A Prototype of UID's for stable permalinks

[Charlie Veniot]

What the heck, I ask for forgiveness rather than for permission.

I'm thinking this may be worth a distinct thread in case it generates loads of questions/comments.

YouTube video based on the conversation in Relink vs Permalinks :

TiddlyWiki: A Prototype of UID's for stable permalinks

[PMario]

Hmmm,

I think, that's not very practical. As soon as you want to link to a TW shadow tiddler, you create a clone as a side effect.

IMO linking needs to be side-effect free!  Those edited shadows are "system" tiddlers. System tiddlers are "user content" and the use always wins. So those tiddlers will not be updated, if a new core will be used.

So linking will break the update mechanism

Just a thought.

-mario

[TiddlyTweeter]

Ciao cj.v...

I'm struggling to understand the application of this to any Tiddler shadowed. 

In making a "Nuovo Permalink" in one you'd overwrite the original.

So, in order to MAINTAIN them you'd need to RE-apply the UID IF the original was ever restored.

Sounds complicated!

JUST a comment 

Best wishes, TT

[Charlie Veniot]

Oh good Lord no, this isn't meant for system tiddlers.  That's something that would need preventing (i.e. make that button unavailable for system tiddlers,) which should be ridiculously easy to do.

If one is going to need permalinks for external access to system tiddlers in some hosted TiddlyWiki, old-fashioned perma-links should do.

To me, system tiddlers are no different than system DLL's in an operating system.  Once named, don't fiddle with the name. 

[TiddlyTweeter]

cj.v...@gmail.com wrote:

Oh good Lord no, this isn't meant for system tiddlers.  That's something that would need preventing (i.e. make that button unavailable for system tiddlers,) which should be ridiculously easy to do.

 Good. But now, a footnote. 

But WHAT are "system tiddlers"? Surely they include anything starting "$:/" ... 

In my own case I create zillions of tiddlers starting "$:/". 

It is just a fetish I have based on the Wizard Of Oz. 

Everything under "$:/" is behind the curtain.

THOSE could do UID too and, in my case, would be needed for UID to work for this end user. 

It is only shadowed tiddlers that would have the issue I raised in my previous post.

Further thoughts

TT

[Charlie Veniot]

Yeah.  I went with a simple architecture.  Creating a UID adds a field to the tiddler with a UID value.

Adding a UID to a system tiddler would create a copy of that tiddler.  That would suck.

I think the whole concept of UID should be in the core, and for the core to know how to handle UID's getting slapped on system tiddlers.

Well, something like that.  I have to chew on it a little.  Up to now, my concept of UID is just for those folk who want stable URL's to non-system tiddlers.

Instead of storing a UID with a tiddler, it could be stored somewhere else.  Yuck.

[Charlie Veniot]

BTW, I keep mixing up, and keeping in my head, what is a "system" tiddler, and what is a "shadow" tiddler.  So anytime I read any related post, or attempt to give thoughts related to those types of tiddlers, there is a strong chance that I've regressed again re knowing which is which, just when I finally got it straight.

So bear with me a little.  Maybe I can get it locked-in updating my wee prototype to deal with both system and shadow tiddlers.  I wouldn't get my hopes up...

[TiddlyTweeter]

cj.v...@gmail.com wrote:

BTW, I keep mixing up, and keeping in my head, what is a "system" tiddler, and what is a "shadow" tiddler.  

Right.  There are TWO Wizards Of Oz. The one behind the curtain ($:/) and the one behind the curtain behind the curtain ($:/(shadow)).

Light relief https://www.youtube.com/watch?v=ci6O7jmRtwA

Best wishes

TT

[Charlie Veniot]

That was oh-so ridiculously good.   I did not know the man can sing.  Thanks !

[TW Tones]

Mario,

It would be simple to enhance the update process to report on the core shadow tiddlers it changed that have a "tiddler" (rather than Shadow) and give the user the ability to review the differences and decide what to do (accept -trash tiddler, ignore -keep tiddler, edit - update new core with edited tiddler). Alternatively a "post update" review.

As I understand it the update currently just replaces mostly the $:/core plugins, if not all, even if they don't change.

Regards

Tony

[Charlie Veniot]

Now that I momentarily have "system" vs "shadow" tiddler straight and before I regress ...

I can't imagine any value of any shadow tiddler having a uid-based permalink, so I've modified my code to hide the "INIT UID" button.  (See screenshot below.)

If one modifies a shadow tiddler (thus creating a copy of the original, leaving the original untouched), then the "INIT UID" button will be available on the modified version of the shadow tiddler, allowing eventual UID-based permalink.

Before I post the code for eval/testing, I want to review the conversations again, and try to think of what I may not be considering.

Cheers !

So "New Tiddler" being just a regular tiddler, vs a shadow tiddler, and whether or not "INIT UID" button is available:

[TW Tones]

All,

First, Charlies Original video post addresses this very well.

I wonder if the "smart" permalink could be set to use any field eg [[fieldname[value]] not just [[uid[0000n]] and if there are multiple tiddlers open them all?

On system vs tiddler "serial" numbers, I built a system I have not yet made public, that had TSN (tiddler serial numbers) and SSSN (system/shadow Serial Numbers) it is possible to have both (TSN and SSSN) but unlikely. The SSN's are recorded separately from the tiddler (if it is or has a shadow), with the expectation that one day we may put a SSN on all core system tiddlers but until then I do not want to turn every system tiddler into a tiddler with an edit.

• We should also remember you can place a unique ID, on demand, for tiddlers than need it, and leave the rest alone (charlie demonstrates this)
• I will also reiterate we can already do stable permalinks by other means (missing tiddler handling) not UID's basically before displaying a missing tiddler content go looking for the new content, people will not notice it moved.
• UID's have a lot of benefits and I would love a good solution, Charlies is approaching it,
  however there are other ways to address permalinks.

Charlie - 

• I would be happy to provide other benefits to serial number fields - automatic or preset.
• There is a little trick, in generating serial numbers if other users can access the same wiki. Generate (read, increment, write) the number inside the button so it happens only at the moment of the click.
• I also have algorithms for making very short serial, numbers,. saving many bytes/kilobytes for lots of serial numbers.
  • Serial numbers can be one way, generate them from an increment with any unique algorithm, once stored in the tiddler (Hide the field from the edit view so it can't be edited), and they do not need to be user readable although why not?
    
  • It is possible to add additional values to the serial number if desired, like a wiki name to ensure cross wiki validity. or even add an epoch, eg design, then published, the serial number remain unique (in this wiki) because of the serial component but they can allways carry more information.
• It would be useful in the wiki to keep a record of the permalink used to get to the site at least for the current session, thus the content can be varied for different users and the permalink they used.

Regards

Tones

[Charlie Veniot]

Changed my mind because it is a pain to properly setup.

I don't see the value in UID's for modified copies of shadow tiddlers.  Regular permalinks should be good enough for those tiddlers, because the names should never change.

Right?

[Charlie Veniot]

On Thursday, May 6, 2021 at 11:15:19 PM UTC-3 TW Tones wrote:

All,

First, Charlies Original video post addresses this very well.

I wonder if the "smart" permalink could be set to use any field eg [[fieldname[value]] not just [[uid[0000n]] and if there are multiple tiddlers open them all?

That's the beauty of it, for example:

• https://tiddlywiki.com/#:[regexp[add]]
• https://tiddlywiki.com/#:[[add%20Operator]addsuffix[:addprefix%20Operator]split[:]]
  

An awful lot of power slapping a filter into the URL.

 

[TiddlyTweeter]

cj.v...@gmail.com wrote:

I don't see the value in UID's for modified copies of shadow tiddlers.  Regular permalinks should be good enough for those tiddlers, because the names should never change.

Right?

Right! It makes total sense NOT to UID instances of the Holy Ghost (shadows).

IF a user wanted to take code from a shadow they'd likely clone it to a different name that is no longer shadowed anyway. 

THOSE could just be used with UID in the normal way you are developing since there no chance they could be  overwritten on updates.

(Just FYI to maintain modified shadows I simply use PMario's excellent BUNDLER import/export plugin to transfer mods between wiki.)

Just comments

TT 

[TW Tones]

Charlie et al.

I think serial numbers on tiddlers and not shadows is fine for 90% of possible actions. As I suggested there are ways to store info for a tiddler, outside the tiddler, and that's what a system serial numbers tool would be about. A few people here have suggested there is no use, but I am not sure they have put their imagination to work on it yet. 

• When cloning (not renaming) we need to generate a new serial number, it would be easy to use old and new serial numbers to track the source tiddler and what was cloned from it, especially useful with code and system tiddlers.
• Documenting the system tiddlers involves some long tiddlernames, space could be saved using a link based on serial number.
• Analysis of new and missing serial numbers would help us see changes across tiddlywiki versions.
• Actually its always being hard/impossible to see deleted tiddlers   (without a trash plugin), a serial number solution could support this.

And more I am sure.

Charlie
In relation to your solution Charlie, that was complete out of the box then, placing a filter in the URL? Any field or value that can be put in the url then? Cool, tiddlywiki already does it then.

Tones

[TW Tones]

The beauty of it yes.

A new permalink button that applies a unique ID then creates the matching url with search filter to the unique ID would be perfect, for permanent tiddler "rename tolerant" permalinks.

However, I do not find it hard to make tiddler names I don't change if necessary. perhaps a "rename inhibit" setting on tiddlers could help. Then I have a whole set of tiddlers I can freely rename if needed like todo items etc... If one wants to get as permalink to something which may change the name then charlies filter on the url is the solution.

Regards

Tones

[Charlie Veniot]

I cannot lay claim to discovering that filter in URL thing.  That's just me standing tall on @Anjar's (Ander's) shoulders.  It does send my imagination running wild.

[Charlie Veniot]

I wish.

I am always in a recursive and iterate/refine/tweak (as part of refactor/recycle/reuse) loop, so there's no such thing as a title or anything else that can stay static.  A unique sequence number that means nothing to me, that is the safest bet for this kid. Such a struggle otherwise. 

[David Gifford]

The beginnings of the TiddlyWiki Cinematic Universe

[Charlie Veniot]

Tidflix ?

[Charlie Veniot]

Okay, for anybody who wants to play, please find the attached JSON, a package of 9 small tiddlers ready for importing into your own test TiddlyWiki.

After you import the attached JSON tiddler, open it to import the individual tidders.

I've made a few changes, and will discuss them in a new video today, or tomorrow, or within the next few days.

In the meantime, please give it a spin and let me know what breaks or gets broken.

Cheers !

[Charlie Veniot]

Arg.  I should have mentioned.  The "ViewToolbar" button to add a UID to a tiddler is in the "More" button's menu.

I decided to make it a little bit more difficult to reach, because when a TiddlyWiki is publicly hosted on the web, we don't want viewers creating UID's on tiddler's and then grabbing UID permalinks, thinking they can directly open a TiddlyWiki to that particular tiddler.

I'll try to remember going over that in next video.

[ludwa6]

You're a wizard, Charlie!  Problem is, these magic spells invoked in an unforseen context can yield unexpected results. 

At least the first step -getting a PermaLink to a newly created tiddler- worked fine: see https://meta.tiddlyhost.com/#:[uid[3]] 

(NB: that one is #3, because tiddlers 1 & 2 got flubbed, because i forgot that Tiddlyhost needs me to save not just tiddler, but then the whole wiki... And so i ran the script twice on same tiddler, and now both 1&2 pull blanks).

But then at step two -changing the title of tiddler- it threw me this error message when i tried to save tiddler:

   Internal JavaScript Error: Uncaught TypeError: cannot read property '1' of undefined When relinking 'SolutionToProblemOfLinkRot'

Because the tiddler in step 1 above has a backlink to this other 'SolutionToProblemOfLinkRot' -but i don't know if it's that Tiddlyhost doesn't like the UID attribute, or has a problem with the "Relink" plugin i have installed. 

Anyway:  i will try some other tests tomorrow; just thought to share this one now, while it's fresh.  

ps: can't wait to see this next video! :-)

/walt

[Charlie Veniot]

Maybe I shouldn't call it Permalink.  The UID Permalink thing is not a replacement for Relink.  The UID Permalink thing is so that external references to a TiddlyWiki's specific tiddler never get broken by renaming that tiddler.

Relink does the job of making sure links to that tiddler within the same TiddlyWiki aren't broken.

UID Permalink is to make sure previously supplied external links to a tiddler (in an email, in Google Groups, in a blog, some other website, some other TiddyWiki on the web) do not get broken if the referenced tiddler gets renamed.

Where are you pasting the UID-Permalink copied to the clipboard ?

[Charlie Veniot]

I just renamed that Tiddler in your TiddlyWiki, and it isn't complaining.  If you can reproduce that error, please share the steps.

All of my tiddlers for this UID stuff are really benign, and I really can't understand how anything in there could cause an internal javascript error.

I'll hammer away at your TiddlyWiki a little bit more and see if I can duplicate that error.

On Saturday, May 8, 2021 at 4:10:40 PM UTC-3 ludwa6 wrote:

[Charlie Veniot]

Sidenote about setting up  URI-permalinks to some TiddlyWiki's tiddler in any other TiddlyWiki.

Using walt's TiddlyWiki as an example.  I notice a permalink in that TiddlyWiki to a Tiddler (SolutionToProblemOfLinkRot ) setup like this: ..tps://meta.tiddlyhost.com/#SolutionToProblemOfLinkRot

A URI-permalink, pasted as-is, in any tiddler will not work as a link (the square brackets mess things up) without some necessary fiddling.  For a URI-permalink to work in TiddlyWiki, it does need to be setup with an HTML anchor (maybe there are other ways I'm not thinking about).  For example:

<a href="https://meta.tiddlyhost.com/#:[uid[3]]">{{ SolutionToProblemOfLinkRot!!title }}</a>

BTW:  {{ SolutionToProblemOfLinkRot!!title }} so that Relink can find and change that tiddler reference should its title ever be changed.

On Saturday, May 8, 2021 at 4:10:40 PM UTC-3 ludwa6 wrote:

[Charlie Veniot]

I removed all of the UID tiddlers from your TiddlyWiki, and I get a consistent javascript error trying to rename the tiddler "PermaLinkCharlie".

The javascript error stops happening after I remove the "PermaLinkCharlie" reference from the text of your "SolutionToProblemOfLinkRot" tiddler.

It looks like Relink is giving a javascript error when trying to rename a tiddler (let's call it Tiddler A) that has a CamelCase title WHEN there are any other tiddlers that have Tiddler A's CamelCase title in any field that Relink scans.

On Saturday, May 8, 2021 at 4:10:40 PM UTC-3 ludwa6 wrote:

[ludwa6]

OK Charlie: can't say as i understand much of this, but the fact that you've been able to replicate that JavaScript error - saving to your local downloaded instance of mine (as you lack edit perms on the hosted instance) i presume- leads me to believe that it's not a Tiddlyhost thing, but rather something else.  Does this mean that Relink plugin doesn't like the fact of this new UID field, i wonder?  If so, that's a real problem, because Relink is for me an essential part of this mix.

I see it like this: one of TW's superpowers is the ability to create AND modify content (including tiddler titles: a vital content element) so dynamically. Problem is that the title field is in effect the primary key of these tiddler entities, so if you change that, you break a whole lot of links in a typically "intertwingled" wiki.  Relink plugin provides a fine solution to this problem internally... But as far as links-in from the ouside world are concerned, they must remain unchanged from the time that you publish them in perpetuity; this is precisely the ProblemOfLinkRot that drives my interest in using some other field that would survive a title change (or any change in other content) as the UID for published Permalinks.

So: gosh, this is vexing.  Your solution ticks a lot of boxes, Charlie: nice compact URL, smartly integrated in UI (your decision about nesting the control in such a way that is reasonably accessible to editors while obscuring it from the superficial view of more casual wiki-browsers strikes me as wise)... And the fact that it doesn't involve any modification of Core elements means it won't interfere w/ TW's nice easy upgrade mechanics, or complicate the lives of busy Core devs who would have to work around that somehow.

If we can get it to play nicely with Relink tho, then it's a non-starter, from my perspective.  Would love to hear your thoughts about this.

/walt

[Saq Imtiaz]

Suggest updating Relink to the latest version if you have not already done so.

[ludwa6]

W00t!  It works! Created a new tiddler, generated stable permalink from Charlie's UID solution -confirmed valid- then retitled & Relinked that tiddler, reloaded page in another browser w/ that same URL... And it landed on that same tiddler w/ the new title!

Thanks for the pointer, Saq -big thanks also to "flibbles" (Cameron?) for the amazing Relink plugin... And to you of course Charlie, for this brilliant solution to a long-standing problem. Bravo!

/walt

[PMario]

Hi,

TLDR; I think a "counter" used as UID will fail in the short run!

I did my post my concerns at github. https://github.com/Jermolene/TiddlyWiki5/discussions/5668#discussioncomment-715278

-mario

[Charlie Veniot]

It will always be unique within one TiddlyWiki.  Same as "Sequence numbers" in an Oracle Database.

The UID isn't really a counter.  It gets the the largest value of UID that exists among the tiddlers, then gives "this tiddler" the greatest value + 1.

So not a counter in the sense of a stored value in some field.  Maybe, for performance, I'll have to set things up that way someday, but not for now.

That said, this is only about unique and stable permalinks for Tiddlers in a TiddlyWiki, not about unique identification of tiddlers.

If you wanted to, you could create a bunch of tiddlers, and copy-paste the UID's among a bunch of them so that a UID permalink actually opens a group of related tiddlers, if that's something someone wanted.

To reiterate:  The UID's are not about unique identifiers for tiddlers.  That's a different problem, but one that I don't think needs solving.  Well, until it ever bites me in the caboose.  It hasn't yet, but my caboose is polished and ready for the bite at any time.

That aside ...

Say we both have TiddlyWiki's that use this UID thing I've developed.

And say I import one of your tiddlers into my TiddlyWiki, and I now have two tiddlers that have UID values of 55.  One of mine, and the one I imported from your TiddlyWiki.

Who cares?

Every URL link out in the wild that references my TiddlyWiki with UID 55 will now open with my tiddler and your tiddler.

However, my original intent for the UID permalink is not borked.  We can still easily get to my tiddler.

If your tiddler (UID=55) gets to be a real pain, then I'll strip the UID off of your tiddler that is in my TiddlyWiki.

Anyway, all of that said, this UID-permalink thing does what it is supposed to do in the problem scope I'm thinking, but is in no means meant to solve the problem scope of unique identifiers for all the tiddlers in the world.  That is not a problem I am interested in at all.

[ludwa6]

I understand, Charlie, how you are only trying to solve the problem w/in scope of a single wiki -and if that were a truly closed system, then indeed your solution solves the problem, if i'm understanding it correctly. 

However: i do see how easily tiddlers with the same ID could wind up in the same wiki in my case, where i've got a mitt-full of different editions that i am drag&dropping tiddlers across without due care, i suppose (mainly owing to that phenomenon Dave Gifford has described so well in his take on the "What is #TiddlyWiki" question.  See: it's Silly-Putty, as i said :-).

So, i have to ask: in case of UID conflict: is what would happen indeed as innocuous a condition as what you describe, i.e.: the two named-alike tiddlers would both display to the WWW browser who comes in on that link?  No other problem you can forsee arising out of that?

I do still think that the create date/time is sufficiently granular as to make the risk of similarly-coded tiddlers as near-zero as you could want, especially if combined with and/or hashed by some other factor.  I gather that this doesn't work for those pesky "$:/" tiddlers -but that's fine, since we don't want it to (and there's no way such a thing could happen by accident, right?)

/walt

[Charlie Veniot]

I'm an amateur security-type, but I'm more so a creative type.  I cannot imagine any scenario that would be a problem other than a UID-permalink opening unintended tiddlers in addition to the intended tiddler.

It should not matter any, but I've been a programmer for close to 40 years.  One of my expertise is relational database design.  So I feel ridiculously confident that this is perfect.  Small.  Lean.  Quick.  Simple.  Stable.  Robust.  Doesn't break anything.

But all of the experience/expertise in the world doesn't mean the scenario that makes me eat crow isn't just around the corner.

If you are planning to include me solution in the micro-chips for the rocket that will take you to Mars, don't do it.

The UID thing is just a field to help build stable permalinks.

One would likely never create a UID for every tiddler in his/her TiddlyWiki.  Only for those that one needs.  For example, to include a link to a specific tiddler in an email, or in a post here, or from anything on the web to the specific tiddler in your TiddlyWiki on the web.

The only way to get an unintended duplicate UID is for you to manually set duplicate UID's in a bunch of tiddlers, or to import from some other TiddlyWiki a tiddler with same UID.

Likelihood is small, maybe nil.  If it happens, it breaks nothing.  There is nothing anywhere that cares about a UID other than a link somewhere intended for a specific tiddler that might cause additional non-related tiddlers to also show.

The UID thing doesn't permeate into anything else.  The TiddlyWiki core knows nothing about UID's and doesn't care.  Plug-in's out there don't know about UID's and don't care.

If you want to complicate the UID-permalink thing with all sorts of dates, that's okay.  If it makes you feel better, then it isn't a waste of your time.  Anything more complicated/convoluted than plain sequence of numbers for UID would be a huge waste of my time.

Really, I'm begging for anybody to prove me wrong.  Prove that it breaks anything.

Not that there would be much value in the bragging rights.  I'm no super-hero, over here.

However, if you really believe that this simple thing will have huge negative consequences going forward, it would be really good to know earlier than later.  But prove it, for everybody's benefit.

[Charlie Veniot]

G'day Walt,

I did not clue into your statement:  "So, i have to ask: in case of UID conflict: is what would happen indeed as innocuous a condition as what you describe, i.e.: the two named-alike tiddlers would both display to the WWW browser who comes in on that link?  No other problem you can forsee arising out of that?"

"Named-alike" tiddlers.  As in tiddlers with same title.  When dragging "Tiddler A" from one TiddlyWiki to another, you really have to pay attention to the messages in the import mechanism.  It says when you are about to overwrite an existing tiddler.

What you talk about here is not a problem UID-permalinks solve.  That is a much greater problem than the simple thing solved by UID-permalinks.  To reiterate:  UID-permalink only keeps URL's to a specific tiddler from totally breaking when tiddlers get renamed.

Use UID-permalinks to keep URL's from breaking.  This other problem (uniqueness of tiddlers to prevent destruction of tiddlers upon import of tiddlers from some other TiddlyWiki) is more inline, I think, with what @PMario is looking into, which I personally think will involve a mess, attempting to give every tiddler a cross-TiddlyWiki unique ID akin to IP addresses or hardware-MAC-addresses.  Very bleurk and very uninteresting to me.

Other than something akin to IP/MAC addresses, you could make it such that any TiddlyWiki can only be created from one centralized spot which guarantees assigning every TiddlyWiki in existence a unique TiddlyWiki ID then gets attached to every Tiddler in that TiddlyWiki.  Infinity-bleurk.

On Sunday, May 9, 2021 at 11:26:13 AM UTC-3 ludwa6 wrote:

[ludwa6]

Sorry Charlie for my sloppy wording: by "named-alike," what i meant was two tiddlers having the same UID-permalink.  As for titles, i am very comfortable with the conflict avoidance measures built into the TW5 import process.

In any case, i am reassured by your answer(s- this last and the one above) that the risk involved in starting to use this thing -and then only for its intended purpose, as you say- is quite small.  The biggest risk i see is the sort of confusion that might arise if i send somebody a link to something, and what they get instead is a page with an extra tiddler (or few -see below) that would tend to throw into question the relevance of that link that the web user trusted enough to follow -especially if the unintended tiddler(s) appear larger and/or louder, maybe higher on the page (? something i'll only learn thru experience; am comfortable w/ that).

Still: i do suspect that i'm gonna somehow wind up with multiple tiddlers having the same number in that UID field, and that before very long i will wind up publishing some one(s) of those.  I say this because of two fundamental dynamics in my workflow:

1. I've got a TiddlyDesktop full of different TW instances that are cross-pollinating tiddlers with such careless abandon as to cause me some concern; and
2. I'm a huge believer in DRY (Don't Repeat Yourself), so once i've written something somewhere that i want to share, i would much rather share a link to it than write it again.

Can't say as (2) is much of a problem yet, because to this point i've got just a few small TW instances online -all of them tests, essentially, as i am still figuring out the best way to do this- but i do expect to be publishing & sharing real content in the very near future, at an ever-increasing rate of flow.  For all that, i think it safe to say: we'll cross that bridge when we come to it.

[Charlie Veniot]

Pff, no worries.  It is very easy to call things by various "names", and for the "intent" of words to match exactly all of one's thoughts related to the words, while meaning something entirely different to somebody else.

So context gets jumbled easily.

Imagine you place in all sorts of places all over the web a URL to a specific tiddler in one TiddlyWiki instance.

So many things can happen to break all of those links.  You might move the TiddlyWiki to a completely different host.  You might actually rename the TiddlyWiki itself.

So all kinds of worse problems than having the same URL suddenly pop open a few different unrelated tiddlers along with the intended one.  That is barely a blip in the scheme of things.

Easy enough to have some Tiddler in each TiddlyWiki that let's you know when you've imported some Tiddler that now has you with duplicate UID's.  At which point, go to the imported tiddler and delete its UID, giving it a new one only if you really need to.

If your workflow has you importing tiddlers incessantly between your TiddlyWikis, then you need to include in your workflow something that helps you with weeding your garden.

Or prepare to have a more complicated system for uniquely identifying your tiddlers and having longer and more complicated URL's.

I'm pretty sure somebody will come up with something much more perfect than what I've come up with, but there will be costs / trade-offs.

Only you know what kind of trade-offs you can live with.  (You won't know the trade-offs without trying the various possibilities.)

For me, this UID-permalink thing (or whatever I finally call it), is the good enough lean/mean/simple/robust/no-break-anything-else solution for me.  To each his/her own.

[TW Tones]

Try this; 

https://tiddlywiki.com/#:[description[Browser extension for Firefox]]

If you could rename and save this tiddler, it will still work until you modify the description or clone the tiddler.

Eureka!

I think I have finally come up with a simple, total, robust solution to permalinks, serial number, UID and GUID's not to put it in words and a plugin. 

I can write the specification if anyone wants to help, otherwise it will take a little longer

Regards

Tones

[Charlie Veniot]

The beauty of your link is that it is obvious what the link is for.  That really is a great thing.  Which I know I would eventually break because I am always slightly tweaking everything towards titles/names/descriptions that better fit changing scope/circumstances/you-name-it.

With a wee number, I'll never monkey around with it..  Which is the safety net I'm looking for: something stable that I know I will never tweak, tweaking being my nature when it comes to text.  I'm just as likely to change a description (scope of tiddler may have changed), or improved the wording or something.

I'm pretty stuck in a method similar to the Oracle Sequence Numbers I'm familiar with.  I've always been more comfortable with identifiers never based on real-world values.

[Anjar]

Ad the two latest post; these solutions are very close to the alternative permalink button suggested here: https://groups.google.com/g/tiddlywiki/c/QOzs3CVtosU/m/QZhVupmUBAAJ creating a permalink field with sluggified title + timestamp (always unique within a wiki), and keeping old versions so that links will continue to work

Best,

Anders