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 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.
Similar to the way nostr does verification: https://www.name.com/blog/how-to-get-nostr-verified-on-a-custom-domain
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/
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.
There is DID which tries to do some of that. Many methods of registering your identifier have been registered (blockchain, bitcoin, crypto keys, purpose-built software, etc). Linking identities to some entity like this would prove ownership, but getting it implemented in places, encouraging users to use/check it (e.g. almost nobody GPG signs email), not trust similar usernames/domains, etc are all hard problems that having a spec alone doesn’t solve.
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.
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.
That’s doesn’t mean anything though.
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.
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.
No.
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.
A verified user marker? Maybe, like, a blue checkmark?
