I’m heartened by efforts to build new social forges. At the absolute minimum, these kind of initiatives raise the background pressure on GitHub and GitLab to improve their products.

From the FAQ:

> For one, [git] has no way of verifying that the repository you downloaded after a git clone is the one you asked for, which means you need to clone from a trusted source (ie. a known server). This isn’t compatible with peer-to-peer in any useful way.

> Radicle solves this by assigning stable identities to repositories that can be verified locally, allowing repositories to be served by untrusted parties.

What does this mean, in practice? At first glance this sounds like Radicle is turning a service trust problem into a PKI-shaped problem, which is more of a transmutation than a solution.

Or more precisely: how do I know which stable repository identities to trust, and how is that trust distributed to parties in the network?

▲

endiangroup 6 hours ago | parent | next [-]

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 5 hours ago | parent [-]

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 2 hours ago \| parent \| next [-]
		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 5 hours ago \| parent \| prev [-]
		AD: I have to clock off now, but I'll get back to this, I appreciate the well thought out response!

▲

iamnothere 6 hours ago | parent | prev [-]

Trust would need to be established through other channels, or through careful code review, same as a repo by an unknown dev on GitHub. Once trust is established, you can look for other repos owned by the same DID if you want to see more by the same dev. If multiple versions of the same repo exist, and you want to find the “real” one, you may look for the one recommended by a trusted source or the one that is mentioned most elsewhere. Failing that you could look at development activity on the repo.

Imagine a project with multiple repos on GitHub (not “forks” but someone actually uploaded it as a new repo). Similar problem. I’ve seen this before with some simple C libraries that haven’t changed in years.