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