alt Hacker NewsAD: I'll take a stab, but I am a new joiner!
Each repository is governed by an identity document which is signed by a set of delegates, each delegate currently corresponds 1:1 to someones ssh-key. We are working to adjust this mechanism so you can have group identities, but its a hard problem and we're not the only ones working on it (note theres light at the end of this tunnel at this point).
Seeing as you studied philosophy I'd argue what then do you mean by a solution? Aren't all solutions transmutations of prior 'things'? In the complex domain we have a word for it, exaptation - the radicle repurposing of something in a new context.
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.
So to answer "how is that trust distributed to parties in the network" - by stable cryptographic identities.
To answer "how do I know which stable repository identities to trust" - by socialising, like you know how to trust people you meet in the world because you were introduced to them by someone else you trust.
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.