Interesting. You'd end up with a lot of objects with that approach and eventually it would be too big for the event size. I thought about doing it with storing packs in blossom. Here is my code to play with that idea. https://gitworkshop.dev/danconwaydev.com/ngit/prs/note1s2au56ejtkfc5tqaduu2a6zp83xm80j2wmkjxx603y645jfrlq3qmp88s4 I would have made it into a POC if rust-nostr had blossom support at the time. It does now. It turns out that having a git server is way more flexible so ngit.dev/grasp came to be. Let git be git and let nostr be nostr.
Issues and PRs (kinds 9803/9804) are automatically published to nostr on handled status changes (merged, closed and reopened).
I fetch them from source if possible on import of the repo and try to aggregate those by their timestamps with the nostr kinds.
If source is lets say Github im not upstreaming the edits additionally there so far.
Anyway still needs polish in finding these kinds better and flows are surely not the endgame, but what i went with so far 🤓
Yep. An expanded git-nostr-bridge (similar to but not a GRASP server) that accepts SSH connections. When smo wants terminal/CI access, they publish their SSH public key as a Kind 52 event, and the bridge automatically pulls it into authorized_keys. That lets them git clone/push against git.gittr.space, just like hitting any GRASP server.
It isn’t the source of truth—every push still emits the NIP‑34 event and Blossom/nostr:// pointers—so anyone can ignore our bridge and sync the same repo via nostr:// or their own mirror. We just provide the SSH path for convenience and compatibility with stock git clients :
https://gittr.space/help#ssh-keys
In the DEPLOYMENT_GUIDE.md theres a “Bridge Explained” section that tells how i keep Strategy 4 metadata while layering an SSH/HTTPS bridge on top.
https://blossom.primal.net/f5637bed27a1b2e3c42a3d5132997be74bc386d237b86e97b0679f25a5e77fd6.mp4
Whats a blossom pack? is it related to the blossom pack idea i outlined in nostr:nevent1qvzqqqqx2ypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqqsg9w72dve9myu29swk7w9wapqncndnhe98dmfrrd8cjd26fy3lsgsnkqr9d
yes, “Blossom pack” here means the optional Strategy‑4/5 hybrid that publishes ["web","https://blossom…"] tags pointing at pack files, exactly like the approach you suggested afais
Yes, a lot. Pls check the docu files :P https://gittr.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr?path=docs
Those are placeholders in the docs;. As said the real repo cards include the live nostr://npub… links, and they’re meant to be consumed via git-remote-nostr. https://gittr.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr?path=docs&file=docs%2FSSH_GIT_GUIDE.md
"Strategy 4 compliance: We never embed file blobs in the NIP‑34 event content. Every push still publishes the full tag set (clone URLs, nostr:// targets, r tags, etc.), and the bridge subscribes to all relays just like any other GRASP/bridge. Anyone can ignore our hosted URLs and pull directly from a nostr:// source or Blossom pack.
Why the bridge exposes /api/nostr/repo/files: That’s an extra convenience layer so the web UI (and other clients) can fetch file content faster while the data is still propagating. It’s not a proprietary format—just a REST wrapper around the bare repo the bridge synced from Nostr. Think of it as Strategy 5 (local caching) layered on top of Strategy 4.
Trusting state events (kind 30618): We do honor them. When a repo already has a 30618 “state” event, the bridge uses that to verify refs before falling back to the clone tags. If there isn’t one yet, we rely on the clone URLs so users aren’t blocked while waiting for the maintainer to publish the state event."
The “bridge” isn’t the source of truth, but i use it as accelerator. Repos are still announced and mirrored via NIP‑34 events (and, when needed, Blossom packs), so any relay-based client can fetch the same metadata/files straight from Nostr. I added some tags btw for docu-links to them etc. The git-nostr-bridge just watches those events, keeps a local bare repo for fast HTTPS clones, and exposes an API so the push ends without waiting period for relay propagation. Like a GRASP server but different :P
Jo, I include https://git.gittr.space/... as the primary clone tag on push by a new endpoint to the bridge so theres a guaranteed HTTPS source while it’s processing. Once other relays pick up the NIP‑34 event, the nostr:// URLs are broadcasted and should work. http://gittr.space/help#git-operations
if you open the clone-url section theyre shown on each repopage
Jo, I include https://git.gittr.space/... as the primary clone tag on push by a new endpoint to the bridge so theres a guaranteed HTTPS source while it’s processing. Once other relays pick up the NIP‑34 event, the nostr:// URLs are broadcasted and should work. http://gittr.space/help#git-operations
Repo read is still done on the client for the events and the bridge fetch, so thats due to the storage/cache + binary fallback, not SSR.
Flow is described here https://gittr.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr?file=README.md
Jo, I include https://git.gittr.space/... as the primary clone tag on push by a new endpoint to the bridge so theres a guaranteed HTTPS source while it’s processing. Once other relays pick up the NIP‑34 event, the nostr:// URLs are broadcasted and should work. http://gittr.space/help#git-operations
Welcome to the Git Nostr community! Its great to see you are building and that you're building on the existing work in the space.
It looks like you may have started with a fork of an early git nostr project that created a github like UI that had ideas about intergrating https://github.com/spearson78/gitnostr which emerged at the time and but was quickly abandoned. I see with gittr you have taken that idea and run with it and also began to try and reconcile / add / intergrate new Git Nostr invovations such as GRASP with spearson78 approach. I'm not sure how easy that would be as they don't appear to be compatible. The active work in Git Nostr space all seems to be based on NIP-34. Would you consider change gears towards NIP-34 / GRASP for greater compatibility with the ecosystem?
What a fantastic event @bitfest was with shitloads of jaw dropping POW in the workshop area and the most lovely psychopaths on earth to hang out with !
And those kids, man, they started vibe coding and writing games and OMG you're all not ready for what's going to happen next 💜👾 
GM from nostrshire #bitfest 
Yes, the state of the software PR also smelled like changes incoming.. DMing to catch up on this
Welcome to the Git Nostr community! Its great to see you are building and that you're building on the existing work in the space.
It looks like you may have started with a fork of an early git nostr project that created a github like UI that had ideas about intergrating https://github.com/spearson78/gitnostr which emerged at the time and but was quickly abandoned. I see with gittr you have taken that idea and run with it and also began to try and reconcile / add / intergrate new Git Nostr invovations such as GRASP with spearson78 approach. I'm not sure how easy that would be as they don't appear to be compatible. The active work in Git Nostr space all seems to be based on NIP-34. Would you consider change gears towards NIP-34 / GRASP for greater compatibility with the ecosystem?
Hey, I parse and display nip34 from 30617, use grasp to clone and publish kind 51 instead of 30617 and Jason not tags based so hybrid until PR is save. Reading yes, creating not yet
So its ready to let you ⚡zap repos, ⚡open bounties for issues, 👾import them from git/github/codeberg, 👾push to nostr...
Check this out and let me know what you think 💜
https://github.com/arbadacarbaYK/gittr/
It has a proper project planning per repo, you can add documentation links to it (like youtube), it shows a mermaid architecture graph and dependencies.. and so much more i always wanted 😜 because fuck them.
