I am not sure what is correct to put in [kbin-core/issues](https://codeberg.org/Kbin/kbin-core/issues) without cluttering it up with somewhat speculative requests. I have no idea how to implement this or whether it is possible. So I will post here?...
A unique ID doesn’t have to be long, opaque, and ugly like a UUID. All you need is a <locally-unique-number> + <originating-intance-domain>. Add a prefix to distinguish its type from other things at that domain, and you’ve got an ID that’s unique, readable, and easy to troubleshoot.
that would certainly make it nicer! I do not know about the limits of randomness. As long as it would be enough to avoid all the instances that will ever exist accidentally bumping into each other’s content.
We already have the IDs you mention in the URLs though, right? In the post I used as the example, the author’s home instance URL for the item is https://lebowski.social/post/12337
<locally-unique-number> = 12337
<originating-intance-domain> = lebowski.social
To make things really simple (at least for the end user), instead of having a UUID, you just have a way that can be easily learned to transform the URL by copy/paste by hand, and would also lend itself to programmatic manipulation:
check out [this post](/local/lebowski.social/post/12337)
I still am thinking there must be some reason why this isn’t done because it seems very obvious. Either it is more difficult to implement across federation than I am guessing, or there are use cases I am not considering.
We already have the IDs you mention in the URLs though, right? In the post I used as the example, the author’s home instance URL for the item is https://lebowski.social/post/12337
Yes, the needed information is already present in those URLs, but as URLs, they instruct the browser to leave the current site and visit the origin instance, which is not what we want. To get the desired behavior, we would want:
Those two fields combined in a distinct format (not easily confused with a URL).
An obvious way for readers to get the global ID for any message they see (perhaps with the community/magazine name embedded, to make finding the source forum easy for humans who see it)
Apps (including the web interface) displaying each global ID as a link to the nearest copy of its message (local copy when available, origin instance copy as a fallback)
An easy way to manually navigate to any message by entering its global ID
a way that can be easily learned to transform the URL by copy/paste by hand
A unique ID doesn’t have to be long, opaque, and ugly like a UUID. All you need is a <locally-unique-number> + <originating-intance-domain>. Add a prefix to distinguish its type from other things at that domain, and you’ve got an ID that’s unique, readable, and easy to troubleshoot.
that would certainly make it nicer! I do not know about the limits of randomness. As long as it would be enough to avoid all the instances that will ever exist accidentally bumping into each other’s content.
We already have the IDs you mention in the URLs though, right? In the post I used as the example, the author’s home instance URL for the item is
https://lebowski.social/post/12337<locally-unique-number>=12337<originating-intance-domain>=lebowski.socialTo make things really simple (at least for the end user), instead of having a UUID, you just have a way that can be easily learned to transform the URL by copy/paste by hand, and would also lend itself to programmatic manipulation:
check out [this post](/local/lebowski.social/post/12337)I still am thinking there must be some reason why this isn’t done because it seems very obvious. Either it is more difficult to implement across federation than I am guessing, or there are use cases I am not considering.
Yes, the needed information is already present in those URLs, but as URLs, they instruct the browser to leave the current site and visit the origin instance, which is not what we want. To get the desired behavior, we would want:
Yep. That’s the kind of ID we want. :)