It’s a matter of trust. A random instance can always lie and you can only determine “that was a malicious instance that was lying to me” in hindsight after it’s broken that trust. Since a malicious instance-runner can spin up new instances almost as easily as creating new fake accounts you end up with a game of whack-a-mole where the malicious party can always get a few bad actions through before getting whacked. Whereas if user account creation was recorded on a blockchain you don’t need to ever trust the instance in the first place. You can always know for sure that an account is X days old.
A malicious instance-runner could still spin up fresh instances and fake accounts ahead of time, but it forces them to do it X days in advance and now if they want to keep attacking they have a longer delay time on it. A community that’s under attack could set the limit to 30 days, for example, and now the attacker is out of action for a full month until their next crop of fake instances is “ripe.” As always with these sorts of decentralized systems there’s tradeoffs and balances to be struck. The idea is to make things as hard for malicious users as possible without making it harder for the non-malicious ones in the process. Right now the cycle time for the whack-a-mole is “as fast as the attacker wants it to be” whereas with a trustworthy account age authentication layer the cycle time becomes “as slow as the target wants it to be.”
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.
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
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.
It’s a matter of trust. A random instance can always lie and you can only determine “that was a malicious instance that was lying to me” in hindsight after it’s broken that trust. Since a malicious instance-runner can spin up new instances almost as easily as creating new fake accounts you end up with a game of whack-a-mole where the malicious party can always get a few bad actions through before getting whacked. Whereas if user account creation was recorded on a blockchain you don’t need to ever trust the instance in the first place. You can always know for sure that an account is X days old.
A malicious instance-runner could still spin up fresh instances and fake accounts ahead of time, but it forces them to do it X days in advance and now if they want to keep attacking they have a longer delay time on it. A community that’s under attack could set the limit to 30 days, for example, and now the attacker is out of action for a full month until their next crop of fake instances is “ripe.” As always with these sorts of decentralized systems there’s tradeoffs and balances to be struck. The idea is to make things as hard for malicious users as possible without making it harder for the non-malicious ones in the process. Right now the cycle time for the whack-a-mole is “as fast as the attacker wants it to be” whereas with a trustworthy account age authentication layer the cycle time becomes “as slow as the target wants it to be.”
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.