Can anyone describe how this differs from Tangled (https://tangled.org/)? Both seem very interesting, but I'm not deep enough into either to understand how they differ.
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?
You can create a decentralized identifier for any repo with a properly formatted inception commit (a signed commit 0), that is the same for any git platform.
```zsh
eval "$(
cat <<'EOF'
zsh_git_inception() {
[ -d "$(pwd)/new_open_integrity_repo/.git" ] && echo " Repo already exists." && return 1
mkdir -p "$(pwd)/new_open_integrity_repo" && git -C "$(pwd)/new_open_integrity_repo" init > /dev/null
SIGNING_KEY="$(git config user.signingkey)"
GIT_AUTHOR_NAME="$(git config user.name)"; GIT_AUTHOR_EMAIL="$(git config user.email)"
GIT_COMMITTER_NAME="$(ssh-keygen -E sha256 -lf "$SIGNING_KEY" | awk '{print $2}')"
GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"; GIT_AUTHOR_DATE="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"; GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_COMMITTER_NAME="$GIT_COMMITTER_NAME" GIT_COMMITTER_EMAIL="$GIT_COMMITTER_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" GIT_COMMITTER_DATE="$GIT_COMMITTER_DATE" \
git -C "$(pwd)/new_open_integrity_repo" -c gpg.format=ssh -c user.signingkey="$SIGNING_KEY" \
commit --allow-empty --no-edit --gpg-sign \
-m "Initialize repository and establish a SHA-1 root of trust" \
-m "Signed-off-by: $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL>" \
-m "This key also certifies future commits' integrity and origin. Other keys can be authorized to add additional commits via the creation of a ./.repo/config/verification/allowed_commit_signers file. This file must initially be signed by this repo's inception key, granting these keys the authority to add future commits to this repo including the potential to remove the authority of this inception key for future commits. Once established, any changes to ./.repo/config/verification/allowed_commit_signers must be authorized by one of the previously approved signers."
[ $? -eq 0 ] && echo " Repo initialized!" || echo " Commit failed. Check Git settings."
}
zsh_git_inception
EOF
)"
```
Interesting. I've been critical on "decentralized" for other types of communication (e.g. ATProto/Bluesky) because it seems to forget that "forgetting is sometimes good."
But this seems excellent for code, a thing that (to the extent you can or should be) is mostly apolitical.
I hang out with a small group of sysadmins who like to spin up the old internet stuff, like irc, gopher.
And that got me to thinking about Usenet and how a ton of software (usually pirated) and images (usually pornography) were posted to it.
And people often posted stupid stuff they said (usually because they were young and dare I say afflicted by a moment of dumb).
I think one of the problems with p2p distributed systems is how do you handle "mistakes". Things you want deleted.
What if someone accidentally posts their address and phone number?
What if you post a communication system with encryption methods, but then the government passes a law that is criminal? Maybe in some regimes that puts you on a list for arrest? Look at what is happening with HAM radio operators and Belarus...
To me, none of this raises above the idea that distributed p2p content should not be used. It is just that it has some issues.
Also, unrelated, but I think the plethora of "How does this compare to XYZ" type comments are not very helpful. It is too easy to write that kind of post, but much harder to answer.
Can radicle seeds run over IPV6? Seems like since IPV6 doesn't have NAT it should be a big advantage for p2p and as it becomes more available the need for everyone to set up port forwarding or get a VPS to seed should go down.
ISPs will try to block use of IPV6 for serving content, but eventually I think users will win because ultimately it should be a right to share information.
This certainly seems like a neat system. From the FAQ, two things I was most concerned about knowing:
——
How does Radicle deal with potential abuse, illegal content sharing etc. on the network?
Each node is free to choose which repositories to host (seed) using configured policies. Nodes can block specific repositories or peers exhibiting abusive behavior.
Is there a way to host private repositories on Radicle?
Yes, Radicle supports private repositories that are only shared among a trusted set of peers, not the entire network. These are not encrypted at rest but rely on selective replication and are thus completely invisible to the rest of the network.
Suggestion: improve the opening summary paragraph:
"Radicle is an open source, peer-to-peer code collaboration stack built on Git. Unlike centralized code hosting platforms, there is no single entity controlling the network. Repositories are replicated across peers in a decentralized manner, and users are in full control of their data and workflow."
From this, I can't tell how it's any different to just plain self-hosted Git. A well written introduction should tell the reader immediately what the software actually does. If it's meant to be an alternative to something like gitea / forgejo then say that, with a brief summary of features that build on top of Git.
This home page really needs a prominent gateway to the underlying gossip protocol so you can easily find every public repo on the network. Might be antithetical to the cause, though I argue it isn't. Maybe this already exists but I couldn't find it. And if this isn't technically possible, someone needs to solve that.
The pitch is compelling; if the project home page shows that index, I can see a world where this takes the reigns from Github. Otherwise I don't see it.
I wonder how "permissive seeders" would be protected from folks pushing large binary files.
Also, wouldn't storing everything about the repo make it very large? Even when cloning large git projects, it is from time to time necessary to make a "shallow clone" to avoid downloading hundreds of megabytes per repo. I imagine with all discussions it would be worse.
Awesome work! Just curious, has anyone worked on a tool for migrating github "collaborations"/ social artifacts to radicle, I'm confident this will be solved eventually as existing projects with treasured social artifacts on GH migrate, just curious about the current state.
I believe that one day, the bad guys are gonna level up such that centralized forges can't withstand corruption and we're gonna be real glad that people have been working on things like this all along.
Is it weird that one of the features that i look for in forge is the ability to star/bookmark a repo? But, since this is decentralized, makes sense that there is no central place to "house" said bookmark...So I'd either have to bookmark a repo using my browsers native, regular bookmarks....or in the future there could be feature to share, save/store said signal like the way ActivityPub, AT proto., etc.. handle it.
32 comments
[ 10.6 ms ] story [ 51.6 ms ] threadFrom 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?
See https://github.com/OpenIntegrityProject/core/blob/main/docs/...
```zsh eval "$( cat <<'EOF' zsh_git_inception() { [ -d "$(pwd)/new_open_integrity_repo/.git" ] && echo " Repo already exists." && return 1 mkdir -p "$(pwd)/new_open_integrity_repo" && git -C "$(pwd)/new_open_integrity_repo" init > /dev/null SIGNING_KEY="$(git config user.signingkey)" GIT_AUTHOR_NAME="$(git config user.name)"; GIT_AUTHOR_EMAIL="$(git config user.email)" GIT_COMMITTER_NAME="$(ssh-keygen -E sha256 -lf "$SIGNING_KEY" | awk '{print $2}')" GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"; GIT_AUTHOR_DATE="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"; GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE" GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \ GIT_COMMITTER_NAME="$GIT_COMMITTER_NAME" GIT_COMMITTER_EMAIL="$GIT_COMMITTER_EMAIL" \ GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" GIT_COMMITTER_DATE="$GIT_COMMITTER_DATE" \ git -C "$(pwd)/new_open_integrity_repo" -c gpg.format=ssh -c user.signingkey="$SIGNING_KEY" \ commit --allow-empty --no-edit --gpg-sign \ -m "Initialize repository and establish a SHA-1 root of trust" \ -m "Signed-off-by: $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL>" \ -m "This key also certifies future commits' integrity and origin. Other keys can be authorized to add additional commits via the creation of a ./.repo/config/verification/allowed_commit_signers file. This file must initially be signed by this repo's inception key, granting these keys the authority to add future commits to this repo including the potential to remove the authority of this inception key for future commits. Once established, any changes to ./.repo/config/verification/allowed_commit_signers must be authorized by one of the previously approved signers." [ $? -eq 0 ] && echo " Repo initialized!" || echo " Commit failed. Check Git settings." } zsh_git_inception EOF )" ```
We need better forges and they need to be p2p to survive. p2p is the only viable future for the web.
But this seems excellent for code, a thing that (to the extent you can or should be) is mostly apolitical.
And that got me to thinking about Usenet and how a ton of software (usually pirated) and images (usually pornography) were posted to it.
And people often posted stupid stuff they said (usually because they were young and dare I say afflicted by a moment of dumb).
I think one of the problems with p2p distributed systems is how do you handle "mistakes". Things you want deleted.
What if someone accidentally posts their address and phone number?
What if you post a communication system with encryption methods, but then the government passes a law that is criminal? Maybe in some regimes that puts you on a list for arrest? Look at what is happening with HAM radio operators and Belarus...
https://www.niemanlab.org/reading/ham-radio-operators-in-bel...
To me, none of this raises above the idea that distributed p2p content should not be used. It is just that it has some issues.
Also, unrelated, but I think the plethora of "How does this compare to XYZ" type comments are not very helpful. It is too easy to write that kind of post, but much harder to answer.
You can put your node behind Tor if you’re worried about demand letters, by the way.
ISPs will try to block use of IPV6 for serving content, but eventually I think users will win because ultimately it should be a right to share information.
——
How does Radicle deal with potential abuse, illegal content sharing etc. on the network?
Each node is free to choose which repositories to host (seed) using configured policies. Nodes can block specific repositories or peers exhibiting abusive behavior.
Is there a way to host private repositories on Radicle?
Yes, Radicle supports private repositories that are only shared among a trusted set of peers, not the entire network. These are not encrypted at rest but rely on selective replication and are thus completely invisible to the rest of the network.
https://radicle.xyz/faq
"Radicle is an open source, peer-to-peer code collaboration stack built on Git. Unlike centralized code hosting platforms, there is no single entity controlling the network. Repositories are replicated across peers in a decentralized manner, and users are in full control of their data and workflow."
From this, I can't tell how it's any different to just plain self-hosted Git. A well written introduction should tell the reader immediately what the software actually does. If it's meant to be an alternative to something like gitea / forgejo then say that, with a brief summary of features that build on top of Git.
Hopefully it will scale well and be ergonomic for collaboration.
The pitch is compelling; if the project home page shows that index, I can see a world where this takes the reigns from Github. Otherwise I don't see it.
Also, wouldn't storing everything about the repo make it very large? Even when cloning large git projects, it is from time to time necessary to make a "shallow clone" to avoid downloading hundreds of megabytes per repo. I imagine with all discussions it would be worse.