Let’s get the AMAs kicked off on Lemmy, shall we. Almost ten years ago now, I
wrote RFC 7168 [https://www.rfc-editor.org/rfc/rfc7168], “Hypertext Coffeepot
Control Protocol for Tea Efflux Appliances” which extends HTCPCP
[https://www.rfc-editor.org/rfc/rfc2324] to handle tea brewing. Both Coffeepot
Control Protocol and the tea-brewing extension are joke Internet Standards, and
were released on Apr 1st (1998 and 2014). You may be familiar with HTTP error
418, “I’m a teapot”; this comes from the 1998 standard. I’m giving a talk on the
history of HTTP and HTCPCP at the WeAreDevelopers World Congress in Berlin later
this month, and I need an FAQ section; AMA about the Internet and HTTP. Let’s
try this out!
I think there are some user scripts folks are developing via browser extensions, but perhaps it’d be better to mainline the kind of features these ticket are tracking:
That’s a harder proposition than you might think. On the one hand, UUIDs are mathematically guaranteed to be universally unique, which is great. On the other hand, there has to be some way to go from a UUID to a particular post, which suggests a lookup table, but the federated nature of Lemmy basically makes that impossible, since there’s no assurance that any instance is aware of any other instance.
No, it only suggests an additional field in the Post table
since there’s no assurance that any instance is aware of any other instance
It already works like that, but slightly worse because post IDs aren’t the same across instances. If you search a newly-created community from another instance here, you just won’t find it until it’s synced, despite its URI being unique.
Thinking about it, it would be possible to have an URI for posts like post:${id}@instance.com, similar to how user URIs and community URIs are made. This way, you could open /post/1772651 on lemmy.world or post:1772651@lemmy.world on, idk, lemmy.blahaj.zone or something.
Another issue is whether the post from a remote instance is colocated on your local instance. It could be the case that your instance never observed the post, as no users on your local instance where first subscribed, to the remote community the post was summited to, before the post was published.
This is probably not the correct place to as this and I don’t know the inner workings of Lemmy, so forgive the stupid question. Does that mean, for an external post to get a programming.dev ID does someone in programming.dev instance to have been subscribed to the community the post was originally shared? Is that why I don’t see any posts at for example https://programming.dev/c/testbot42@voyager.lemmy.ml even though I see them at https://voyager.lemmy.ml/c/testbot42? If that’s the case, it sounds like an important limitation.
The first link you listed (viewing the remote community from our local instance) shows 0 subscribers from the sidebar. From my understanding, no one from our instance is then subscribed to that remote community, so our instance has no reason to index those posts. Although I could be wrong, and it could be that no one from our local instance is subscribed to any community on the remote instance. I’m unsure if only instance federation or community subscription is necessary for merrioring/indexing remote posts.
Here is the programming.dev link: https://programming.dev/post/424984
BTW: Is there a way to use instance links automatically when referring to another instance?
I think there are some user scripts folks are developing via browser extensions, but perhaps it’d be better to mainline the kind of features these ticket are tracking:
And the post on lemmy.world: https://lemmy.world/post/1086238
I think we need UUIDs so we can reference posts across instances
That’s a harder proposition than you might think. On the one hand, UUIDs are mathematically guaranteed to be universally unique, which is great. On the other hand, there has to be some way to go from a UUID to a particular post, which suggests a lookup table, but the federated nature of Lemmy basically makes that impossible, since there’s no assurance that any instance is aware of any other instance.
No, it only suggests an additional field in the
PosttableIt already works like that, but slightly worse because post IDs aren’t the same across instances. If you search a newly-created community from another instance here, you just won’t find it until it’s synced, despite its URI being unique.
Thinking about it, it would be possible to have an URI for posts like
post:${id}@instance.com, similar to how user URIs and community URIs are made. This way, you could open/post/1772651on lemmy.world orpost:1772651@lemmy.worldon, idk, lemmy.blahaj.zone or something.Another issue is whether the post from a remote instance is colocated on your local instance. It could be the case that your instance never observed the post, as no users on your local instance where first subscribed, to the remote community the post was summited to, before the post was published.
This is probably not the correct place to as this and I don’t know the inner workings of Lemmy, so forgive the stupid question. Does that mean, for an external post to get a programming.dev ID does someone in programming.dev instance to have been subscribed to the community the post was originally shared? Is that why I don’t see any posts at for example https://programming.dev/c/testbot42@voyager.lemmy.ml even though I see them at https://voyager.lemmy.ml/c/testbot42? If that’s the case, it sounds like an important limitation.
The first link you listed (viewing the remote community from our local instance) shows
0 subscribersfrom the sidebar. From my understanding, no one from our instance is then subscribed to that remote community, so our instance has no reason to index those posts. Although I could be wrong, and it could be that no one from our local instance is subscribed to any community on the remote instance. I’m unsure if only instance federation or community subscription is necessary for merrioring/indexing remote posts.At the minimum we could have a bot that responds with local links.
That’s a great idea.