radicle-alpha

See [old-roadmap], on the challenges they had. But I agree that they should be overcome. In particular, the essence of the packfile format and protocol --- storing and exchanging patches from one content-addressed atom to another --- would be good for IPFS as a whole, so I think the issue is not some incompatible priorities, but rather just human/org coordination difficulties. (C.F. [eth2-report] for about Ethereum 2 working with libp2p.) It's always harder to reuse code developed by different teams in the short term, but I firmly believe it's worth it, making both sides better --- better than they would be had they gone their separate ways --- in the long term. The immediate challenge with Git is that git objects (blobs, trees, and commits) can be arbitrary large, which is bad in general, but especially bad for p2p networks where you don

Radicle is a full-fledge (fledling of a) programming language, so you can really do as you wish with access control. Here's the module for authorization [0], and in this module [1] you can see an example of it being used. [0] https://github.com/radicle-dev/radicle/blob/master/rad/prelu... [1] https://github.com/radicle-dev/radicle/blob/master/rad/monad...

There already is access control. Only admins can accept patches, for instance (though a bug we've just made a fix for [0] meant if someone else tried doing it the entire patch system for that project would break). Programmatic content-filtering is really the bread-and-butter of Radicle. Ad-hoc content-filtering is a bit harder, but as I mentioned elsewhere still possible. [0] https://github.com/radicle-dev/radicle/pull/552