Ask Lemmy
A Fediverse community for open-ended, thought provoking questions
Please don't post about US Politics.
Rules: (interactive)
1) Be nice and; have fun
Doxxing, trolling, sealioning, racism, and toxicity are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them
2) All posts must end with a '?'
This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?
3) No spam
Please do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.
4) NSFW is okay, within reason
Just remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either [email protected] or [email protected].
NSFW comments should be restricted to posts tagged [NSFW].
5) This is not a support community.
It is not a place for 'how do I?', type questions.
If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email [email protected]. For other questions check our partnered communities list, or use the search function.
Reminder: The terms of service apply here too.
Partnered Communities:
Logo design credit goes to: tubbadu
view the rest of the comments
Thank you for writing the explanation! I still think that this doesn't need a blockchain. Instances could broadcast user creation, so each instance could validate user age on its own (or ask other trusted instances when they first "saw" that user).
Fundamentally, blockchain solves the problem that there is no central source of trust, but in the Fediverse people necesarily trust the instance that they sign up, so a blockchain can't add much in my opinion.
This specific situation isn't about the users trusting their instance, though. This is about your instance trusting what other instances are saying. If I wanted to run a community that had a rule prohibiting accounts that were less than 30 days old from posting, and someone with an account on another instance posts there, who do I check with to find out how old that account is? The instance the account belongs to could be lying.
Having a shared database that everyone's keeping a copy of and broadcasting updates to could solve that, but there's going to be a bunch of fiddly problems you'll need to solve. If you discover that your database has differences from some other instance's database, who's "authoritative?" How do you stop it from being spammed, forcing every instance owner to maintain gigabytes of useless fake records? Once you've solved all those problems I think you'll discover that you've ended up building something that's essentially your own blockchain, since this is exactly the sort of thing that blockchains were created for in the first place. So might as well use an existing one that's done all the hard work for you. Not to mention that the more people that are using the same blockchain the more secure against tampering it gets, everybody using it contributes to its security.
More generally, there are some situations where it would be nice if you didn't have to trust your own instance either that using a blockchain to record account information would allow for. For example, you could generate and attach a public/private key pair to your account. Someone else could then look it up and use it to send you a private message that's end-to-end encrypted in a way that even the admins of your instance wouldn't be able to read or tamper with. As far as I'm aware the Fediverse doesn't have a private messaging protocol built into it at all, let alone one that's end-to-end secure. Or if your instance abruptly shuts down you could use that key to add a note pointing to your new account on some other instance, without needing the old instance runner to do anything. This sort of thing would require support to be built into Fediverse clients, it's not simple, but if the clients are well written the user doesn't need to worry about any of that complexity themselves.