ActivityPub is "sufficiently decentralized" in my book. I don't consider decentralizing name registry a requirement — DNS is a sufficiently decentralized name registry we already have and know how to manage. I don't consider cryptographic keys a viable form of identity because they absolutely inevitably leak into the UX and hopelessly ruin all of it. To add to that, as someone who has worked in a real-world popular social media company, I can assure you that account recovery is not something "nice to have", but rather a hard requirement — and it's impossible, by design, in a public-key-crypto-based system.
Odd you should mention, this project is being built as sort of the cryptographic foundations of another protocol adjacent to the idea of worker solidarity.
> account recovery is not something "nice to have", but rather a hard requirement — and it's impossible, by design, in a public-key-crypto-based system.
Can you give some examples of acceptable account recovery systems?
Do they involve either giving up privacy (with government-issued IDs, for example), or delegating the problem to another system like email?
If email is an acceptable system to base account recovery on, then couldn't users just store their recovery private key in an email sent to themselves (or saved as a draft)?
> Do they involve either giving up privacy (with government-issued IDs, for example)
Sometimes, yes. But then presenting a government-issued ID is kinda inescapable — this is also a requirement for participation in crypto. You can't buy cryptocurrency without KYC. And you sure as hecc need some sort of tokens for these "fully decentralized" identity schemes because they inevitably are a cryptocurrency with extra functionality duct taped to the side.
> or delegating the problem to another system like email?
That's also an option.
> If email is an acceptable system to base account recovery on, then couldn't users just store their recovery private key in an email sent to themselves (or saved as a draft)?
And if their email account is broken into and the private key gets into someone else's hands, how exactly do they prevent potential impersonation without starting a whole new online life, ideally without their followers even noticing?
> these "fully decentralized" identity schemes ... inevitably are a cryptocurrency with extra functionality duct taped to the side.
I've not actually used BrightID[0], but my understanding is that you can use it without needing to buy any of their tokens. So it's more like a web-of-trust identity scheme with a cryptocurrency duct taped to the side. (Also I think that buying cryptocurrency without relying on a government-regulated business is probably more common than you're suggesting).
> if their email account is broken into and the private key gets into someone else's hands
This is the same problem that all existing social networks (and probably some government services in some countries) are already vulnerable to. I think a decentralised social network can offer meaningful improvements in user freedom and privacy without also solving every other online/computer security problem in the world.
> starting a whole new online life
In the case of BrightID, you can set up "social recovery"[1] which uses the social graph to allow you to regain access to your account.
There are a lot of issues with DNS - fights over limited names/squatting, per-country rules depending on TLD, unreliability of registrars (see the thread every 6mo "what registrar should I use" with horror stories about every single one), and the fact that once you've chosen a name it's hard to change. I'm not going to claim that cryptographic keys don't leak into UX because I don't know, but I'm not sure what experience you have to guarantee they do. The only system I know of that heavily relies on keys is cryptocurrencies, which aren't social networks and are only one example (and TBH seem to be doing alright in the UX department).
Account recovery essentially means you have a backup method to gain access if you lose your key or it's stolen. There are many ways to accomplish this, many of which work fine with public key crypto systems: 1. If you're just worried about losing it, backing up your primary key, 2. A backup master key/subkey system with revocation, 3. An opt-in service that manages network access for you (including your keys) and provides human recovery mechanisms. The latter is essentially what you get with non-crypto methods but allows decentralization.
> and it's impossible, by design, in a public-key-crypto-based system.
I think anyone believing otherwise should spend a few months as front-line tech support dealing with forgotten passwords and then (perhaps) reconsider.
> and it's impossible, by design, in a public-key-crypto-based system
You can walk back on the security preventing account recovery by giving your keys to a third party.
This is essentially the same as not having the security guarantees in the first place - and it's optional and you can choose who to give the keys to!
So how do you do it? Who would override the authentication mechanism and reset your key? How would that person authenticate? How would you keep your identity when your public key is your identity? How would you stop someone using your leaked private key to impersonate you?
a simple mechanism is using a smart contract to map your key (0x123) to an identity (@alice). the contract can allow you to transfer that identity to a different key (important for key rotation) and also to set up a recovery key that is also authorized to transfer the key if the primary key is lost.
So it's just pushing the problem a bit further away by hiding your real key. See, you have to be able to recover your account even if you've lost every single of your electronic devices. Every one of them. Including flash drives. No data. No backups. None. Zero bytes.
The fundamental problem with keys is that they are files. You can't exactly memorize one, not without torturing yourself. You have to store them somewhere extremely reliably but at the same time completely secretly.
The point here is that self-hosting is _possible_. Most users are almost certainly going to just let a third party host their keys. But if keys are identity primitive at the protocol level, then the protocol prevents full centralized platform capture, similar to email interop.
The key being the identity still has the problem of not being changeable, no matter how you spin it.
Self-hosting is possible with ActivityPub as well, but without sacrificing the user-friendliness. I can already see someone saying "what do you mean I have to start a new account after my private key leaked".
> See, you have to be able to recover your account even if you've lost every single of your electronic devices. Every one of them. Including flash drives. No data. No backups. None. Zero bytes.
Well 12-word mnemonics help here right? It's imperfect, but certainly is as good as most 2FA implementations use for account recovery.
There are alternative approaches people are trying too. For example Coinbase[1] is trying a MPC approach where you delegate two (or more?) people known to you and if they agree it can recover your account.
But this is done using secure multi-party computation so the unencrypted key is never stored - it is only decrypted by the person doing the recovery when all the other parties agree to provide their tokens.
here's an example that might help -- you can allow key A to own your identity and key B to move your identity to another key. But key B can only move the identity after a time delay if key A does not cancel it. So key B is not your "real key" -- as long as key A is around it is an inferiorly permissioned key. But if Key A is missing then key B becomes the real key.
the key insight is that smart contracts can be used to transmute keys from single points of ownership into a distributed set of permissions.
you can compose a whole set of recovery systems with this primitive - key B could be your ledger or it could be a friend or it could be a third party service that offers "recovery as a service" where you have to call them and prove your identity before they will recover it back to you.
> Ownership remains decentralized because the recovery address cannot make a transfer that the custody address does not approve.
This isn't true though?
If I go out camping for a week and the recovery address transfers my identity, I won't be asked to approve; it'll simply go through after waiting 3 days.
