Thanks for your detailed response.

I guess what I mean is that trust is a hard problem, and a lot of solutions to trust involve transmuting a presupposed trust problem into a different trust problem with a slightly different security model.

For example: with a centralized service, I assume that a given identity is integral so long as the service is secure. I don't need cryptographic identity for that centralized service, but that assumes I trust the service to be secure.

With a distributed service, I need some way to ensure the integrity of identities. One way to do that is to TOFU, i.e. take a claimant identity on face value on first observation and then trust it going forwards. This works well for schemes like SSH, but it doesn't work super well for distributed user networks (because users like to lose their keys, and there's a larger potential surface area for undetectable key substitution).

Another solution is a "web of trust" architecture, where you take an initial trusted core and transitively extend trust outwards. The problems with this are (1) that trust isn't actually transitive, and (2) it still presupposes a trusted core, which needs to be bootstrapped somehow.

A third solution is a traditional PKI, where you have one or more pre-established identity "authorities" that sign for end user identities. This is the solution that HTTPS picks, and is arguably the most empirically proven of the decentralized identity schemes. But it's only as decentralized as the authorities themselves are, and there's a meaningful argument to be had about that (particularly in schemes that are smaller than the Web PKI).

It sounds like Radicle is going with a mixture of (1) and (2), which is interesting and worth proving out. But my experience is that "someone's SSH key" is much less of a stable identity than we'd all like it to be, and schemes that involve delegating trust via unstable identities eventually run into architectural limitations that end users solve by just subverting the scheme itself (i.e. falling back to TOFU).

> That aside, how do you know which people to trust when you meet them? And how do you signal trust in those you've met? In Radicle holding stable cryptographic identities doesn't resolve the zero-to-some trust problem but it does resolve the some-to-more trust problem, I can continue trusting once I recognise and know an identity.

This is a good example both of how (1) social trust isn't easy to encode in cryptographic claims, and (2) how the transitivity of trust breaks down.

In the real world, I trust my barber to cut my hair and my dentist to look at my teeth. But I only trust them for their apposite roles, and my trust in my barber doesn't necessarily mean anything to my friend who doesn't like my haircut.

Your comments of trust reminded me of an analysis of the PGP strongly-connected component of the "web of trust," back when keyservers were a bigger thing, and essentially found that, in practice, "web of trust" turned out to have a lot of key nodes that look very much like CAs in Web PKI.

That is, for as much as a lot of cryptoenthusiasts want to talk about decentralizing trust and empowering users to have fine-grained trust decisions, in practice, most users really just want to offload all of the burden of ensuring someone is trustworthy on somebody else.

AD: I have to clock off now, but I'll get back to this, I appreciate the well thought out response!