Thread

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

Replies (3)

yeah youd bloat the event with every object ref as the repo grows. not a great design but a fun poc. i wrote my poc in go. the code is actually hosted on itself, as the poc is a relay/blossom/webui all in one binary server. i also wrote my own git-nostr-remote for the client side. it was a fun hack and generally works for the happy path. no planning to pursue it. i can share the code if you’re interested in it.
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 πŸ€“