This is the best idea since Blossom. If I understand it correctly the plan is to create a cloud of servers that host Git repositories and that each programmer can be affiliated to (just like you can do with Blossom servers) and they will host all your Git repositories (such that if one of them is down the repositories can always be found on the others) and everything is automatically addressed and authorized using Nostr keys, repositories are discovered using Nostr events and the magic can work easily. I've been trying to self-host my repositories at https://git.fiatjaf.com/ for a while now, and keeping the server running and safe from the aggressive AI crawlers has been a challenge. My intent was to make a nice self-hosted server with a NIP-34 integration so people could send patches (the biggest hurdle these days when using anything to host your code except for GitHub is that it's too hard for external people to contribute), but that integration was never finished and I couldn't even focus in getting the "self-hosted git" part good enough. The truth is that, even with the best self-hostable software ever, still most programmers wouldn't run it. I had hoped that someone was going to make a service that hosted repositories on behalf of others, and that NIP-34 integration would make that automatically interoperable and easy for external contributors, thus removing the network-effect that GitHub has and enabling competition between multiple providers. @gsovereignty had hinted at building something like this at some point. That could have worked, but at least problems would have remained: even if repositories were addressable via Nostr, the URLs of the git repositories would have remained too important and fragile, and so people would have still become more-or-less dependent on these services and on DNS; that and it would still be a hard thing to send any contributions to repositories that didn't fit in a "patch" Nostr event. The natural solution for the big patch problem is to have your changes pushed to your own Git server as a branch, than propose that as a change to the base repository, asking the owner to pull them from your server and merge them upstream. We can call that a "merge request" or "pull request" if you prefer. But before this new revolutionary idea from @DanConwayDev that flow would be arcane and hard, but if we have a new Blossom-like protocol that makes it easy and straightforward to setup new Git repositories and push branches, all automated, pre-authorized and authenticated with Nostr events, the problem becomes as easy as uploading an image. At the same time I don't have to worry anymore about making a nice self-hostable Git server with code browsing HTML UIs and all that stuff: now Git servers can be basically headless and the job of browsing code and patches and whatnot can be entirely delegated to NIP-34 clients. We can kill Radicle now.
DanConwayDev's avatar DanConwayDev
image https://ngit.dev/relay introducing ngit-relay, a Nostr-permissioned Git / Relay / Blossom Service Protocol. A complete, self-hostable data solution for Nostr Git repositories.
View quoted note →

Replies (71)

👀
fiatjaf's avatar fiatjaf
This is the best idea since Blossom. If I understand it correctly the plan is to create a cloud of servers that host Git repositories and that each programmer can be affiliated to (just like you can do with Blossom servers) and they will host all your Git repositories (such that if one of them is down the repositories can always be found on the others) and everything is automatically addressed and authorized using Nostr keys, repositories are discovered using Nostr events and the magic can work easily. I've been trying to self-host my repositories at https://git.fiatjaf.com/ for a while now, and keeping the server running and safe from the aggressive AI crawlers has been a challenge. My intent was to make a nice self-hosted server with a NIP-34 integration so people could send patches (the biggest hurdle these days when using anything to host your code except for GitHub is that it's too hard for external people to contribute), but that integration was never finished and I couldn't even focus in getting the "self-hosted git" part good enough. The truth is that, even with the best self-hostable software ever, still most programmers wouldn't run it. I had hoped that someone was going to make a service that hosted repositories on behalf of others, and that NIP-34 integration would make that automatically interoperable and easy for external contributors, thus removing the network-effect that GitHub has and enabling competition between multiple providers. @gsovereignty had hinted at building something like this at some point. That could have worked, but at least problems would have remained: even if repositories were addressable via Nostr, the URLs of the git repositories would have remained too important and fragile, and so people would have still become more-or-less dependent on these services and on DNS; that and it would still be a hard thing to send any contributions to repositories that didn't fit in a "patch" Nostr event. The natural solution for the big patch problem is to have your changes pushed to your own Git server as a branch, than propose that as a change to the base repository, asking the owner to pull them from your server and merge them upstream. We can call that a "merge request" or "pull request" if you prefer. But before this new revolutionary idea from @DanConwayDev that flow would be arcane and hard, but if we have a new Blossom-like protocol that makes it easy and straightforward to setup new Git repositories and push branches, all automated, pre-authorized and authenticated with Nostr events, the problem becomes as easy as uploading an image. At the same time I don't have to worry anymore about making a nice self-hostable Git server with code browsing HTML UIs and all that stuff: now Git servers can be basically headless and the job of browsing code and patches and whatnot can be entirely delegated to NIP-34 clients. We can kill Radicle now. View quoted note →
View quoted note →
I took it as storing the git blobs in blossom and using events for the metadata. hard to know, didnt look at the code
To be fair the write-up on that page is not the clearest possible. I think @DanConwayDev may be working on a better protocol description. The idea as far as I know is just that there may be many Git servers anywhere -- like Blossom servers -- that host repositories from anyone (maybe they'll ask for a pre-payment, maybe they will have a free quota for some Nostr users and so on) that you can just push your repositories to. And your pushes are pre-authorized by publishing a Nostr event beforehand that says what is your repository state (branch=commit, HEAD=branch or something like that). Then when announcing your repository you can include multiple git+http URLs to these servers that people can clone the project from. And Git-enabled Nostr clients can contact these servers to download and display source code and Git history data. It's a very simple idea but a very powerful one.
What do you want to use Torrents for? This is about Git repositories, not filesharing. I like torrents, I experimented with making torrents the default for Nostr image sharing but they would never gonna make it because HTTP image download is just magnitudes easier. Blossom makes these HTTP links more resilient and safer, optionally.
I would keep experimenting with making them the default for image sharing, and we should definitely use torrents more for videos and music. My caveman brain can't even code, but I think git repo torrents would also be fine with the right infrastructure in place. BitTorrent for hosting full version snapshots, as many as the community feels like seeding; nostr for actively collaborating on each snapshot to develop updates
These are fine ideas in theory, but the amount of complexity and necessary code and network-effect they would require in practice should be factored in your thinking.
Alright, I read your post and didn't know enough to understand it, but I saw DNS reliance was part of the problem it's trying to solve What if we made it Tor-only and used onion services to solve DNS reliance? Or what if we moved DNS to a blockchain or solved it some other way? Is this still relevant for other reasons?
For anyone just joining in: I smoke weed every day and don't use other drugs, alcohol, etc. This has nothing to do with the conversation but apparently yet another npub is trolling me and making me clarify basic facts about myself because I'm much more focused than others and as a result I get targeted with a lot of harassment
To be clear - been on nostr over a year without trying to quit weed or making any other statements that would be construed into a context for this It's just a totally random accusation, and gangstalkers do this because it's confusing to onlookers
Traditional file hosting: - Files have arbitrary URLs (like example.com/photos/image123.jpg) - Single point of failure - if the server goes down, files are gone forever - No built-in verification that you received the correct file - Centralized control over content availability Blossom: - Files use hash-based URLs like blossom.primal.net/c1aa63f983a44185d039092912bfb7f33adcf63ed3cae371ebe6905da5f688d0.jpg - Multiple server redundancy - users can specify primary and mirror servers - Automatic verification - the hash ensures you get exactly the file you requested - Seamless failover - apps automatically try backup servers if the primary fails - Censorship resistance - users can switch hosting providers without breaking existing content Practical Benefits: - Verifiable authenticity: The hash in the URL guarantees file integrity - Redundancy: Automatic mirroring across multiple servers prevents data loss - Censorship resistance: Easy server switching without breaking links in existing posts
In what way it works better than anything you aware? Blossom also has not bans in the same sense the nostr has (redundancy of relays) Blossom also can improved to fix its problems (it’s an open protocol)
there are multiple differences between the design of blossom and the design of bittorrent. but the most important are probably: - Responsibility model: BitTorrent relies on random volunteers to keep your personal content alive forever. Blossom lets you take responsibility by choosing and paying for your own hosting providers. - Content survival: Your vacation photos work great on BitTorrent if millions of people want to seed them (they don't). Personal content dies when seeders lose interest. Blossom keeps your content available as long as you maintain your servers. - Economic sustainability: BitTorrent depends on altruism at scale. Blossom uses proven hosting economics - you pay for what you need. BitTorrent has existed for 20+ years but zero Nostr clients use it or considered using it for media hosting. Blossom is new and already has multiple clients and servers adopting it. what is the reason for that in your opinion? they are not familiar with bitorrent?
I don’t think “grifter mindset” is very common in the nostr developers ecosystem. To my understanding people are motivated mostly by technological passion and freedom values. So I tend to think the reasons are mainly in the engineering realm.
I don’t know if “being tested” by authorities is one of the main objectives in this stage. And anyway I don’t see why it would be less effective in that aspect. Blossom is much simple architecture. Basically the simplest approach apart of regular file hosting. This is major advantage. You basically get redundancy, censorship resistance and verifiability with almost no cost of complication. Maybe BitTorrent and seedboxers is also easy to integrate. But I don’t know. It seems more complex.
Maybe. Nostr may adopt some p2p elements one day. P2P is way harder. That’s way nostr is not based on that (although it may get added one day). I think the same thing goes to blossom / BitTorrent question. Simplicity is important
Josua Schmid's avatar
Josua Schmid 6 months ago
Let me digest the Github aspect here: Github works so well because of the centralist social aspects. Code gets reputation with stars, open issues/prs, code age. It‘s ratings, conversations and applying patches which became much easier with „pull requests“ than with mailing lists and patch files. The role nostr should play in this analogy is that it should make all the Github-goodness uncensorable, right?
jonas 's avatar
jonas 5 months ago
This 👆 This is one of the best features. Forks, stars and interaction. It’s always good to get a track of how maintained a repo is based on the feedback and interaction between the developers and users.