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.
GitWorkshop.dev
Decentralized github alternative over Nostr
 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.
View quoted note →

Replies (6)

πŸ›‘οΈ
you could use Go and i already have a second draft blossom server written in go. i didn't write it. claude spun it up in about 3 hours and then another hour fixing it and i just haven't tested it yet. i know it works because it's just http and the tests pass, and i saw it accepting, and allowing me to delete a random blob several times. i just haven't used it. probably
ORLY?
 will already serve you with blossom. imma make sure you both have permissions in case you want to try it
πŸ›‘οΈ
my take on this is look into techniques used in computer games. i remember when GTA3 came out, and its most epic achievement was loading free inter-map transit. still very few games use this but it's a graph theory algorithm. this is the kind of thing you need to automatically, and quickly partition a map of related data. you need metrics of proximity and some kind of parameters for partitioning the map to fit the compute you need to do. it's not hard. but it may take a while to wrap your head around it. but graphs at high node count are N! style compute cost. so it only takes like 3 or 4 deep and you are practically at infinity as far as even the most powerful computers can do in milliseconds.
πŸ›‘οΈ
↩ replying to α΄›Κœα΄‡ α΄…α΄‡α΄€α΄›Κœ ᴏꜰ α΄ΚŸα΄‡α΄‹α΄œ
The problem is git enables many feature like shallow and parse cloning, packing specific object and data, getting specific files and git logs, etc. These are all battle tested on solid git server implementations. This is all not possible trying to reinvent a simplified git server with blossom.
πŸ›‘οΈ
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 πŸ€“
image image image image image