cloudhead

It's a good question, I don't know why you're downvoted.

Because the synchronization protocol (backed by Git) is operating in the background, web frontends are always just querying local data, so it's actually quite fast. You can try browsing the linked repository and see for yourself.

I am a nix noob, but we are now using flake[0], I don't know if that helps!

[0]: https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3gqcJUoA...

I do remember Mango! I didn't actually try it out, but we had experimented with Ethereum and IPFS in the past, and it wasn't a great fit for a code collab platform due to performance and cost.

It's a good point - I think "gateways" such as `app.radicle.xyz` will have to allow crawlers to index the full set of repositories on the network.

Everything that is replicated on the network is stored as a Git object, using the libgit2[0] library. This library uses hardened SHA-1 internally, which is called sha1dc (for "detect collision"). Will add to the docs, good idea!

[0]: https://github.com/libgit2/libgit2/blob/ac0f2245510f6c75db1b...

Hey there. Yes, Windows support is something we'd like to have, but focusing on less OSes is helping us ship faster. In principle, there shouldn't be any issue in porting to Windows, but since no one on the team runs Windows it would have been hard to ensure things are working smoothly. If there is demand though, we will certainly start allocating time towards it.

Radicle does work on macOS as well.

Thanks! There is no mirroring built-in yet, though this is something we're looking into. It should theoretically be as simple as setting up a `cron` job that pulls from github and pushes to radicle every hour, eg.

  git pull github master
  git push rad master

When you fork an abandoned repo, you are essentially giving it a new repository identity, which is a new root of trust, with a new maintainer set. You'll then have to communicate the new repository identifier and explain that this is a fork of the old repo.

A CONTRIBUTORS file is easy to change by anyone hosting the repository - it's useless for the purpose of verification, unless you have a toolchain to verify each change to said file. "Sign-offs by maintainers" it not useful either unless you already know who the maintainers are, and you are kept up to date (by a trusted source) when the maintainers change. This is what Radicle does, for free, when you clone a repo.

That's not quite right, we solved this in Radicle. Each change in ownership (adding/removing maintainers) is signed by the previous set of owners. You can therefore trace the changes in ownership starting from the original set, which is bound to the Repository ID.

Yeah, because for eg. I can publish the given repository from my server with an additional signed commit (signed by me) on top of the original history, and that commit could include a backdoor. You have no way of knowing whether this additional commit is "authorized" by the project leads/owners or not.

We've designed Radicle with Tor support in mind, via Socks5 proxy!

Yes, working on it!

I think it's currently more likely to happen on Radicle given there is no search or discovery functionality, and repositories exist on a flat hierarchy, ie. they are not namespaced by user/org name, so harder to distinguish if they share the same name and description.

Here's the problem: how do you know that the commit signers are the current maintainers of the repo?

I won't reveal anything about our finances, but the current code base is a little under 2 years old. We've worked on the general problem for over 4 years in total though. The team is around 12 people, split between protocol, cli, tui, web and content.

The product is set to launch this month, so we're just starting to onboard users, but many people in the community are already using it, and we've been using it internally for about a year.

I don't think there's anything "special" here. You have the same problem currently where finding the canonical location of a repository is done via some out-of-band social network or website.

On GitHub, you also can look at the stars to give you extra confidence, and on Radicle the equivalent is the seed count for a given repository.

If you mean collision attacks, this shouldn't be a problem with Git, since it uses Hardened SHA-1. Eventually, when Git fully migrates to SHA-2, we will offer that option as well.

> Is Hardened SHA-1 vulnerable?

> No, SHA-1 hardened with counter-cryptanalysis (see ‘how do I detect the attack’) will detect cryptanalytic collision attacks. In that case it adjusts the SHA-1 computation to result in a safe hash. This means that it will compute the regular SHA-1 hash for files without a collision attack, but produce a special hash for files with a collision attack, where both files will have a different unpredictable hash.

From https://shattered.io/

Yes, these are what Radicle calls "private" repositories. They are invisible to the rest of the network, and only shared amongst trusted peers. Note that they are not encrypted at rest, which means they cannot be stored on intermediary nodes that are not part of the truste set.

I've answered the use-case question here: https://news.ycombinator.com/item?id=39601588

But yes, we're not officially launched yet and the website is going through a rewrite to offer more clarity, thanks for the feedback.

Re: seed nodes: they are running the same software and work the same way as regular nodes, the only difference is how they're deployed (with a public IP address vs. behind a NAT). But yes, a little bit of asymmetry is needed because of NATs/IPv4.

Re: properties: mainly we need to provide encryption and self-certification to enable a similar user experience as GitHub/GitLab/etc. on a an untrusted peer-to-peer network. Additionally though, Radicle offers a level of censorship resitance and disruption tolerance that GitHub cannot offer.

Good question!

One of the key ideas is that each user chooses what repositories they host via pretty fine-grained policies. This means you can easily block content you're not interested in seeding, or simply configure your node to only host content you explicitly allow.

You can also choose which public nodes to connect to if you'd rather not connect to random nodes on the network; though I don't expect most users to go this route, as you are more likely to miss content you're interested in.

Though Git (and thus Radicle) can replicate arbitrary content, it's not particularly good with large binary files (movies, albums etc.), so I expect that type of content to still be shared on BitTorrent, even if Radicle were to be popular.

Thanks, we haven't officially launched though!

Pijul is a great project indeed :)

We're a small team, but if there is enough demand for it, then yes.

In the long term, this is intended as an alternative to collaboration platforms like GitHub and GitLab for people/organizations who want full control of their data and user experience, without compromising on the social aspect of these platforms.

The first three paragraphs of the guide has a longer motivation: https://docs.radicle.xyz/guides/user

It can handle them, though we haven't built that much tooling around them. However, unlike GitHub, updates to PRs (Patches in Radicle) are non-destructive, just like Gerrit[0], and code reviews are tied to specific revisions of patches. This is in my opinion one of the biggest flaws in GitHub's model.

[0]: https://www.gerritcodereview.com/

I haven't seen the term misused very often - the way it is defined in Radicle and most other peeer-to-peer systems is how Wikipedia defines it[0]; specifically this part: "Peers are equally privileged, equipotent participants in the network".

So a peer to peer system is one where all participants are "equally privileged in the network". This usually means they all run the same software as well.

[0]: https://en.wikipedia.org/wiki/Peer-to-peer

While Git is designed in some way for peer-to-peer interactions, there is no deployment of it that works that way. All deployments use the client-server model because Git lacks functionality to be deployed as-is in a peer-to-peer network.

For one, it 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 p2p in any useful way.

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

[0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...

See https://docs.radicle.xyz/guides/protocol

> The "bag of artifacts" data model used by Fossil is apparently an implementation of a particular Conflict-Free Replicated Datatype (CRDT) called a "G-Set" or "Grow-only Set".

Isn’t this just by virtue of content addressing objects? In that sense Git’s odb is also a G-set.

We'll hopefully have a real alternative to these centralized platforms when Radicle[0] gets closer to core feature parity with GitHub. For many, this will be sometime this year, for others it might take another year or two.

It's really scary to have a single platform be able to take away what is essentially your portfolio, resume, social profile, webhost (github pages) and collaboration platform all in one go, with no explanation or recourse available. It shouldn't be that way.

We're inching towards a Radicle v1.0 release that will provide some stability and a basic feature-set for hosting and collaboration in a fully "sovereign" way. If you're interested in helping out or learning more, feel free to drop me an email: cloudhead@radicle.xyz or come by our Zulip[1].

[0]: https://radicle.xyz

[1]: https://radicle.zulipchat.com/