Most of the other things radicle aims to provide seem like they are better centralized. There is a reason we all use gitlab/github for collab services. It is that centralization is better for that kind of thing.
Most of the other things radicle aims to provide seem like they are better centralized. There is a reason we all use gitlab/github for collab services. It is that centralization is better for that kind of thing.
No, it is not because centralization is better. It is because centralization is easier.
I've many, many times wished for a way to collaborate on a git-based project without having to centralize the collaboration on a platform that I ultimately fear will censor the project. radicle-link is exactly what I'm looking for, and it's bizarre to me that someone would look at this project and say "hmm, it should just be centralized." Why should it be?
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't to waste arbitrary large bandwidth and storage with some untrusted peer before verifying whether the data they've sent you is what you wanted. But I think I and a friend found a solution to this [git-chunk]. With that, it's at least possible to negotiate who has what git object without an awkward trustful identifier translations. That I think is good enough to get the ball rolling, after which the improvements to the protocol taking inspiration from the packfile format/protocol can be pursued.
[old-roadmap]: https://github.com/radicle-dev/radicle/issues/689
[eth2-report]: https://discuss.libp2p.io/t/report-a-study-of-libp2p-and-eth...
[git-chunk]: https://discuss.ipfs.io/t/git-on-ipfs-links-and-references/7...
But centralization is good until someone gonna try to censor and deplatform your project or it's contributors. And this can happen for all kind of reasons starting with non-exiting copyright infringement (like with popcorn-time), bypassing some DRM or creating tools that can be used for malware development or even breaking ToS on some API.
Today people think it's good idea to deplatform people for their political views or ban them based on region where they living, but tomorrow that's can happen with software projects too.
What is "better centralized" and what advantages do you think centralizing it brings? Git itself is literally a reaction against having centralization.