My home instance is shutting down soon.
https://lemm.ee/post/65824884.
I am slightly unclear about what the instance admin meant.
Because of how Lemmy is built, everything posted on lemm.ee will still be accessible from other instances, even after we go offline.
How are other Lemmy instance able to access the content from the post-shutdown lemm.ee?
Do all the other Lemmy instances keep a copy of the content from lemm.ee?
If so, wouldn’t that be rather taxing on each Lemmy instance? (since they have to keep a copy of all the content from all instances they federate with).
I tried reading this up by researching on Lemmy federation, but this is still unclear to me.
Note that because of the way federation works, the domain can be bought by someone else who can then use the connections and links to lemm.ee images and posts to peddle spam and other nonsense. It’s not a problem as long as the domain name stays under control of the lemm.ee admins, but if they don’t renew their registration then anyone can pretend to be the old lemm.ee server.
Best for lemm.ee users to delete images from their posts and comments now so whoever grabs the domain in a year or so can’t use it to inject weird shit into your old posts as easily. Of course they still can create new accounts for all.the old account names and post in your name if they want, but the user private keys should prevent that for individual posts if the other server software is smart enough to validate them.
While they could put up weird images, they can’t change posts without everyones private keys.
I don’t see why not. Based on the spec, a server submits a request signed by a keyId which the receiving server caches or obtains, but the new server is also queried for the keys belonging to the actor. You cannot reuse the old key IDs (probably) because it’ll stay in the cache, but you can just add new keys of your own.
Step 10 of the key verification algorithm explicitly instruct the server to ignore the old key and fetch a new one, in case the other server has done a blind key rotation.
In other words, the ActivityPub spec only verifies that an account was the source of a message at the time a server submitted or forwarded an event. It does not validate that an
Updatewith new text contents belongs to the same server that onceCreated the object.Of course, I expect ActivitiyPub software to (mis)implement this spec in different ways. Some software will be protected against domain hijacking, others will leave domains once registered completely useless in the future for common actor names in ActivityPub.
I was misremembering something here, mastodon always keeps old keys iirc, but lemmy caches them temporarily iirc.
I didn’t know that. That seems to be a very bad decision.
I would have thought there was some sort of private public key involved in instance authentication.
There is, but the protocol is designed that you can’t buy a domain for a month, set up a server, and then let it expire, leaving it unable to use ActivityPub for decades after because you posted a few things to Mastodon with popular usernames.
There is public/private key authentication, but the server is queried for its current keys when verifying content. This allows lemmy.ml to forward lemmy.dbzer0.com content to any other server without knowing the private key, because the receiving server will call back to the original server (if they key is not already cached) and use the user’s public key to verify the message.
Once the domain expires and a new person buys the domain, that new person is in charge of what keys a domain lists or not. That, combined with the fact blind key rollover is permitted, leaves it up to programmers of individual servers to decide if they accept the new keys or not (the spec says they should).
To shreds
Federation means that when anything happens on one instance (post, comment, whatever), that instance will also inform other instances of this. Which other instances? The ones that have at least one user who has indicated they are interested in that kind of activity (on Lemmy mostly: by subscribing to the community).
So already now you can see eg my instance’s copy of a lemm.ee community at https://discuss.tchncs.de/c/[email protected] and this will not disappear just because lemm.ee goes down. It’s stored in my instance’s database. But it will no longer be possible to post or comment there because that will no longer federate to other instances.
It’s not guaranteed that all of lemm.ee will be accessible elsewhere. Some communities might not have (always had) subscribers from other instances, which would mean no other database has stored those parts.
Do all the other Lemmy instances keep a copy of the content from lemm.ee?
Yes, but it only keeps text and links, any images uploaded to lemm.ee will be lost. Any community in lemm.ee will still be visible but nobody outside of your instance will see anything you post there so they’re effectively dead.
nobody outside of your instance will see anything you post there
So you are saying that if let’s say a user from
lemmy.worldmakes a post to the post-shutdownlemm.eecommunity, only users withinlemmy.worldcan see the content? Did I understand that correctly? Basically each instance has a "copy of lemm.ee's community, andlemm.ee` is acting as the main distributor of events between these “isolated communities”.Is there any indication for the
lemmy.worldpeople to notice that the instance hosting the community is gone? Wouldn’t there be cases where users continue posting to a community who’s instances have shutdown, without realizing that they are not visible outside?Exactly, yes.
Is there any indication for the lemmy.world people to notice that the instance hosting the community is gone?
I don’t think there is but I remember the lemmy devs saying they’ll add a warning at some point when a community can’t be reached.
The way ActivityPub federation works, once an instance is “linked” (like lemm.ee linking with lemmy.world, lemdro.id, etc), the instance will now send them an event once a post is made or something like that.
For example:
- lemm.ee —links–> lemmy.world
- lemm.ee user makes a post A
- lemm.ee —notifies–> lemmy.world
- lemmy.world makes a copy of post A.
So yes, every Lemmy instance stores copies of new data from other instances once they link.
every Lemmy instance stores copies of new data
What about the old data? Are they also stored retroactively once the link happens?
And about the linking, from what I gather, (taking your example) as long as any one user from
lemmy.worldfrom retrieves posts fromlemm.ee, or if they subscribe to it, the “link” will happen. Is that correct?Is there anyway to verify that the data is persisted on
lemmy.world? As long as the post/community is visible right now fromlemmy.world, would it be indication that it will be there even afterlemm.eeshuts down?Basically, I am mainly concerned whether my previous content on
lemm.eewill be persisted.When instances federate, they don’t send old content. Old content will be fetched if a user tries to open it, for example by clicking a link to an old post (on some apps) or pasting its url into the search box.
The data copied to the other instance will stay on the other instance, unless manually deleted for some reason.
So if a brand new instance is started, it does not retroactively receive any content from other servers. Only ones that were connected by a link at the time content was posted will have a copy, essentially.
To know which posts will be kept on different servers, look up your own username, e.g. https://lemmy.ca/u/[email protected]
Will images uploaded to lemm.ee be federated with the other Lemmy servers, or will they be permanently deleted?
I’ve heard conflicting answers to this question, and I’d like to get a definite answer.
afaik those get deleted. However there shouldn’t be many images uploaded to that server specifically because the instance admins were really hesitant about ever opening image uploads much. They often advocated for using another 3rd party for image hosting.
It’s conflicting because it depends™. By default Lemmy is configured to mirror images by remote instances so as to not overwhelm them with traffic. But most instances turn that off because of the storage cost.
