4 ms·

I like the idea of a distributed issues/PR tracking platform, but I am skeptical about this one. I would have expected something simpler, that leverages the exi

I like the idea of a distributed issues/PR tracking platform, but I am skeptical about this one. I would have expected something simpler, that leverages the existing paradigm of push/pull remotes (and then building an optional live-sync daemon on top of that). Radicle appears to be built on the concept of a single global network, completely without any location-based addressing. I'm also suspicious about moderation. Even with tools to blacklist peers, it seems like this design is vulnerable to "hostile takeovers" where a repo is forked but the new maintainers don't change the repo's did, instead just get more nodes to follow them than the original.

crotchfire 3y ago
where a repo is forked but the new maintainers don't change the repo's did A DID is a public key. If you don't know the corresponding private key you won't be able to make any updates. All you'll be able to do is mirror it. instead just get more nodes to follow them than the original This is like saying "but I can fork Verisign's Root CA certificate and get more nodes to follow me than Verisign!". No, you don't have the private key that goes with that root certificate. So everybody will ignore you. Cryptography is not a popularity contest.
- CGamesPlay 3y ago
  Thanks for the reply. I see that "repository delegates" is a git-versioned list of public keys corresponding to approved maintainers. So it looks like a fork taking over an abandoned repository would have to use a slightly modified URL to access [0] (until the original maintainer comes back and adds the new maintainer to the delegates list, then the new maintainer can merge the repositories). My confusion (your so-called "popularity contest") came because I read how the "canonical branch" is determined based on consensus of signatures, and I didn't realize that only the pre-approved keys could contribute those signatures. So, anyone can make commits and seeds will accept the commits from anyone, but the "canonical branch" will only update (on a given seed) if it's signed by repository delegates. The "next strictest" level of control is private repositories, which simply means that Radicle will only send its commits to a peer in the repository's allow list. My next big moderation-related question is what redaction looks like. Obviously an unwilling peer would diverge from the signature chain at this point, but does Radicle provide any tools for, say, permanently redacting an issue comment? It's obviously possible (but painful!) to do this in regular git for commits. [0] https://radicle.xyz/guides/protocol#git-url-scheme https://radicle.xyz/guides/protocol#git-url-scheme

crotchfire 3y ago

where a repo is forked but the new maintainers don't change the repo's did A DID is a public key. If you don't know the corresponding private key you won't be able to make any updates. All you'll be able to do is mirror it. instead just get more nodes to follow them than the original This is like saying "but I can fork Verisign's Root CA certificate and get more nodes to follow me than Verisign!". No, you don't have the private key that goes with that root certificate. So everybody will ignore you. Cryptography is not a popularity contest.

CGamesPlay 3y ago
Thanks for the reply. I see that "repository delegates" is a git-versioned list of public keys corresponding to approved maintainers. So it looks like a fork taking over an abandoned repository would have to use a slightly modified URL to access [0] (until the original maintainer comes back and adds the new maintainer to the delegates list, then the new maintainer can merge the repositories). My confusion (your so-called "popularity contest") came because I read how the "canonical branch" is determined based on consensus of signatures, and I didn't realize that only the pre-approved keys could contribute those signatures. So, anyone can make commits and seeds will accept the commits from anyone, but the "canonical branch" will only update (on a given seed) if it's signed by repository delegates. The "next strictest" level of control is private repositories, which simply means that Radicle will only send its commits to a peer in the repository's allow list. My next big moderation-related question is what redaction looks like. Obviously an unwilling peer would diverge from the signature chain at this point, but does Radicle provide any tools for, say, permanently redacting an issue comment? It's obviously possible (but painful!) to do this in regular git for commits. [0] https://radicle.xyz/guides/protocol#git-url-scheme https://radicle.xyz/guides/protocol#git-url-scheme