4 ms·

I have to say that reading the Radicle designers observations about git on IPFS I think they solved the wrong problem. I would love to be able to save and work

I have to say that reading the Radicle designers observations about git on IPFS I think they solved the wrong problem. I would love to be able to save and work with git repos on ipfs. 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.

outsomnia 6y ago
> better centralized What is "better centralized" and what advantages do you think centralizing it brings? Git itself is literally a reaction against having centralization.
mathnmusic 6y ago
I was wondering the same. If the Microsoft monopoly is the problem, why not just use non-profit Git hosting sites like codeberg.org? They run a Gitea instance and are being adopted by more and more FOSS projects.
- dboreham 6y ago
  Because if they become popular they'll be picked up by The Empire too. E.g. .org TLD debacle.
SXX 6y ago
Might be I didn't get your point; sorry then. 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.
Ericson2314 6y ago
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'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 https://github.com/radicle-dev/radicle/issues/689 [eth2-report]: https://discuss.libp2p.io/t/report-a-study-of-libp2p-and-eth2/229 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/730/24 https://discuss.ipfs.io/t/git-on-ipfs-links-and-references/7...
orthecreedence 6y ago
> 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?

outsomnia 6y ago

> better centralized What is "better centralized" and what advantages do you think centralizing it brings? Git itself is literally a reaction against having centralization.

mathnmusic 6y ago

I was wondering the same. If the Microsoft monopoly is the problem, why not just use non-profit Git hosting sites like codeberg.org? They run a Gitea instance and are being adopted by more and more FOSS projects.

dboreham 6y ago
Because if they become popular they'll be picked up by The Empire too. E.g. .org TLD debacle.

SXX 6y ago

Might be I didn't get your point; sorry then. 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.

Ericson2314 6y ago

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'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 https://github.com/radicle-dev/radicle/issues/689 [eth2-report]: https://discuss.libp2p.io/t/report-a-study-of-libp2p-and-eth2/229 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/730/24 https://discuss.ipfs.io/t/git-on-ipfs-links-and-references/7...

orthecreedence 6y ago

> 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?