[endiangroup]

AD: 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.

[woodruffw]

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.

[jcranmer]

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.

[endiangroup]

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

[endiangroup]

AD: Thanks for engaging in a constructive way!

I agree trust is a hard problem when your coming from a problem<>solution framing. Trust is pretty abundant in our day-to-day lives if not a slightly backgrounded, for example; I trust my keyboard to type until the batteries run out or wear & tear gets the better of it, I trust my partner to hold care for me in mind when making decisions for me, I trust my dog to come back to me when I call for him... etc. In all those cases I've engaged on a epistemic and phenomenological journey mutually validating (at least) my experiences, my expectations and my actions. Because I remember my dog coming back to me in my previous experiences I trust and as such expect him to do so in the future. Because my keyboard continues to reflect my intent in writing this, I trust it is operating correctly. Because my partner has shown care for me a prior, I trust she will continue to do so.

I agree with your representations of centralised, TOFU and 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).

You're right 'someones ssh key' is unstable (not to detract from my my point but in the real world trust can be fickle and unstable too), however we can increase our certainty and are intending to. I'm interested in bring HSM's into Radicle, that swaps something you have on your computer to something you have on a physical device, but there are also further advancements like have been seen in the world of Keri where you can delegate identity to a log (KEL) which act as Autonomic Identifiers, these are self-sovereign, self-certifying sources of truth, we can have a set of keys and rules that govern the usage of them such that only 1 is valid at a time and if it is lost or compromised we can rotate safely and continue doing so.

> 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.

Agreed on 1.! I'd rather keep people good at what people do (continuously making and sharing trust judgements by engaging in the world) but enabling them to reflect that easily in their digital life. As for 2. I think it goes both ways depending on the context, it can breakdown but it can also compound amongst a plethora of other variations.

> 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.

I disagree, when talking conceptually of the role of barbers and trusting them at cutting my hair I agree, however when I go out into the real world and interact with my barber I trust them with more than just that! In fact I'd imagine many barbers would be offended at the idea they are ONLY trusted to cut hair in the barber shop. Try have that conversation with your barber next time you are there - if they aren't hurt by the idea of being reduced to a single role you might of found yourself a robot!

As for your trust in your barber meaning nothing to your friend who doesn't like your hair cut, I'd imagine your trust would of changed given the bad hair cut, but we could split this many ways, your friend might not like your hair cut but you like it - thats not much to do with the barber, your friend might not like your hair cut and you don't like your hair cut, not really a conducive situation for a recommendation, you might not like your hair cut and your friend might love it, now how loyal is your friend? Any attempt to enumerate out all of the variations is feeble, but hopefully the point comes through that theres a lot more going on than we can reduce.