New Idea about Permalinks and link-rot using tiddler titles

[pmario]

With the popularity of the relink-plugin, it is much easier for users to change tiddler titles, without messing up the wiki itself.

There has been a very nice idea from Anjar: https://groups.google.com/g/tiddlywiki/c/QOzs3CVtosU/m/_vxFgUeKBAAJ
to use: https://tiddlywiki.com/#:[created[20140904085700000]] as a permalink.

There is a problem with core system tiddlers. They don't have a created field. See Proposal

A second version looks like this: https://tiddlywiki.com/#:[contains:permalink[new-tiddler-20200509141702846]], where the "Permalink" button creates a new field: permalink ... This solution needs write access to the wiki. So this would be the option for the author to create a "human readable" + machine searchable info.

The problem here is, that the modified field will be updated to the time where the permalink was created. .. But IMO that's ok.

The Proposal is:

• If the permalink field doesn't exist,
• use the last part of the link-info eg: -20200509141702846 and search the created field
• If there is no tiddler with this created field, or the "created-key" doesn't exist (core shadow)
  • search for system tiddlers, that have the same <slugified title> as reqeusted in the tiddler search.

The only think we would need to check, if core tiddlers have unique "sluggified titles"

[pmario]

hmmm, There is a problem. ... "shadow-slugs" are super ugly for humans to read

<$list filter="[all[shadows]slugify[]]">
<<currentTiddler>><br>
</$list>

eg:

languagebuttonsencryptionclearpasswordcaption
languagebuttonsencryptionclearpasswordhint
languagebuttonsencryptionsetpasswordcaption
languagebuttonsencryptionsetpasswordhint
languagebuttonsexportpagecaption
languagebuttonsexportpagehint
languagebuttonsexporttiddlercaption

So not only "spaces" should be dashes - ... Slashes / should have been dots or underlines . -

[pmario]

@Jermolene ... Has this been an oversight?

[pmario]

hmmm, There is a problem. ... "shadow-slugs" are super ugly for humans to read

<$list filter="[all[shadows]slugify[]]">
<<currentTiddler>><br>
</$list>

eg:

languagebuttonsencryptionclearpasswordcaption
languagebuttonsencryptionclearpasswordhint

As we see slugify completely fails to create human readable slugs, We will need a new operator eg: xslugify ... That lets us give system tiddlers better names.

And i wouldn't want to call the link "permalink" anymore. I would give it a different name.

[TiddlyTweeter]

@pmario - With the popularity of the relink-plugin, it is much easier for users to change tiddler titles, without messing up the wiki itself....

I think that is a very good description of the "problem" as has been articulated on the Google Group ...

Just FYI, for the types of wiki I use and make, I'm perfectly happy, most all of the time, with the existing permalink method.
But I do appreciate many users like the Relink plugin and actively use it.

I think my bigger question is to what extent "relinking" (i.e. title change update) in user wikis actually IS a major issue beyond them (i.e. creates serious incoming URL Permalink breakage problems)?

Just thoughts!

UPDATE: To clarify what I am meaning ... is it really needed to alter the core to do this when there seem to be workable solutions emerging from users that cover their own needs already?

[ludwa6]

I think my bigger question is to what extent "relinking" (i.e. title change update) in user wikis actually IS a major issue beyond them >(i.e. creates serious incoming URL Permalink breakage problems)?

As i explained in our TwGgroup, TT, it is indeed a major issue -and not only for me, but for its many users (including a significant number of devs & "power users" who have rolled it into their own editions).

UPDATE: To clarify what I am meaning ... is it really needed to alter the core to do this when there seem to be workable solutions >emerging from users that cover their own needs already?

If there were any viable way to do this without core modification, TT, i would certainly agree... But no such thing has emerged thus far, and i guess that's why PMario has escalated the problem to this level. That very clever solution he referenced from Anders -quite apart from its reliance on modified Core tiddler- was not without problems, and this latest one from Charlie, which does sidestep the need of core modification, may be fundamentally incompatible with Relink plugin... Which may be the case with any solution involving an alternative UID field, tho i don't know enough about Relink plugin to say if that is so.

So, i don't know, but still: i don't understand why there cannot be a single immutable and guaranteed unique field on content tiddlers that would be ignored by Relink (which only cares about links & backlinks based on title field), which field we could then use for this specific purpose of publishing to the web.
NB: This new field should never be used on those "$:/" tiddlers, since (as PMario explained) that would create clones that would break the TW update mechanism.

[ludwa6]

UPDATE: As shared in latest exchange on the TWusersGgroup thread, Charlie's "UID Tiddlers Package" prototype solution has passed the critical test of generating a UID permalink that works, even after the linked tiddler is retitled & Relinked (NB: requires version 2.x of Relink plugin to work).

So: does this obviate the need for this proposal, i wonder? Also, as this new package does not affect any "$:/" tiddlers that i am aware of, i guess it should have no impact on TW5's easy update process, but it would be good to have this point confirmed.

/walt

[CharlieJV]

That's fine. You're talking about a problem in greater scope. I'm just interested in solving the very narrow problem of broken links to specific tiddlers. A very small/narrow problem scope-wise, with a very trivial good-enough solution. You're solution will handle more things, so a greater scope of tiddler types, etc. That's all I meant.

[AnthonyMuscio]

Mario,

I have to disagree with counters not being almost enough. You can add a single counter to a compound value constructed of other things, be it a hash of the site url {tends to be unique because domains are) even something as boring as a wiki name.

Personally I believe we should have a registry of wiki serial numbers one can request a unique (next id) from we can all use. Or we could have a aggreed hash algorithm (based on the URL) to get unique WIKI UID's from other unique values like domain, or wiki date in milliseconds....

This enables what you are concerned for a Unique GLOBAL id.

However there are thousands of possible uses of local unique ids even if not global. Amongst my own set of wiki's I can guarantee an effectively global UID.

I have even come to permitting an additional value in my UID at generation time called an epoch. so I have have a design epoch, or based on a version, all tiddlers created then have a UID of Wikiname/epocname/countervalue. The epoc only makes it "more unique" than a counter. The epoc can be freely changed with no loss of tiddler uniqueness. eg change to production epoc.

Now if I was transferring tiddlers interwiki, I can ether assign new UID in the destination OR check the same wikiname/epoch is not in use in the destination. If I forgot to add the wiki name to the UID's a batch process can update all uids within a wiki name (before transfer). If the WIki name or wiki UID could be obtained from a registry then the GUID is possible with little or no computational overheads (each registered wiki would be the responsibility of the registee. We could even populate wikiname/epoc/counter fields on each tiddler if the convention is all three will be used to generate the GUID.

I am also a strong believer in minimising the bytes in a UID and this can be done by changing the counter to a base 62 number consisting of " ", 0-9, a-z and A-Z characters. starting at 0 and having the length for part of the UID just 4 characters can generate 14million unique tiddler values, but this can be extended indefinitely. You do not need to reverse this as all we care is the result is Unique.

GUIID's only need an agreed convention to get 99.99% of the value.

Tony

[AnthonyMuscio]

All,

Charlies solution we can all make use of a filter in the url of he form [[fieldname[value]] when the wiki owner make value unique i9s sufficient for this thread. Perhaps an alternate permalink button could update a permalink-seed field and use a filter to find it in the generated permalink?

Tones

[andjar]

I made a simple demo of an alternative permalink button that creates a permalink field and add sluggified title+timestamp when created and copies an appropriate link to the clipboard. If the permalink field exists from before and the title has been changed, append the new title+timestamp so that both links will work

\whitespace trim
\define permlink() <$text text={{{ [all[current]slugify[]] }}} />-<$text text={{!!created}} />
\define permurl() {{$:/info/url/full}}#:[contains:permalink[$(permaval)$]]

<$button tooltip={{$:/language/Buttons/Permalink/Hint}} aria-label={{$:/language/Buttons/Permalink/Caption}} class=<<tv-config-toolbar-class>> >
<$wikify name="permaval" text=<<permlink>> >
<$wikify name="permaurl" text=<<permurl>> >
<$action-listops $field="permalink" $subfilter=<<permaval>> />
<$action-sendmessage $message="tm-copy-to-clipboard" $param=<<permaurl>> />
</$wikify>
</$wikify>
<$list filter="[<tv-config-toolbar-icons>match[yes]]">
{{$:/core/images/permalink-button}}
</$list>
<$list filter="[<tv-config-toolbar-text>match[yes]]">
<span class="tc-btn-text">
<$text text=" "/>
<$text text={{$:/language/Buttons/Permalink/Caption}}/>
</span>
</$list>
</$button>

Best,
Anders

[pmario]

That's a nice idea, to have a "list-field" like behaviour of the permalink field. ...

---

But testing it I had a new idea. ... Would it be possible to create new "deeplinks" without the need to modify the tiddler, that should be linked to.

The initial idea was, to use [created[date]] as a permalink. ... My desire was to add an additional info, to increase the probability to have a more "unique" link. ... The down side is, that we need to modify the tiddler and add a new permalink field. ... That's OK, if it is OK for the user. ...

But if it isn't OK for the user, we still can use the new deeplink format <title>-<created> but we don't write it. ... We would just need to mechanism how we search for the linked tiddler.

eg: incoming link is: <title>-<created>

• no permalink field with the exact match is found.
• search for a tiddler named <title>
• if <title> is found check for <created> ... If it matches we have an exact match
• if <title> is not found search for <created> ... if found ... we have a partial match with created
• if <title> is found but <created> didn't match ... we have a partial match with title

All the matches are better than what we have now. Where the link is just broken after a rename. ...

just some thoughts

[CharlieJV]

I like it. And I look forward to witnessing the discussion including: I copy your TiddlyWiki, and my copy has the same serial number as your wiki, and tiddlers from my copy are so wonderful that they are spreading like hot cakes, but with your serial number. Well, not me and not my copy. Somebody with a copy and with the ability to crank out good stuff rapid fire. That's an interesting problem. I don't think it is impossible to solve, but I think it will be enough of a challenge that the discussion will be wickedly fantastic, and the ultimate solution pretty frigging cool. Maybe more of a spectator sport for this kid. Maybe...

…

On Mon, May 10, 2021 at 10:22 PM TonyM ***@***.***> wrote: Mario, I have to disagree with counters not being *almost enough*. You can add a single counter to a compound value constructed of other things, be it a hash of the site url {tends to be unique because domains are) even something as boring as a wiki name. Personally I believe we should have a registry of wiki serial numbers one can request a unique (next id) from we can all use. Or we could have a aggreed hash algorithm (based on the URL) to get unique WIKI UID's from other unique values like domain, or wiki date in milliseconds.... This enables what you are concerned for a Unique GLOBAL id. However there are thousands of possible uses of local unique ids even if not global. Amongst my own set of wiki's I can guarantee an effectively global UID. I have even come to permitting an additional value in my UID at generation time called an epoch. so I have have a design epoch, or based on a version, all tiddlers created then have a UID of Wikiname/epocname/countervalue. The epoc only makes it "more unique" than a counter. The epoc can be freely changed with no loss of tiddler uniqueness. eg change to production epoc. Now if I was transferring tiddlers interwiki, I can ether assign new UID in the destination OR check the same wikiname/epoch is not in use in the destination. If I forgot to add the wiki name to the UID's a batch process can update all uids within a wiki name (before transfer). If the WIki name or wiki UID could be obtained from a registry then the GUID is possible with little or no computational overheads (each registered wiki would be the responsibility of the registee. We could even populate wikiname/epoc/counter fields on each tiddler if the convention is all three will be used to generate the GUID. I am also a strong believer in minimising the bytes in a UID and this can be done by changing the counter to a base 62 number consisting of " ", 0-9, a-z and A-Z characters. starting at 0 and having the length for part of the UID just 4 characters can generate 14million unique tiddler values, but this can be extended indefinitely. You do not need to reverse this as all we care is the result is Unique. GUIID's only need an agreed convention to get 99.99% of the value. Tony — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5668 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTBHIAHF3BFO34FDPMRRH3TNCBFPANCNFSM44F2YLOA> .

[pmario]

@AnthonyMuscio

from: #5668 (reply in thread)

I have to disagree with counters not being almost enough. You can add a single counter to a compound value constructed of other things, be it a hash of the site url {tends to be unique because domains are) even something as boring as a wiki name.

That's OK. I think my proposal is "just good enough" and far away from a UUID-discussion. ...

What I want is

• a possibility to allow renaming
• keep a published link alive
• being able to permalink to shadow tiddlers with the "deeplink" system

I think the whole UUID discussion can go away, if we would have a unique URL like hyper://<long-and-unique-string>/tiddlers/ [1] ... Because the address will be unique by itself. ... The rest can be human readable BUT allow us to rename tiddlers. ... The proposal will stay the same for this system.

There are several advantages of a globally unique URL

• Any link will be unique by default
• No registration authority needed
• Only the "owner" can write
• Combining wikis is possible: "multi writer"
  • Everyone is still in control of her/his content
• Versioning is part of the core system
• As long as 1 member "seeds" the URL it will be available
  • I hope archive.org will store at least 1 copy of the URL in the future

The disadvantages:

• The system is new and in flux

[1] https://hypercore-protocol.org/ ... WARNING: The site is mainly "tech-speak"

[pmario]

I am also a strong believer in minimising the bytes in a UID and this can be done by changing the counter to a base 62 number consisting of " ", 0-9, a-z and A-Z characters. starting at 0 and having the length for part of the UID just 4 characters can generate 14million unique tiddler values, but this can be extended indefinitely. You do not need to reverse this as all we care is the result is Unique.

I do like UUIDs that are created this way. .. The only problem I have is, that there should be a possibility to convert version 4 UUIDs into base62-UUIDs and vice-versa without a loss.

even if a ID-4 will look like this 00000000-0000-4000-955d-1c40b5290180 which would be 11 chars for a base62-ID instead of a 36 chars for id-4

I was thinking about a conversion tool, but didn't have time to make it.

[CharlieJV]

And now Google Map Plus Codes are on my mind. Everything is always a degree of separation away ...

…

On Tue, May 11, 2021 at 9:42 AM Mario Pietsch ***@***.***> wrote: I am also a strong believer in minimising the bytes in a UID and this can be done by changing the counter to a base 62 number consisting of " ", 0-9, a-z and A-Z characters. starting at 0 and having the length for part of the UID just 4 characters can generate 14million unique tiddler values, but this can be extended indefinitely. You do not need to reverse this as all we care is the result is Unique. I do like UUIDs that are created this way. .. The only problem I have is, that there should be a possibility to convert version 4 <https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random)> UUIDs into base62-UUIDs and vice-versa without a loss. even if a ID-4 will look like this 00000000-0000-4000-955d-1c40b5290180 which would be 11 chars for a base62-ID instead of a 36 chars for id-4 I was thinking about a conversion tool, but didn't have time to make it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5668 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTBHIEFES4POJK23T27HHLTNEQ4RANCNFSM44F2YLOA> .