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.
Reading the intro, I feel like I got a good hint about what this is. It sounded like "local first git for teams, without the hell of sharing patches via email".
I don't know what gitea or forgejo are, so comparisons wouldn't help me.
The existing summary is great. It uses git in the first sentence. Meanwhile forjo's landing page seems to be activly avoiding the words git and source control leaving it a cryptic mess.
AD: Feel free to take a stab at an alternative, we're an open source project and we accept and welcome discussions but patches more so! What would read better in your opinion?
no, it's a distributed peer-to-peer alternative to something like github. it has all the features like a locally hosted forgejo/gitea/gitlab, but it also is built on a distributed and fault-tolerant peer-to-peer network for hosting public projects.
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?
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.
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.
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
)"
```
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.
You know, a centralized system is not immune to any of the issues you are listing here.
Whether your mistakes can be deleted is up to the operator. They can even lead you to believe your content was deleted, while reporting it to the authorities.
> What if you post a communication system with encryption methods, but then the government passes a law that is criminal
Did you post it while it was legal to do so? Yes. Are you distributing it after it was deemed illegal? No. If you are in a country with a fair justice system, you wouldn't have to worry. If you are in a country without one, they will find a much easier way to get you anyway.
A large proportion of historic usenet posts are archived and remain freely available today. Didn't google end up with one of the larger commercial archives? So that "stupid stuff" is still around unless it got deleted at the time (and wasn't archived first).
New uploads to github are constantly being scanned by both benevolent and malicious actors for secrets that were inadvertently checked in. It's far too late by the time you notice and delete it.
This P2P system doesn't appear to introduce any new problems that aren't already widespread.
This just seems like acknowledging the reality. If you publish something publicly, it's very possibly forever. Maybe a reasonable solution would be for a user client to delay publishing for a time (like an email client that lets you cancel/recall a sent email for a time).
AD: We're actively working on that issue right now, making the defaults safer. We're also discussing internally how to enable revocation of content at the network level. It won't be perfect, but neither is GitHub or the likes.
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.
Radicle is architecturally local-first: you run your own node, sync repositories from a P2P gossip network, and then everything—browsing code, creating issues, reviewing patches—happens against your local data store. There's no round-trip to a server. Issues and patches are stored as signed Git objects (COBs) that replicate with the repo itself. The network is only involved when you choose to sync. This makes it extremely performant for day-to-day work and fully functional offline.
Tangled to my understanding is federated in theory but centralized in practice. It relies on "knots" (servers that host Git repos) and a central AppView at tangled.sh that aggregates the network. Issues and social artifacts live on Personal Data Servers, not locally. While you can self-host a knot, the default experience routes through Tangled's managed infrastructure. The architecture is fundamentally client-server: your operations go over the network to wherever your data lives.
Tangled is built on top of the AT Protocol, and "mediates" between what they call "knots". Git servers. Their strength is to use AT Protocol to make communication across multiple Git servers work smoothly.
Radicle is completely peer to peer. There are no such things as servers and clients, only nodes. However, there are quite a few nodes that then act as HTTP servers to offer convenient access via the browser.
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.
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.
Is it straightforward to set up a seed node that's simultaneously available on multiple networks? For example tor, i2p, clearnet, and maybe even yggdrasil all at the same time. I ask because I recall (not git related) projects in the past that did not do well when configured in such a way.
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.
Radicle is peer to peer. There are no "instances" or "servers" you interact with. The process that runs on your machine to synchronize changes across the network is the same as you would run on a server somewhere else. This is the core difference in network topology.
What Forgejo are working on is to have their servers/instances communicate with each other via ActivityPub (IIRC). Think about it more like GitHub : Forgejo :: Twitter : Mastodon and possibly Filesharing : BitTorrent :: Software Development : Radicle.
With Forgejo, every instance has its own database of user accounts, and controls who may log in or not (and so on). This is not the case with Radicle. Since there is no such authority, user accounts are self-certifying.
For repositories, since there is no "standard location" like "the server", Radicle has developed a way to abstract from the user namespaces of the maintainers of a repo, to a canonical namespace. This is how references are lifted from individuals to a project. Not by having a copy on some particular server with access control. Of course, Radicle also has access control, but it is tied to the self-certifying identities, not to some server.
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.
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.
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.
AD: We're looking ad introducing 'forgetting' as a feature, there may be a mutually beneficial way of signalling to permissive seeds when content is no longer relevant or stale or actively been flagged for removal.
> Causal dependencies can be modeled as commit parent-child relationships.
And there we have the problem. Git does not guarantee these things. Git is no CRDT. A proper replication protocol would, but git not. Git requires manual intervention to resolve coflicts. You end up with hourly conflicts, which need to be resolved manually, or not. Leading to inconsistencies all over when two people merge and resolve conflicts differently. Let not people merge, the system must handle this automatically. As in all online collaboration tools. Like Google Wave eg. If CRDT or as with databases PAXOS or single owner.
What is the revenue model for Tangled? This is why ATProto stuff worries me, the AppView is expensive to host and no one has created a paid service yet to achieve sustainability.
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.
In the Radicle ecosystem, quite a few people like the idea to "seed" repos that they want to support. It means that you download the repo, and also announce to other nodes that you have it available to share. Thus, you are not only incrementing some counter in a central database, but you are actually contributing to the replication of the project on the network.
The number of seeds then is a similar indicator as the number of stars.
Of course, you can also just keep a list of repository IDs.
As alternative git forges become more common, it might make sense to build a social bookmarking site for repos that can roll up repos from Radicle, Codeberg, Sourcehut, individual Gitlab instances, etc. Maybe it could include cross-platform search, alerting, and other tools.
This might address some of the trust and discovery questions posed elsewhere in the discussion.
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.
[+] [-] jbstack|1 month ago|reply
"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.
[+] [-] the_other|1 month ago|reply
I don't know what gitea or forgejo are, so comparisons wouldn't help me.
[+] [-] int0x29|1 month ago|reply
[+] [-] endiangroup|1 month ago|reply
[+] [-] a-dub|1 month ago|reply
[+] [-] dwa3592|1 month ago|reply
[+] [-] fwip|1 month ago|reply
Edit: removed snarky line.
[+] [-] woodruffw|1 month ago|reply
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|1 month ago|reply
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.
[+] [-] iamnothere|1 month ago|reply
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.
[+] [-] ChristopherA|1 month ago|reply
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 )" ```
[+] [-] hackthemack|1 month ago|reply
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.
[+] [-] phoronixrly|1 month ago|reply
Whether your mistakes can be deleted is up to the operator. They can even lead you to believe your content was deleted, while reporting it to the authorities.
> What if you post a communication system with encryption methods, but then the government passes a law that is criminal
Did you post it while it was legal to do so? Yes. Are you distributing it after it was deemed illegal? No. If you are in a country with a fair justice system, you wouldn't have to worry. If you are in a country without one, they will find a much easier way to get you anyway.
[+] [-] fc417fc802|1 month ago|reply
New uploads to github are constantly being scanned by both benevolent and malicious actors for secrets that were inadvertently checked in. It's far too late by the time you notice and delete it.
This P2P system doesn't appear to introduce any new problems that aren't already widespread.
[+] [-] pluralmonad|1 month ago|reply
[+] [-] endiangroup|1 month ago|reply
[+] [-] vlad-roundabout|1 month ago|reply
[+] [-] unknown|1 month ago|reply
[deleted]
[+] [-] noelwelsh|1 month ago|reply
[+] [-] 0x3o3|1 month ago|reply
Tangled to my understanding is federated in theory but centralized in practice. It relies on "knots" (servers that host Git repos) and a central AppView at tangled.sh that aggregates the network. Issues and social artifacts live on Personal Data Servers, not locally. While you can self-host a knot, the default experience routes through Tangled's managed infrastructure. The architecture is fundamentally client-server: your operations go over the network to wherever your data lives.
[+] [-] lorenzleutgeb|1 month ago|reply
Radicle is completely peer to peer. There are no such things as servers and clients, only nodes. However, there are quite a few nodes that then act as HTTP servers to offer convenient access via the browser.
[+] [-] jrmg|1 month ago|reply
——
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
[+] [-] avaer|1 month ago|reply
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.
[+] [-] Defelo|1 month ago|reply
[+] [-] noman-land|1 month ago|reply
We need better forges and they need to be p2p to survive. p2p is the only viable future for the web.
[+] [-] endiangroup|1 month ago|reply
[+] [-] endiangroup|1 month ago|reply
[+] [-] iamnothere|1 month ago|reply
You can put your node behind Tor if you’re worried about demand letters, by the way.
[+] [-] fc417fc802|1 month ago|reply
[+] [-] untech|1 month ago|reply
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.
[+] [-] eigenspace|1 month ago|reply
[+] [-] lorenzleutgeb|1 month ago|reply
What Forgejo are working on is to have their servers/instances communicate with each other via ActivityPub (IIRC). Think about it more like GitHub : Forgejo :: Twitter : Mastodon and possibly Filesharing : BitTorrent :: Software Development : Radicle.
With Forgejo, every instance has its own database of user accounts, and controls who may log in or not (and so on). This is not the case with Radicle. Since there is no such authority, user accounts are self-certifying.
For repositories, since there is no "standard location" like "the server", Radicle has developed a way to abstract from the user namespaces of the maintainers of a repo, to a canonical namespace. This is how references are lifted from individuals to a project. Not by having a copy on some particular server with access control. Of course, Radicle also has access control, but it is tied to the self-certifying identities, not to some server.
[+] [-] rirze|1 month ago|reply
Hopefully it will scale well and be ergonomic for collaboration.
[+] [-] toastal|1 month ago|reply
[+] [-] __MatrixMan__|1 month ago|reply
[+] [-] ilaksh|1 month ago|reply
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.
[+] [-] lorenzleutgeb|1 month ago|reply
[+] [-] jrm4|1 month ago|reply
But this seems excellent for code, a thing that (to the extent you can or should be) is mostly apolitical.
[+] [-] endiangroup|1 month ago|reply
[+] [-] rurban|1 month ago|reply
> Synchronization is handled by Git.
> Causal dependencies can be modeled as commit parent-child relationships.
And there we have the problem. Git does not guarantee these things. Git is no CRDT. A proper replication protocol would, but git not. Git requires manual intervention to resolve coflicts. You end up with hourly conflicts, which need to be resolved manually, or not. Leading to inconsistencies all over when two people merge and resolve conflicts differently. Let not people merge, the system must handle this automatically. As in all online collaboration tools. Like Google Wave eg. If CRDT or as with databases PAXOS or single owner.
[+] [-] lorenzleutgeb|1 month ago|reply
Radicle implements so called "collaborative objects" (think: issues, patches, anything that multiple users collaborate on; except the source code itself) as CRDTs: https://radicle.xyz/guides/protocol#collaborative-objects
[+] [-] acedTrex|1 month ago|reply
[+] [-] wantlotsofcurry|1 month ago|reply
[+] [-] HexDecOctBin|1 month ago|reply
[+] [-] mxuribe|1 month ago|reply
[+] [-] lorenzleutgeb|1 month ago|reply
The number of seeds then is a similar indicator as the number of stars.
Of course, you can also just keep a list of repository IDs.
[+] [-] iamnothere|1 month ago|reply
This might address some of the trust and discovery questions posed elsewhere in the discussion.
[+] [-] mistercheph|1 month ago|reply