Thread

Thank you, sir 💜

Why was Python written in C and not in Python? 😀

Because 4MB limit .. but it will come 😀

XDDDDD

:) Here you go :) https://gittr.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr

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

O cool. Do you mean until your confident your app won't create noncompliant NIP-34 kinds?

Yes, the state of the software PR also smelled like changes incoming.. DMing to catch up on this

Check, mate 💜✔️💜 https://gittr.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr

Your making some fantastic progress on this and quickly. Can you fix your announcement event so it clones from the `nostr://` URL? Files in repos are loading really fast. Are you SSR them?

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.

gittr

gittr - Decentralized Git Hosting on Nostr

A truly censorship-resistant alternative to GitHub built on Nostr.

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 💾.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr

if you open the clone-url section theyre shown on each repopage

in strategy 3 grasp servers dont expose "/api/nostr/repo/files" or "/api/git/file-content?sourceUrl=". are you saying you have a bridge that servers the files over that API ie go to strategy 5?

strategy 4 - files are never embedded in event content. isn't extracting the clone urls just strategy 3? You should look up the state event `30618` and if there is one trust that rather than the refs provdied by the clone urls. by the looks of it, 99% of files are going to be delivered from your bridge, so i guess that should happen there also.

I don't understand how a bridge is a decentralised git server. Do you mean they are stored on grasp and access via a bridge for efficency?

I dont understand your recommended option. how can you use ssh? Are you offering a centralised git server permissioned via ssh keys?

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

Option C links to a repository that doesnt exist. ngit has the git-remote-nostr plugin that enables cloning via `nostr://` see ngit.dev/install

yes. 💾.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr

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

how are repositories mirrored via NIP-34 events? In NIP-34 git data is only stored on git servers. are you are storing the files in nostr events? Do you have a spec you are working towards that outlines the primatives you are using?

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. 💾.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr

Whats a blossom pack? is it related to the blossom pack idea i outlined in

Yes, a lot. Pls check the docu files :P https://gittr.space/npub1n2ph08n4pqz4d3jk6n2p35p2f4ldhc5g5tu7dhftfpueajf4rpxqfjhzmc/gittr?path=docs

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

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 :

gittr

gittr - Decentralized Git Hosting on Nostr

A truly censorship-resistant alternative to GitHub built on Nostr.

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.