Leo Wandersleb on Nostr: That's exactly the reason why I was browsing to this repo. I think, jack will at some ...
That's exactly the reason why I was browsing to this repo. I think, jack (nprofile…s480) 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.
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.