You may notice that the title is "peer-to-peer code collaboration stack built on Git", emphasis on "built on". We're using Git as a storage and transport mechanism for code collaboration data. So we're building a local-first tool for the social data, e.g. patches and issues.

It's also stated in the FAQ on the website (https://radicle.xyz/faq) that the project is funded by Radworks and also provides a link to the funding page.

I, for one, work on Radicle and what I care about is the data sovereignty and local-first code collaboration. We're building on top of Git to provide a local-first, extensible collaboration experience -- avoiding walled gardens like GitHub :)

As a project team, we only posted once on HN when we were announcing our v1.0 release candidates. The other two posts have been from other people outside of the organisation, so it's nice to see there's interest in the project but don't blame us for that kind of hype :')

Perhaps in the future, a user could use a web interface for a Radicle node and they post it directly from their browser. Some questions about that would the verifiability of that action though. Definitely some food for thought here!

Git is just a mechanism for storing plain-text data as a series of commits. The underlying data are just blobs of bytes. So all data is Git data and Radicle takes full advantage of that.

The "special" data in Git would be `refs/heads`, `refs/remotes`, `refs/tags`, and the lesser known `refs/notes`. Radicle doesn't touch those directly, we still allow the use of Git tooling for working with that data.

It then extends on top of these by use `refs/rad` and `refs/cobs` for storing Radicle associated data, using all of Git's mechanisms that it provides to do so.

If someone wanted to come along and define a way to embed Fossil wikis/issues as a COB then they could be replicated on the Radicle network and it's then up to application developers to load and interpret that data.

I think this is cool because it essentially allows developers to extend the Radicle ecosystem easily and define new workflows! However, that does not avoid our XKCD problem stated above ;P But hey, sometimes that's the beauty of these things -- we're given the power to define our own workflows and not locked into something everyone complains about coughGitHub branches PR flowcough

Updates to the delegate set (read: maintainers) can be made, let's say adding a new delegate. This change is signed by a quorum of the current set of maintainers. This change is kept track of in the Git commit history, so these chain of actions can be walked from the root and verified at each point.

Similarly, a delegate can be removed, the project name changed, etc.

Forking is only necessary if there is a disagreement between maintainers that cannot be resolved so one of them goes off to create a new identifier to differentiate between the two. At this point, it's up to you to decide who you trust more to do a better job :)