Re:Radicle-Link: Extending Git with Peer-to-Peer Network Dis...
by Ericson2314 on Saturday September 05, 2020 @11:21AM
(#24384203)
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.
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...