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. 

 Have you looked at the nostrocket problem tracker?  

 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. 

 Are people using Nip34 with github or just their own git servers? I don't want to dissuade you just wondering if the demand is there, still a fun project regardless though 

 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. 

 There are a bunch of projects that use GH for PRs and Issues and have created a nip34 repo event. eg gossip, amber, amethyst, ndk... 

 Not bridging to Big Tech/github.  It’s bridging to other encryption keypairs, like Ethereum push channels and other cryptos. 

 I originally thought projects should have to opt-in to being bridged to github.
I'm not keen for gitworkshop.dev or ngit to be bridged to github.
perhaps maybe it could be opt-out for projects which list github first in the the 'clone' attribute of their repo event?
 

 Another concern I had was around feature parity. There are some features that aren't built like Reviews, code comments on specific lines, etc and some that aren't possible.
What if someone pushes to an existing patch on nostr. The account wont have permission to do the same to the github branch. 

 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... 

 @b10c runs a backup script for bitcoin-core and libsec256k1. These are pretty useful to understand the structure of the data and what to expect.
core developer Fabian also created a one way bridge to a self-hosted gitlab. 
se https://delvingbitcoin.org/t/gitlab-backups-for-bitcoin-core-repository/624
I remember finding a python tool that seemed to be quite active - can't seem to find that now. I'm not sure why Fabian didn't use it. Maybe it didn't meet his needs.