I wish Lemmy would make instance agnostic post and comment links. With the current system it’s impossible, as every instance assigns its own number. Instead, links could be in the form https://your instance/comment/number@hostinstance
Done. I hadn’t seen that issue before, not that I really dig into github all that much.
However the issue is somewhat outdated. We do have instance agnostic links for communities and users now, and we have since I joined, which was less than 2 weeks after this issue was posted. We may need a new updated issue that focuses on posts and comments specifically.
It could just be a GUID. The community’s host instance assigns a GUID (which by definition is unique in all GUIDs) and then when sending the post or comment out to federate to other servers it includes the GUID for the other instances to use.
But I still need a host to know where to retrieve the comment from. A GUID on its own doesn’t help if my instance hasn’t seen that comment. So if there’s a host already on the comment id, why bother with an ugly long GUID?
I don’t think there’s a need for a GUID, in fact it would be quite difficult - every instance would have to check with every other instance to ensure that the ID’s are unique. Meanwhile, if we just have the federated host picking a number, then every other host uses that number followed by @hostinstance, we don’t need cross-checking but still have unique ID’s for everything.
For example, https://lemm.ee/comment/123456 would be a different comment to https://lemmy.nz/comment/123456 (as it is currently also), but the first comment could be found on the 2nd instance as https://lemmy.nz/comment/123456@lemm.ee.
But they can only be globally unique if each instance has its own range of unique ID’s, otherwise they’ll have to check with the other instances to make sure the GUID they want to use hasn’t already been used. With new instances spinning up all the time you can’t really manage this.
I agree that the @instance provides a little more info, and it fits nicely in line with how user profile and community URLs are handled.
There was also a github issue report about putting the title in the URL, like reddit does, but I think this goes too far - lemmy has the ability to change the title and putting the title in the URL would just confuse things or lead to exploits (eg you put naughty words in the title then change it afterwards, but the URL still has the original title).
GUIDs are globally unique because of maths and clocks not because of checking. When you generate a GUID you can be confident no GUID the same has ever been generated using that algorithm, ever, anywhere, and you don’t have to check.
However, someone pointed out you could run a malicious instance that copies GUIDs from other instances and federates them out to deliberately cause issues, so this idea is out.
I wish Lemmy would make instance agnostic post and comment links. With the current system it’s impossible, as every instance assigns its own number. Instead, links could be in the form
https://your instance/comment/number@hostinstance
The GitHub issue is here, you could put a thumbs up reaction on it, and also subscribe to the issue to get updates about it
https://github.com/LemmyNet/lemmy/issues/2987
Done. I hadn’t seen that issue before, not that I really dig into github all that much.
However the issue is somewhat outdated. We do have instance agnostic links for communities and users now, and we have since I joined, which was less than 2 weeks after this issue was posted. We may need a new updated issue that focuses on posts and comments specifically.
deleted by creator
That works for a Lemmy user, but it doesn’t help for sharing on other platforms or for users discovering content elsewhere
deleted by creator
There are a few extensions, but I don’t think there’s one extension to rule them all yet:
It could just be a GUID. The community’s host instance assigns a GUID (which by definition is unique in all GUIDs) and then when sending the post or comment out to federate to other servers it includes the GUID for the other instances to use.
I’m a massive fan of GUIDs, too, but you’d have no protection from rogue instances reusing GUIDs of existing posts…
But I still need a host to know where to retrieve the comment from. A GUID on its own doesn’t help if my instance hasn’t seen that comment. So if there’s a host already on the comment id, why bother with an ugly long GUID?
I don’t think there’s a need for a GUID, in fact it would be quite difficult - every instance would have to check with every other instance to ensure that the ID’s are unique. Meanwhile, if we just have the federated host picking a number, then every other host uses that number followed by
@hostinstance
, we don’t need cross-checking but still have unique ID’s for everything.For example,
https://lemm.ee/comment/123456
would be a different comment tohttps://lemmy.nz/comment/123456
(as it is currently also), but the first comment could be found on the 2nd instance ashttps://lemmy.nz/comment/123456@lemm.ee
.No they wouldn’t, that’s the point of a GUID - they are globally unique.
However, I’ve changed my mind. For the nice-URL factor, having @instance is better and provides extra info.
But they can only be globally unique if each instance has its own range of unique ID’s, otherwise they’ll have to check with the other instances to make sure the GUID they want to use hasn’t already been used. With new instances spinning up all the time you can’t really manage this.
I agree that the @instance provides a little more info, and it fits nicely in line with how user profile and community URLs are handled.
There was also a github issue report about putting the title in the URL, like reddit does, but I think this goes too far - lemmy has the ability to change the title and putting the title in the URL would just confuse things or lead to exploits (eg you put naughty words in the title then change it afterwards, but the URL still has the original title).
GUIDs are globally unique because of maths and clocks not because of checking. When you generate a GUID you can be confident no GUID the same has ever been generated using that algorithm, ever, anywhere, and you don’t have to check.
However, someone pointed out you could run a malicious instance that copies GUIDs from other instances and federates them out to deliberately cause issues, so this idea is out.
Ah fair, I guess I misunderstood GUID’s.