4 ms·

Git commits also rely on hashes, so there isn't a huge mismatch. The main issue is that each commit would become a separate torrent, so you'd need some abstrac

Git commits also rely on hashes, so there isn't a huge mismatch. The main issue is that each commit would become a separate torrent, so you'd need some abstraction on top to clone a whole repository (you'd need to download all the torrent-commits). OTOH, when updating a repository you'd only pull new commits (just like other transports). I've toyed with the idea in the past, but it's a substantial amount of work.

miki123211 3y ago
Fetching the commits isn't the problem, knowing which commits to fetch is. You need some way to assign a stable identifier to a repository and to query for the current tip of the master branch from that identifier. This can be done naively by using public-key cryptography and DHT nodes storing signed {timestamp, commit_hash} messages, but this is wildly insecure against key compromise, which (as Bitcoin and others have shown) is pretty much inevitable. You'd probably need m-of-n signatures and some way to do key rotation, and that's not easy to do if you can't just run arbitrary programs, like you can on the EVM for example.
- k8svet 3y ago
  Also, I'm guessing by time you go down that road, you wind up re-implementing Radicle.
  - miki123211 3y ago
    I don't think you need radicle TBH, there's nothing in this use case that requires a custom blockchain or even a token (if you're willing to accept UUIDs instead of human-friendly repo names). A simple smart contract running on EVM / Solidity with no financial incentives (except the gas fees of the underlying chain of course) would do nicely. That means you get nothing out of it as a developer, though, and there are very few people willing to do crypto stuff and not interested in $$$. You still have the problem of incentivizing hackers. In the Github world, hacking the author of a major project is bad but not disastrous, somebody is probably going to notice, ping the Github security team, and the changes will get reversed in a matter of hours. Hacking a major project on radicle or similar means that the project is now out of its authors hands, potentially forever, and there's nothing you can do, short of informing every single consumer and asking them to change the project ID they depend on. You can give a trusted team a way to override ownership in such cases, but then these people are also subject to being hacked or compelled by a court. Requiring multiple signatures and best practices around hardware wallets is probably the best you can do realistically, and that dramatically increases complexity and expense on the maintainers' side compared to traditional Git workflows.
    - k8svet 3y ago
      Last time I'd looked, Radicle had done a better job of decoupling the Git stuff, from the token stuff. But yes, adoption is always the issue with these sorts of things, unfortunately.

miki123211 3y ago

Fetching the commits isn't the problem, knowing which commits to fetch is. You need some way to assign a stable identifier to a repository and to query for the current tip of the master branch from that identifier. This can be done naively by using public-key cryptography and DHT nodes storing signed {timestamp, commit_hash} messages, but this is wildly insecure against key compromise, which (as Bitcoin and others have shown) is pretty much inevitable. You'd probably need m-of-n signatures and some way to do key rotation, and that's not easy to do if you can't just run arbitrary programs, like you can on the EVM for example.

k8svet 3y ago
Also, I'm guessing by time you go down that road, you wind up re-implementing Radicle.
- miki123211 3y ago
  I don't think you need radicle TBH, there's nothing in this use case that requires a custom blockchain or even a token (if you're willing to accept UUIDs instead of human-friendly repo names). A simple smart contract running on EVM / Solidity with no financial incentives (except the gas fees of the underlying chain of course) would do nicely. That means you get nothing out of it as a developer, though, and there are very few people willing to do crypto stuff and not interested in $$$. You still have the problem of incentivizing hackers. In the Github world, hacking the author of a major project is bad but not disastrous, somebody is probably going to notice, ping the Github security team, and the changes will get reversed in a matter of hours. Hacking a major project on radicle or similar means that the project is now out of its authors hands, potentially forever, and there's nothing you can do, short of informing every single consumer and asking them to change the project ID they depend on. You can give a trusted team a way to override ownership in such cases, but then these people are also subject to being hacked or compelled by a court. Requiring multiple signatures and best practices around hardware wallets is probably the best you can do realistically, and that dramatically increases complexity and expense on the maintainers' side compared to traditional Git workflows.
  - k8svet 3y ago
    Last time I'd looked, Radicle had done a better job of decoupling the Git stuff, from the token stuff. But yes, adoption is always the issue with these sorts of things, unfortunately.