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 [email protected] 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?
Should Lemmy have a verified user marker for members who are of importance to any given community?>
No, everyone is equal here and I want to keep it that way. I don’t want this to be twitter.
Are there any other options to protect users against nefarious persons playing impostor?>
You mean besides the one where you just successfully figured out the person was legit through verifying them?
No, it should be up to the community mods to verify someone is legit not the app itself.
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.
If you have even just a bit of fame… you more than likely have a website that show all the way to contact you… so this is a non-issue.
Example, me: https://thefrenchghosty.me/contact/
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.
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.
Is Keybase still popular (if it ever was) these days? I know at some point it was an alright way to verify a collection of your online identities with each other.
It looks like they had Mastodon integration however I can’t seem to find anything about linking a keybase account with Mastodon anymore, and their integration guide looks to be a dead link now.
This is where systems like NOSTR could help out. You could also verify somebody’s identity by checking their public key against their NOSTR identity. There are tons of good ideas in this area. At the end of the day, it will always involve some work but it’s not an impossible issue to solve. I would love it if the fediverse incorporated access and validation of keys from NOSTR.
No.
Let’s say you trust [email protected]. Anyone can already create [email protected]. 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.
Nobody else can have the username [email protected] 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.
That’s doesn’t mean anything though.
Nobody else can have the username [email protected] 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 [email protected] and [email protected] would show as the same user to me.
That is a deficiency in those implementations, not in the platform itself.
Unless the Lemmy devs create their own app, the vast majority of users are going to use third party apps like mlem and Memmy.
So it’s still a problem with the platform if the username databases for instances don’t validate against each other to prevent reuse and impersonation.
A verified user marker? Maybe, like, a blue checkmark?