A unique ID doesn't have to be long, opaque, and ugly like a UUID. All you need is a + . 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.
this post was submitted on 23 Jul 2023
4 points (100.0% liked)
Fediverse
42 readers
2 users here now
This magazine is dedicated to discussions on the federated social networking ecosystem, which includes decentralized and open-source social media platforms. Whether you are a user, developer, or simply interested in the concept of decentralized social media, this is the place for you. Here you can share your knowledge, ask questions, and engage in discussions on topics such as the benefits and challenges of decentralized social media, new and existing federated platforms, and more. From the latest developments and trends to ethical considerations and the future of federated social media, this category covers a wide range of topics related to the Fediverse.
founded 2 years ago
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.