Thread

That's exactly the reason why I was browsing to this repo. I think, @jack will at some point pay the bounty but to a project that ultimately will not make a dent. Some teams started cloning GitHub but with relays as backend. Jack to my knowledge never defined what he would consider a valid solution and that's why I think that these GitHub clones might end up getting the bounty. I think the main component of a real solution should revolve around discoverability and cross instance merge requests. For example, when reviewing Android wallets I usually search for the appId on GitHub and conclude it must be closed source if I can't find it there. This heuristic is right 99.9% of the time. If the solution doesn't cover finding stuff on GitHub I don't think it will be able to break the network effect. On the other hand, storing commits on relays doesn't fix any problem but probably generate a dozen new problems. Git is very well understood as a server for commits and mirroring is common. There is no benefit in using relays for this kind of data. Where I see nostr being interesting is for: * logins: use your pubkey across instances * events that store where to find stuff: records of repository clones for example * code reviews: imagine a GitHub PR and a code review on nostr. With the right browser extension you could import that code review into your GitHub project or open it on a mirror that has better support for interactions with the code review. The latter would allow to mention the reviewer on nostr etc. * merge requests from other instances: Git already allows me to clone open source projects from GitHub into my Gitea or GitLab instance. If I could open an MR towards a GitHub repo I could link to that in the issue that is fixed by my MR for example. Again, a contributor could use his browser extension to import the MR which could mirror my git branch into their repo and open the MR under the member's name.