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.

  • Skull giver@popplesburger.hilciferous.nl
    6·
    7 天前

    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.

      • Skull giver@popplesburger.hilciferous.nlEnglish
        1·
        1 天前

        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 Update with new text contents belongs to the same server that once Created 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.

    • daniskarma@lemmy.dbzer0.com
      2·
      6 天前

      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.

      • Skull giver@popplesburger.hilciferous.nlEnglish
        2·
        1 天前

        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).