How can federated networks protect their users from impostor accounts?
I was recently approached by a user claiming to be the developer of Sync for Lemmy who wanted to be a moderator of the community I created, !syncforlemmy.
I was able to verify this user was indeed LJ Dawson as I knew where to contact him on Discord.
It is quite possible that an impostor user on another instance may be created, for example ljdawson@beehaw.org could easily be made.
Should Lemmy have a verified user marker for members who are of importance to any given community? Are there any other options to protect users against nefarious persons playing impostor?
I respect your position, but I think that as federated services gain popularity, the percentage of users who have the nous to validate any person decreases. Additionally, I can't image users being happy about answering large numbers of validation messages.
I like mastodon's solution. That is, validate a public identity, like a site, your site appears on your profile and it's only verified it you have proof inside the site itself.
On this specific case, the Sync team may have their lemmy users on the Sync site.
Let's say you trust billg@microsoft.com. Anyone can already create billg@scam-site.cn. You wouldn't trust that, why would you trust any other account you can't authenticate?
Like most impersonation questions, the answer is to verify identity through a known trusted source, as you did.
My initial thoughts on lemmy where that it was so strange we where going BACK to the trust everyone's servers and separate accounts model like that of Email.
Given its distributed nature there is nothing to protect against just setting up random squatter instances to quickly phish users with similar domains.
It also means if you setup on a small instance that later goes away you sort of lose part of your identity.
Some form of block chain distributed ledger that runs on the instances seems like it would address "SOME" of the issues.
Any of the instances could add you to the account ledger you could have a singular unique name, and the ledger could record which instance created you and what verification has ever been done to your account. You could then directly sign in to ANY instance as that account provided you had the credentials that matched the chain entry.
Verification providers could exist that SIGN your block chain entry with some form of validation and users and instances could chose which ones are recognized. This would be a way to add verification for those what WANT to be public not anonymous. All of which is optional.
The ledger could also track if any instances are known to be untrustworthy maybe and other instances could vote not to trust accounts generated by them.
Nobody else can have the username Izzy@lemmy.world so that is proof enough that I am me within lemmy. If you have some identity outside of lemmy then that identity should be verified outside of lemmy.
Nobody else can have the username Izzy@lemmy.world but Lemmy.world is only one of hundreds of instances on Lemmy.
I could go right now and make Izzy@<any other Lemmy instance> and depending on the client used, nobody would be able to tell the difference if that client doesn’t list the instance as part of the username. For example, both mlem and Memmy on iOS do not show full usernames by default. You just show up as Izzy to me. So Izzy@lemmy.world and Izzy@lemmy.ml would show as the same user to me.