On the technical topic of renaming a domain of a Lemmy server… I think it is worth experimenting with the code.
This is unfortunately only possible if you still own the original domain. Think about it this way: if you could migrate domains without proving you own the original, then what’s stopping a bad actor from migrating any domain they want? Keep in mind that Federated servers rely on DNS to verify who’s who – they don’t have a backup system for deciding trustworthiness.
Yes, there’s no technical reason Lemmy has to rely on DNS to establish trust (aside from the fact that changing this would require a massive rearchitecting effort), but why shouldn’t it? It’s possible to switch to a different trust system (i.e.: public/private keypairs), but that doesn’t actually change the nature of the problem – people can still lose control of the private key and blow the whole system up (and, arguably, this is a lot more likely to happen than permanently losing a domain).
At minimum, I think it should be an option to try and keep the same login/passwords for users from the old install of Lemmy.
So, login credentials aren’t actually tied to the domain name at all. A user like example@lemmy.ml is simply known as example to the server internally. The server doesn’t particularly care if it lives at lemmy.ml or microsoft.com – if user example shows up and gives the right password, they’re allowed to log in. What I’m trying to say is that – assuming that the user database isn’t destroyed – login info would probably carry over without any special effort needing to be taken at all.
But even that could prove tricky if a particular domain changed underllying ownership more than once - and user@domain became rewritten by an entirely different person. I guess in the real-world people do often get mail for previous residence of a house.
The identity problem you allude to is not exclusive to this scenario. Let’s use lemmy.ml as an example: where did the domain come from? The Mali government. Does this mean that the Mali government owned lemmy.ml before it became associated with the Lemmy project? At the risk of oversimplying: yes, pretty much! Prior to 2019, the government of Mali could have created “fraudulent” Fediverse posts under your username, /u/[email protected].
With that being said, it’s kind of a silly concern. Despite being partially distributed, Lemmy is not a read-only database (i.e.: not a blockchain). There’s nothing stopping the current domain owner from more-or-less completely undoing vandalism from prior domain owners by simply asking the other servers to delete fraudulent content. Keep in mind that the domain is not the server; the original operator keeps all of the original data even if they lose the rights to host that data under the original domain.
My biggest concern is legality because Lemmy claims to support privacy. I honestly think it’s a bad idea to claim privacy because you run into so many problems. If the user never knows that their lemmy instance changed names and can’t find it again, etc.
This is not a problem unique to Lemmy. If Google forgets to pay for gmail.com, then suddenly a lot of email addresses become untrustworthy. This isn’t a privacy issue because your old emails don’t leave Google’s servers. It is a trust issue, however, since the new owners can now impersonate anygmail.com address and receive any new email that was intended for the original owner.
Not to downplay how catastrophic this scenario would be… but I don’t think there’s any law on the books which would legally obligate Google to operate gmail.com until the end of time. Nothing lasts forever and eventually gmail.com won’t be controlled by Alphabet Inc. anymore – that’s just how time works. Those bothered by this uncertainty can instead choose to host their own mail server (or Lemmy instance) on their own domain – this won’t last forever, either… but at least you’re in control now.
Especially on technical topics, 15+ years of having Reddit keep messages from deleted user accounts offered a lot of great search engine hits. With Lemmy, a person moving to a different instance and deleting their account, so much content is going to get black-hole in favor of 50 instances having copies of a meme post or trivial website link - and solid original content (often in comment discussions) gets removed.
Just FYI: Much like Reddit, comments continue to exist even when the author deletes their account. The user must explicitly delete each individual comment before deleting their account if they want it all taken down. I don’t really get this complaint in the first place, actually… surely both kinds of content would get lost when a user deletes all of their data, right? There’s no button that says “delete all of my stuff, except for the shitposts”.
This is unfortunately only possible if you still own the original domain. Think about it this way: if you could migrate domains without proving you own the original, then what’s stopping a bad actor from migrating any domain they want?
I’m suggesting a whitelist, that each peer has to put in a substitute list of vlemmy.ml==vlemmy.ml to re-federate.
Much like Reddit, comments continue to exist even when the author deletes their account.
I’m suggesting a whitelist, that each peer has to put in a substitute list of vlemmy.ml==vlemmy.ml to re-federate.
I don’t see any inherent problem with that suggestion, though it does create something of a sticky situation with things like canonical links. It also kind of goes against what I’ve so far perceived as a “low-maintenance” operations ethos from the project maintainers, so I’m not totally sure if they’d greenlight it. Technically quite doable, though.
EDIT: scratch that, I now see that the stated intent is to retain anonymized comments as Reddit does, but that the functionality is not yet implemented in the main code release for reasons that seem triage-related rather than a change in plans.
The intention is to routinely purge all content of users who delete their account. In fact, there are open GitHub issues about serious performance problems in executing this code, even with a relatively small amount of content. Developers in the past 2 days have commented on this and made no mention of intention to retain content.
This is unfortunately only possible if you still own the original domain. Think about it this way: if you could migrate domains without proving you own the original, then what’s stopping a bad actor from migrating any domain they want? Keep in mind that Federated servers rely on DNS to verify who’s who – they don’t have a backup system for deciding trustworthiness.
Yes, there’s no technical reason Lemmy has to rely on DNS to establish trust (aside from the fact that changing this would require a massive rearchitecting effort), but why shouldn’t it? It’s possible to switch to a different trust system (i.e.: public/private keypairs), but that doesn’t actually change the nature of the problem – people can still lose control of the private key and blow the whole system up (and, arguably, this is a lot more likely to happen than permanently losing a domain).
So, login credentials aren’t actually tied to the domain name at all. A user like
example@lemmy.ml
is simply known asexample
to the server internally. The server doesn’t particularly care if it lives atlemmy.ml
ormicrosoft.com
– if userexample
shows up and gives the right password, they’re allowed to log in. What I’m trying to say is that – assuming that the user database isn’t destroyed – login info would probably carry over without any special effort needing to be taken at all.The identity problem you allude to is not exclusive to this scenario. Let’s use
lemmy.ml
as an example: where did the domain come from? The Mali government. Does this mean that the Mali government ownedlemmy.ml
before it became associated with the Lemmy project? At the risk of oversimplying: yes, pretty much! Prior to 2019, the government of Mali could have created “fraudulent” Fediverse posts under your username, /u/[email protected].With that being said, it’s kind of a silly concern. Despite being partially distributed, Lemmy is not a read-only database (i.e.: not a blockchain). There’s nothing stopping the current domain owner from more-or-less completely undoing vandalism from prior domain owners by simply asking the other servers to delete fraudulent content. Keep in mind that the domain is not the server; the original operator keeps all of the original data even if they lose the rights to host that data under the original domain.
This is not a problem unique to Lemmy. If Google forgets to pay for
gmail.com
, then suddenly a lot of email addresses become untrustworthy. This isn’t a privacy issue because your old emails don’t leave Google’s servers. It is a trust issue, however, since the new owners can now impersonate anygmail.com
address and receive any new email that was intended for the original owner.Not to downplay how catastrophic this scenario would be… but I don’t think there’s any law on the books which would legally obligate Google to operate
gmail.com
until the end of time. Nothing lasts forever and eventuallygmail.com
won’t be controlled by Alphabet Inc. anymore – that’s just how time works. Those bothered by this uncertainty can instead choose to host their own mail server (or Lemmy instance) on their own domain – this won’t last forever, either… but at least you’re in control now.Just FYI: Much like Reddit, comments continue to exist even when the author deletes their account. The user must explicitly delete each individual comment before deleting their account if they want it all taken down. I don’t really get this complaint in the first place, actually… surely both kinds of content would get lost when a user deletes all of their data, right? There’s no button that says “delete all of my stuff, except for the shitposts”.
Your Gmail example is very funny because if anyone actually tried to do it, they would effectively DDoS themselves.
Governments could do it effectively.
I’m suggesting a whitelist, that each peer has to put in a substitute list of vlemmy.ml==vlemmy.ml to re-federate.
That is NOT how the testing code of lemmy_server tests things, nor how the GitHub front page advertises Lemmy.
I don’t see any inherent problem with that suggestion, though it does create something of a sticky situation with things like canonical links. It also kind of goes against what I’ve so far perceived as a “low-maintenance” operations ethos from the project maintainers, so I’m not totally sure if they’d greenlight it. Technically quite doable, though.
I meant to say vlemmy.ml=vlemmy.net in example
I’ll cite my source, then: https://github.com/LemmyNet/lemmy/commit/1de7a08d973c1079b36e13e087960cc5cd1b345c .EDIT: scratch that, I now see that the stated intent is to retain anonymized comments as Reddit does, but that the functionality is not yet implemented in the main code release for reasons that seem triage-related rather than a change in plans.
You cite a conversation from November 4, 2022.
A Febuary 6, 2023 comment from developers https://github.com/LemmyNet/lemmy/issues/2624#issuecomment-1419559651 says “The correct way privacy-wise, is to delete your account through your profile settings, which overwrites all your content to remove any info.”
The intention is to routinely purge all content of users who delete their account. In fact, there are open GitHub issues about serious performance problems in executing this code, even with a relatively small amount of content. Developers in the past 2 days have commented on this and made no mention of intention to retain content.