Relink vs Permalinks

[ludwa6]

The more i use TW, the more concerned i become about maintaining data integrity -and so this issue has boiled to the top of my queue: how can i continue to enjoy the benefits of TW (+ Relink plugin) flexibility, without compromising the integrity of Permalinks?  

This feels like a deep problem that goes right to core TW architecture- since, as PMario explained in last thread, tiddler immutability is tied to its Title (so how can Relink even work, i wonder?)- but if i've learned anything here, it is to not underestimate the creative problem-solving ability of this group :-)... SO:

From a non-technical perspective, what i'd like to do is have some immutable UID (based on date-time, or maybe date+ a serial number, like yyyy-mm-dd-serialnum) that is used for Permalinks (i.e. shared w/ the outside web that is not Relink-aware), but still have Title field and Relink plugin (and everything else for that matter) work just as it does now, from the TW editor's perspective.

Is this a reasonable feature design goal, i wonder?  If so, i'd like to do what i can to help make it happen!

/walt

[TW Tones]

Walt,

As I understand it your concern is when using permalinks. In this case you are externalising a tiddler with a URL. I think there is an argument that if you use a permalink it should be for something permanent.

Now if you would like the ability to generate a link that will return to the same tiddler in the future, even if it changes it's name, then we can do that. 

However before I explain how, can you clarify what you are trying to do or get from tiddlywiki because I have never come across this as a problem (I put it down to my tiddler naming skills :). Can you give an example?

Regards

Tones

[TiddlyTweeter]

Ciao walt,

Right. Tiddler PERMALINK-ability posted as URLs elsewhere is intimately tied to NOT changing Titles.

Personally I can't get in a hot sweat over that. That is no different than any other web page.

SURE you could get into REDIRECTS on a server or up the complexity within  TW of self-REDIRECTS I guess?

I don't really see the point though :-). 

Best wishes

TT

[ludwa6]

OK @Tones & @TT: if neither of you guys sees this as problematic, then i'd better explain myself better.  Here's a meta-example i've just documented:

1.  Create a tiddler on this topic, and give it a permalink: https://meta.tiddlyhost.com/#AvoidingLinkRot.  Share link with friends, to engage their support in taming this dragon!
2.  Recall that "Link Rot" is a well-known problem, which Wikipedia might know about- and indeed: see https://en.wikipedia.org/wiki/Link_rot
3. Realise that- in keeping w/ principle of AtomicGranularity- i should probably limit this tiddler to describing the problem (including link to that Wikipedia article and maybe just my review of that material) and rename it after that article: "ProblemOfLinkRot"
4. Work away on that renamed tiddler, adding my detailed analysis of the article, and the problem.  
5. Puzzled after a time as to why nobody is commenting on my work, check the link -and find out that it's broken. (yeesh! and nobody told me? did they even click the link i shared?)

i've run through this loop enough times, it's already getting old.  Could it be that it's just me, i wonder?

/walt

[Anjar]

Hi,

I agree with you and see the problem. One simple solution is just sharing links like https://tiddlywiki.com/#:[created[20140904085700000]]

Best,

Anders

[TiddlyTweeter]

Ciao walt,

I feel your pain. BUT a PERMAlink is as its name suggests.

All the gizmoidology we have in TW now to CHANGE the Titles of tiddlers and correctly RELINK them will NOT address the PERMAurl issue if the clickee ONLY has your previous version of the link.

This leads me to think you are seeking for an INTERNAL-REDIRECT mechanism (parallel to what servers do everyday) in TW such that an old address gets redirected to the latest version of the Title.

    I have NO idea how complex that would be to make. 

    NOR do I think it is needed.

Truth is if you are INTERNET FACING then the easiest method is to NEVER publicly publish a permalink that could cease to exist---and don't change Titles ever on public wiki. :-)

My 2 cents :-)

TT

[ludwa6]

Hey @Anjar -that's cool!  Could be the makings of a viable solution.

Question: Create-date is both immutable, even if the tiddler name is modified, and guaranteed unique -is that right?

If so, then this would satisfy the conditions of a UID -and then i can still change the tiddler's Title (which can and should occur for all sorts of good reasons that i can explain if need be).

Would be nice to make generation of such URL a button-push kinda thing, instead of having to "hack" it (simple as the syntax is, it's a bit of friction i'd like to avoid if possible).

Thanks, Anders!

/walt

[Charlie Veniot]

G'day walt,

That is a huge pain point for me.  In my previous career, I relied heavily on the ProjectForum Wiki to keep track of everything.  It did not use page names in URL links, but rather used auto-generated unique identifiers.  So I could change page titles to my heart's content, knowing that URL links were always stable.

My approach, still formulating it, is to edit tiddlers via custom forms.  The tiddlers have auto-generated unique identifiers stored in the title.  What would normally be the title goes in a field.

That works fine right as-is for structured data.  I haven't looked into setting up the formatting buttons (bold, italics, etc.) for formatting text.

I think this could still work for you well if you have an easy way to lookup tiddlers via a field instead of via title, and if you can overcome that mindset change.

[TiddlyTweeter]

Ciao cj.v..., 

Interesting! 

Functionally that is working like a SURROGATE permanent REDIRECT. It is a clever solution! but requires the logic of the Wiki to change considerably and its owner to know what to do. :-)

HOW, for instance, do you quickly generate a PERMALINK you can quickly post online?

Probing :-)

TT

[ludwa6]

Yes, TT: PERMAlink should be just that -which is why i advocate for tying it to something that is both guaranteed unique AND immutable by its very nature -not by convention (i.e. best practice).

In fact one should be free to change Title of a tiddler, as it is the right thing to do under certain circumstances -e.g. narrowing the specificity of a topic, as i tried to illustrate- even in a public wiki. 

in fact -as anybody who has ever managed  a large relational database can tell you- this is the very good reason why any industrial strength RDBMS assigns a UID automatically (taking Primary Key declaration out of the user's hands) because names can always change... and do, as a rule.  You might think a person's name is both guaranteed unique (if it's long & weird enough) AND immutable, but -when your DB gets large enough- there's almost sure to be some other(s) with such name AND some person(s) who change their name (gender, even!) legally.

So you can see that, even in a public wiki, if you have tiddlers named after living persons, you need to be able to rename such tiddlers. 

/walt

[Anjar]

Hi Walt,

It should be trivial to modify the permalink button to produce links as https://tiddlywiki.com/#:[created[20140904085700000]] but the creation time is not guaranteed to be unique (the link will then open both tiddlers, so no harm is done), although in practice it usually will be

An alternative is to make the permalink button add the current title to a separate field (say permalink) and use that field to produce a URL like https://tiddlywiki.com/#:[permalink[aReadableTitle]] The strength is that the URL then will be human-readable and you have the history of old titles, but again, it is not guaranteed to be unique

If you are not afraid to add plugins, there is a plugin (https://ibnishak.github.io/Tesseract/pluginsandmacros/index.html#UUID%20Plugin) to create UUIDs that can also be used to populate a separate field to get URLs like https://tiddlywiki.com/#:[uuid[anUUID]]

Best,

Anders

[ludwa6]

I've been following your forms development w/ interest, Charlie -and this makes it all the more interesting- but i really think this idea of permalinks using createdate is much simpler, if indeed that attribute satisfies the 2 aforementioned criteria.  There is so much goodness in a TW instance that is title-dependent, i'm afraid that throwing some auto-generated code into the title would compromise its human-friendliness, if nothing else.  /w

[Charlie Veniot]

Right-click on the link, copy and paste ?  Kind of like this:  https://tifoist.neocities.org/CJ_TIFOIST_PROJECT.html#Fact-000001

Because, say, "Tid-0000123" is a little hard to identify, one would need to customize TiddlyWiki a little to have links that display maybe the caption field's text (or whatever other )  i.e. something recognisable so one can right-click on the thing and copy the URL.

I never use PERMALINK.  I always right click on a tiddler link and copy the URL.  But if you are looking at the open tiddler, PERMALINK still does what it ought to do with the title having an autogenerated unique identifier.

[ludwa6]

That's a new one on me, Anders; will give that plugin a try -thanks!  /w

[David Gifford]

I agree with you and see the problem. One simple solution is just sharing links like https://tiddlywiki.com/#:[created[20140904085700000]]

 Anjar, I like this idea. Is there a way to hijack the permalink button so that it displays this?

[Charlie Veniot]

Another solution: when one wants a link to a tiddler that will never change:  create a "URL-safe" tiddler (i.e. a name that will never change) with the only purpose of transcluding a tiddler with a title that could be subject to change at any time.

So, if you have "Tiddler XYZ", have an auto-generated-title tiddler (Say "Tid-0000001"), and have "Tid-0000001" have in it's text only {{Tiddler XYZ}}.  For external references to your TiddlyWiki's "Tiddler XYZ", actually grab the URL for "Tid-0000001".

Then you can change the title for "Tiddler XYZ" willy nilly, knowing that the external reference to "Tid-000001" will always be rock-soid.

All of that said, had I been involved in TiddlyWiki right from the start, I would have screamed and hollered for TiddlyWiki to have auto-generated unique ID's for all Tiddlers, such that external URL references to a TiddlyWiki's Tiddler always has the unique ID of the tiddler and never the name.  Sigh ...

In the same way as I like all tables in Oracle databases to use sequence numbers as primary keys.

[Charlie Veniot]

TiddlyWiki's Tiddler Template could be modified to show something other than the title field in the "title area" of a tiddler.  Not sure how much fiddling it would take to get that working.

Using createdate is a really quick way to go,  It can only be a little bit lousy on a day in which a whole bunch of (wildly?) unrelated tiddlers got created, but then one could add all sorts of extra filtering in the URL to exclude certain kinds of tiddlers.

On Wednesday, May 5, 2021 at 11:02:21 AM UTC-3 ludwa6 wrote:

[Charlie Veniot]

I forget to mention that ProjectForum is defunct since 2016, just in case anybody's curiosity got the best of them.

If curiosity is still getting the best of you:  https://web.archive.org/web/20160528045948/http://www.projectforum.com/pf/pfuserguide.pdf

[TiddlyTweeter]

Ciao Anjar & David

Nice one!

I agree with David. 

Without a clear, one button, method to get the "PERSISTENT DATE STAMP REAL PERMALINK"  like that it is too obscure a method for daily use.

When you open the tiddler "created" field is, of course, not visible.

SO how do you quickly, one click, get what is needed to paste the URL?

Best wishes

TT

[Charlie Veniot]

Anders, you sweet and huggable you.

That way of getting tiddlers is new to me, and just gave me a fantastic idea.

Now knowing that URL's like https://tiddlywiki.com/#:[title[Saving%20on%20TiddlySpot]] and https://tiddlywiki.com/#:[delivery[Service]]

Then having auto-generated/auto-created uid fields on tiddlers ...

Say a tiddler titled "Tiddler XYZ", if it had a uid field with value "tid-000001", then a link like this should work:  https://whatever-your-tiddlywiki/#:[uid[tid-000001]]

It is just a matter of having an alternate permalink button that generates that uid link.

Yay ?

[Charlie Veniot]

Oh, and also a button to give a tiddler a uid field with an auto-generated uid value.

Something like that ...

[dieg...@gmail.com]

Here are some related threads where I also shared some thoughts along this topic:

https://groups.google.com/g/tiddlywiki/c/pvc-qqoWHdI/m/TcX3FPNaAgAJ

https://groups.google.com/g/tiddlywiki/c/WtNz2X10jIA/m/9VaQHBjUCwAJ

I also would love to have built in support for uniqueIDs (created serves great!) but no one actually wants to //type// it out! I gave some ideas to avoid having to type it out in the threads. Something like:

[[#current_title]] gets replaced-on-save with the actual created time stamp of the tiddler. Then, on view mode, that is parsed and displays the current title, whatever it may be. That way, I never type the created timestamp, but it gets actually placed in and in view mode, I never even see a differnce.

[Anjar]

Hi,

Here is a demo for a new permalink button. It creates a new field called permalink and inserts <slugified title>-<created>. Since the title is unique at creation, this string should be unique (?). Further, it copies the appropriate link to the clipboard; https://tiddlywiki.com/#:[contains:permalink[new-tiddler-20200509141702846]]. If you change the title, the button appends the new <slugified title>-<created> to the permalink field so that both links go to the same tiddler

Best,

Anders

[ludwa6]

Your spec ticks all the boxes, Anders... So i installed it, but not getting the hoped-for result, alas.

What i did: Changed URL on the "ProblemOfLinkRot" tiddler to "SolutionToProblemOfLinkRot"; selected (modified) Permalink button in pulldown tiddler menu -and it copied the composite URL, composed per your specification, to my clipboard, which is also populating the new "Permalink" field, i see.  So far so good... But there is yet a problem -two actually:

1. When i point my browser to the new URL- https://meta.tiddlyhost.com/#:[contains:permalink[solutiontoproblemoflinkrot-20210505114349833]] - it pulls a blank page.
2. The old permalink-  https://meta.tiddlyhost.com/#ProblemOfLinkRot -brings me to a "Missing Tiddler" page (not surprising, since a tiddler with that name indeed exists no more, having been overwritten by the new... And that old URL has no "contains" parameter in it).

I hadn't really thought of this problem in terms of having two different URLs pointing to the same tiddler; instead, i was hoping that a UID could be assigned on tiddler creation (ideally a not-too-weird combo-key: original name (guaranteed unique at the time, as you say) plus date would work), which persists across any renaming event in the Permalink field, but is not the title.  Is there some problem w/ this simpler solution that i'm not seeing?

/walt

[ludwa6]

Correction to my last: dunno what caused the phenom i reported as #1 above, but i can no longer replicate that error; the new URL works fine.

However: problem #2 reported above persists -and so my question about a potentially simpler solution to this two-headed problem stands.

/walt

[Anjar]

Hi Walt,

I am glad it solved the first problem.

Ad #2: You are right, permalinks created earlier are not affected by this solution. However, if you now rename the SolutionToProblemOfLinkRot tiddler to ProblemOfLinkRot and click the permalink button, then both #:[contains:permalink[solutiontoproblemoflinkrot-20210505114349833]] (old) and #:[contains:permalink[problemoflinkrot-20210505114349833]] (new) will work

I think it will be very difficult to solve #2 in a general way that ensures that links already shared will keep working forever. It may be possible (but I don't know how) to make a solution to search in the permalink field if the tiddler couldn't be found (eg. /#ProblemOfLinkRot -> look for problemoflinkrot in the permalink fields -> list all potential hits). But if you later make a new tiddler called ProblemOfLinkRot, then the old link will give you the new one

Best,

Anders

[PMario]

On Wednesday, May 5, 2021 at 6:12:15 PM UTC+2 Anjar wrote:

Here is a demo for a new permalink button. It creates a new field called permalink and inserts <slugified title>-<created>. Since the title is unique at creation, this string should be unique (?). Further, it copies the appropriate link to the clipboard; https://tiddlywiki.com/#:[contains:permalink[new-tiddler-20200509141702846]]. If you change the title, the button appends the new <slugified title>-<created> to the permalink field so that both links go to the same tiddler

Hi,

That's a nice idea.  ... But the problem is, that I also want to create permalinks on pages, where I don't have write access. ... So this permalink button doesn't work with tiddlywiki.com

Your first ideas would. I do like this idea.  https://tiddlywiki.com/#:[created[20140904085700000]] ... The only problem is, that most core tiddlers don't have created and modified, to save space.

The problem I have with such links is Browser History Pollution. The same thing, that goolge does with it's links. So it would be nice, if there was a possibility, that the browser history stores something useful.

-mario

[PMario]

I did create a Discussion at github. So it should be longer visible for the devs.

<quote from github> Title: New Idea about Permalinks and link-rot using tiddler titles #5668

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"

</quote>

have fun!

mario

[PMario]

Hi Walt,

Yes, link-rot is a problem. If we could improve it, we should definitely think about it.

I think the relink-plugin is very popular. It is one of the first plugins I import into my own wikis. ...

It makes it easy and safe to change tiddler titles, without messing up the wiki.

So the probability, that published permalinks get broken, definitely increased with this plugin. Shame on you flibbles!

have fun!

mario

[PMario]

uups. Here's the link to the github discussion: https://github.com/Jermolene/TiddlyWiki5/discussions/5668

[Michael Wiktowy]

This sounds like symbolic links vs hard links in file systems. If you change the name of the file that a symbolic link (or shortcut in Windows) points to, it breaks. If you change the name of a file that a hard link points to it doesn't break . The reason for this is that the hardlink doesn't point to the copy of the changable name of the file, it points to a common inode that the other file (with the name changed) points to also. So they are pointing to a common source.

This leads to a similar solution as in file systems. Maybe tiddlers need an abstraction later where the immutable tiddler is like an inode and all renameable tiddlers are just all-field-trancluded inode-tiddlers.

You could assign a randomized name to the immutable tiddler but if you want to go further, the names of the inode tiddlers can be a content hash ... maybe a SHA-1 of the tiddler contents ... so if the tiddler content changes, you can relink the hardlink-tiddlers to the new contenthash-tiddler. Then if you want to set up a permalink, it will use the contenthash-tiddler name. Then you can be guaranteed that the *permalink* is actually to the *content* that was originally linked ... if it still exists ... and not just to a ephemeral name.

But this is actually sounding a little bit like git. It does offer some pretty lightweight revision tracking possibilities though.

I don't think setting up a "redirect" is too tough though depending on the scope ... it is essentially just opening up the tiddler you want to rename, ctrl-A, ctrl-E, put in a new name and pick transclusion or macro ... although the other non-text fields wouldn't get excised+transcluded. Maybe there is a need for a "_content" field that acts like a _canonical_URI field but local to the tiddlywiki and replaces all the fields in the hardlink-tiddler with that of the tidder in the "_content" field.

Maybe this is crazy-talk.

/Mike

[Charlie Veniot]

YouTube video:  TiddlyWiki: A Prototype of UID's for stable permalinks

[TW Tones]

There is a lot of water under the bridge in this thread so here are a few points that may or may have not being covered;

• In summary it is not difficult to generate stable permalinks.

This is based on 100's of hours of my time considering these issues and dozens of prior conversations.

• Unless you fiddle with default behaviors the created field will not change, the only concern is if more that one tiddler has the same date, this can be tested on one one date incremented (in the microseconds) to make them unique.
• When making a permalink, who is to say if the tiddler changes its name, that link may not longer be valid anyway.
• Using URL's containing search and reference to a unique ID is superior to permanent links.
• Others including myself have created viable tiddler serial number solutions, which may ONLY be needed for this generating an advanced permalink, ie only tiddlers with an advanced permalink need have a serial number applied.
• There are other issues if publishing static sites, however url redirections can be put in place.
• Interactive tiddlywikis have the smarts to address changes, static ones by definition do not necessarily, however it would be trivial to not delete a tiddler, when renaming but include a html redirection in it if the static url is to change.
• Global Serial numbers or UUID's are overkill in most applications where we need "unique References", references need only be unique to the tiddlywiki, at its domain/folder address unless you are designing for GUID's to allow dragging and dropping of tiddlers.

Regards

Tones

[Charlie Veniot]

That is some good stuff.

Only one of those I'd dare fuss about:  

• Using URL's containing search and reference to a unique ID is superior to permanent links.

That one I'd say "it depends" on a whole bunch of things.  Every solution is superior to every other one depending on the trade-offs, the scenarios, the design, blah blah blah snooze.

I would much prefer provide ability for visitors to grab UID permalnk because they are so easy), but setup my TiddlyWiki with the smarts to recognize somebody is trying to access a tiddler via a link with a bad UID (maybe I should call that "SEQ" for sequence number), and redirect to TiddlyWiki's search page along with a message that related tiddler no longer exists, here are a few others in the vicinity of the UID in case they are materially close.  Something like that.

[TW Tones]

Cj,

If you want to try that you can create a view template that tests if the tiddler is missing. If it is it will display the missing message and you can interrogate the URL used to get there and propose the users click a search button to find the tiddlers new title, if by no other method than a unique created date. You could have a table somewhere that it searched for the old title, and find the correct and latest new title.

This has the advantage of tiddlywiki informing the user the link has changed. Like a html 404 page with a search facility. This could even suggest the user open an archived wiki.

I can share more if you want to go that way.

With "Using URL's containing search and reference to a unique ID is superior to permanent links"  the key point is a permanent link is that, permanent, it should remain permanent, if we must rename something then we are after a non-permanent responsive link (however it is done).

Tones

[ludwa6]

Q: What's even better than "Rough Consensus & Running Code" ?  A: All that, plus a video explainer to boot :-). 

Of all my YT channel subs, Charlie, yours is the one that i am watching most eagerly to see what comes next.  

Rock on, man!

/walt

[Mohammad Rahmani]

On Wed, May 5, 2021 at 8:42 PM Anjar <ajar...@gmail.com> wrote:

Hi,

Hi Andres,

Here is a demo for a new permalink button. It creates a new field called permalink and inserts <slugified title>-<created>. Since the title is unique at creation, this string should be unique (?). Further, it copies the appropriate link to the clipboard; https://tiddlywiki.com/#:[contains:permalink[new-tiddler-20200509141702846]]. If you change the title, the button appends the new <slugified title>-<created> to the permalink field so that both links go to the same tiddler

Very clever solution! I see it also keeps a history of renaming!

Wonderful!

 

Best,

Anders

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7a484ee5-05f0-48cf-a7dd-8cd15c72a6c4n%40googlegroups.com.

[ludwa6]

Interesting thoughts, @Tones (as usual), two of which i find most stimulating:

On Thursday, May 6, 2021 at 5:21:27 AM UTC+1 TW Tones wrote:

...If you want to try that you can create a view template that tests if the tiddler is missing. If it is it will display the missing message and you can interrogate the URL used to get there and propose the users click a search button to find the tiddlers new title, if by no other method than a unique created date. You could have a table somewhere that it searched for the old title, and find the correct and latest new title.

This has the advantage of tiddlywiki informing the user the link has changed. Like a html 404 page with a search facility. This could even suggest the user open an archived wiki.

If this could go beyond the typical 404 + direction to the standard search widget -and i guess maybe it can, since the wiki KNOWS about this name change, right?- then YES, that would be super-interesting.  /w

 

I can share more if you want to go that way.

By all means, Tones -i for one am all ears!   /w

With "Using URL's containing search and reference to a unique ID is superior to permanent links"  the key point is a permanent link is that, permanent, it should remain permanent, if we must rename something then we are after a non-permanent responsive link (however it is done).

I may be slow, but i do believe it essential to the case -especially since @PMario has escalated this issue to the TW devs repo- to deconstruct this assertion to underlying premises.  Let me try:

1. A Permalink is by definition permanent.
2. The way TW implements it now, it pulls the URL of hosted instance followed by /#TiddlerTitle.  (NB: that convention works as a reference to any tiddler in the wiki, even without using the "Permalink" feature, if one knows enough to apply it).
3. If TiddlerTitle changes to NewTiddlerTitle, then Permalink brings user to the default "MissingPage" tiddler (NB: empty, i.e. devoid of any more helpful information)
4. So if the ability to change TiddlerTitle to NewTiddlerTitle is wanted, then a Permalink feature must be tied to some immutable (and guaranteed unique) attribute of the tiddler. 
5. By adding an additional "permalink" field to all tiddlers that are only "published" following creation & population of that field with a UID, then such link will never break, so long as that field is never modified (NB: a rule that could be encoded as a hard constraint).

Now, since both Anders and Charlie have demonstrated two different ways in which we can create and populate such new "permalink" field, it is clear that this is possible... So what would be the problem with simply populating that field with a crash number, as every RDBMS worth of the name does as a rule?

(i must be missing something, given all the complexity being bandied about here by logical minds greater than mine... But i'm gonna go grab my morning coffee and see if i can't catch up w/ y'all :-)

Yours, Walt

[TW Tones]

I can confirm that if your permalink is out of date (ie the tiddler no longer exists) opr you click on a link to a tiddler title that does not exist,

the view template tiddler  $:/core/ui/ViewTemplate/body will display the tiddler $:/language/MissingTiddler/Hint

which contains

Missing tiddler "<$text text=<<currentTiddler>>/>" -- click {{||$:/core/ui/Buttons/edit}} to create

At first I though It would be simply a matter of redesigning this tiddler with a button that says this address is no longer valid, click to search for the renamed/replacement content or similar. Keep in mind currentTiddler is the missing title.

However an ever smarter bit of wiki text could just make the missing tiddler "look" like the "new" tiddler" by finding its content and displaying it as if you were in the new tiddler.

Regards

Tony

[PMario]

On Thursday, May 6, 2021 at 9:39:36 AM UTC+2 ludwa6 wrote
...

So what would be the problem with simply populating that field with a crash number, as every RDBMS worth of the name does as a rule?

A random number isn't human readable. What I did like at https://tiddlywiki.com/#:[xxxxxxxx[new-tiddler-20200509141702846]] is, that there is a human readable element in it and it is "somewhat" unique.

Even if 2 tiddlers from different TWs have the exact same "created" timestamp, it is very unlikely, that they also have the same name. ... Except they are the same tiddler. ... Which is OK.  

A very important part is: TW shadow tiddlers DON'T have a created field. So you cant find them with [created[something]]

We have to find them by name. ... AND If you install a different language, all /language/ tiddlers are exchanged,, only the title will be the same.

-mario

[PMario]

On Thursday, May 6, 2021 at 2:56:32 AM UTC+2 cj.v...@gmail.com wrote:

YouTube video:  TiddlyWiki: A Prototype of UID's for stable permalinks

See my comment here: https://groups.google.com/g/tiddlywiki/c/l2Mwu3pOAXw/m/9V3mVFXLBAAJ

Linking to a tiddler must not break the TW update mechanism.

If it does, there is a high chance, we will have a very high number of support requests, with broken updates.

-m

[Charlie Veniot]

Okay, package of tiddlers (updated since the video) posted in  A Prototype of UID's for stable permalinks conversation.

[ludwa6]

Anders: much as i appreciate the brilliance of your solution to this problem, i think that -since Charlie's come up w/ a different solution that solves the problem w/o opening core functionality to possible corruption (right? i hope!)- then maybe i would do well to remove this "$__core_ui_Buttons_permalink.json" code from my wiki -yes?  

If so, i have to ask (as i'm still a total n00b when it comes to this core / shadow tiddler stuff, obviously): what tiddler(s) do i need to remove or modify to eliminate this risk of creating clone tiddlers that are gonna break the TW upgrade process, as PMario has explained could be a problem.

[Anjar]

Hi,

To remove it, just delete the permalink button: (replace URL with your own) https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FButtons%2Fpermalink

But I don't think we are changing any core functionality with this button; all we have done is replaced the single button and all it does is making a new field and copying a string to you clipboard. So I don't think it will interfere with anything

Best,

Anders

[Charlie Veniot]

I'm pretty sure we are talking very different problems.

The problem I am solving is trying to guarantee as much as possible and with the least amount of fuss:  prevent a URL, out in the wild and to a specific tiddler existing in a TiddlyWiki that is also out in the wild, from not opening that specific tiddler should the title of that tiddler ever change.

There is no ice-cube's chance in hell that what I've done can get break anything in any TiddlyWiki, let alone the TW update mechanism.

I am ready to eat crow at anytime should anybody be game to prove me wrong using this UID-permalink thing for only/exactly the intended purpose.

Should anybody use this UID-permalink thing for anything other than the intended purpose, I can't help that.

Same as I can't help somebody driving a moped and entering a crash-car derby meant for 3/4 ton trucks.  The moped wasn't intended for that.

Now if "UID" for permalinks is a label that leads to confusion (re intended purpose), I am game for anything else that is 3-4 letters long and that is obvious re intended purpose.

Would "PIN" be better, for permalink identification number?  Or PID?  (Either of those can be confused with Property Identification Number re land/tax registries)