Hacker News Reader

A bit of a naiive general question, but why are these things not layered on top of existing technology?

You already have Bittorrent for distributing files P2P. We "just" need an extra layer for discovering new updates/patches so that files can dynamically update/grow. These two problems seem fundamentally decoupled. The "git forge" aspect seems to be another fundamentally separate layer on top of that

View on HN

We tried. At first we built it on top of IPFS. It was much too slow. BitTorrent is interesting but we need a way to have mutability (repos change all the time). So we built the networking layer ourselves and the forge on top of that.

If you built a mutable bittorrent layer yourself (like ipfs but better), then why not make it its own separate thing?

If that's what you've managed to pull off, that's like a way bigger deal than a p2p gitforge (not that that isn't super cool in itself)

I guess architecturally why does it need to be coupled to git and a git forge?

It's optimized for certain workloads around code collab, so for now we don't want to oversell it. It doesn't have to be coupled with Git, though Git is very efficient at synchronizing changes. The protocol currently can be used for other things than a forge, but having an application influence protocol development is very helpful.

Reply on news.ycombinator.com