sommerfeld @sommerfeld - 7mo
I want to create a nostr-github bridge bot: if you open an issue/PR on nostr, it should be seen on GH and viceversa. Bridges are essential to foment smooth adoption. Why pick one or the other when you can have both...
I have nothing yet, this is just something that has been brewing on the back of my mind while I take a shower. I just think repo maintainers have no incentive to manage 99% of issues on GH and the rest on nostr. That won't work, even if they like nostr, managing 2 separate issue trackers is a big no.
Looks interesting but is it bridging github with nip34 events?
I have heard about nostrocket on your pod. Great idea albeit ambitious. I just checked the spec for NIP-1971 and it looks more like a replacement for complex issue tracked used internally within companies (like Youtrack, altassian, jira, zendesk, redmine) more than GH issues (which are rather simple). Would love to see it to fruition! For now I will focus on bridging NIP34 events, gotta start small.
My thoughts are to iust enable the bridge on repos that already voluntarily signaled a nip34 repo annoucement. There should be an easy clear way for them to opt out of the bridge (weird decision, if they already enabled nip34 but ok, won't blame them). After that, we can think of how to do better spam prevention (only mirror "qualityx npubs, etc).
My repo uses my personal git server as primary, github as a mirror: https://gitworkshop.dev/repo/sentrum If people mainly use GH for the social aspect and we can steal that with nip34, I believe people will naturally use other git servers since they won't depend on GH so much anymore.
You're right, PRs are much more complex to mirror, although I still think it should be possible. If someobe creates a PR on nostr, it could be mirror by a PR created by the bot (which would have permissions to push to its fork). It's hard, but doable. Let's start with Issues only...
sommerfeld @sommerfeld - 5mo
Btw, I've actually already started working on this and it's being going great. Hardest part now is making sure no issues get duplicated by running the bot multiple times. My goal is to do it in a reproducible way without the need to keep a local state. #devstr nostr:nevent1qqsv7q8fhc7uzkgw4v6xrpffwqjyekg9gskxyrz0hyf99h8mfulhg4cpz3mhxw309akx7cmpd35x7um58g6rsd3e9upzp5x7h70mzt00s86r6lrfg2dm0pyp9tq7f5k48gszmd42cl4yk3nvqvzqqqqqqyw8m28t
