Nostr Web Client

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

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.

Reply to this note

Please Login to reply.

Discussion

DanConwayDev 1mo ago

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

i'm definitely with you on that. i personally would even suggest to not even write one single bit of code that handles git. palm it off to Linus' excellent implementation and then see what it misses.

i always envisioned that nostr was just negotiation rendezvous easy inbound connection. i've already tried to work with an attempt to clone the core features of git, in pure Go, and it was endlessly problematic with even minimal lag between their work and what the git project has already progressed to.

git is just a unix shell protocol, based on stdio and unix filesystem. don't over think it. the protocol only needs to provide the correct references and paths.

DanConwayDev 1mo ago

The reference implementation does exactly that. It uses nginx to pass request to the git-http-backend CGI scripts maintained by the git project.

DanConwayDev 1mo ago

It turns out that the http wrapper (CGI scripts) is not that complicated. There are nearly 3 grasp implementations that do this bit internally. This enables shipping a single binary and handling the authorisation *before* the data is sent.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

i dream of a day, where other people understand that most things are just pipes and shells and access control. if you ever read me on a regular basis you kknow the last point is my biggest gripe with most devs, and i already have experienced first hand how hard it is to explain the first two to most devs.

networks are just pipes with extra steps.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

also, it's just combinatorial stuff. you can't efficiently deal with multidimensional graphs, you want to stick with stuff that can be flattened into a 2d representation. branches and layers are basically exponentially more complex.

git is built on the directed acyclic graph geometry. there is a lot of shortcuts because you don't have to escape loops.

DanConwayDev 1mo ago

I'm sure the midcurve meme apply here with 'just let git handle that'.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

you mean, the retard and the jedi saying that, of course.

yeah, don't reinvent the wheel if you don't have to. servers that translate between protocol and git is quite trivial to implement. this is not realtime, low latency requirements here. even as much as 5 seconds to lay down a commit and propagate it is fine.

never prematurely optimize, and don't roll your own if you can just assemble someone else's stuff into a shape that meshes with your actual part of it.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

speaking from experience. even since picking up LLMs to help me with this, there are many things that just are not practical to do of such scale in any sane amount of time.

it was a harsh burn discovering that i couldn't do git stuff in pure go. the go version just isn't nearly adequate. it seemed to be working, and then i got all this mess going on. what was the error? i forget, it was some protocol network shit iirc. annoying af.

thats' why https://git.mleku.dev/mleku is just a plain gitea. i wanted to just host only my repos, and not have that stutter in the URL.

i spent probably weeks trying to get that working, and in the end, it was futile. linus seems to be turning into a javascript ninja with all his fucking breaking changes this last few years. fuck that guy.

just use his binary and interface to the git repo using it.

the bitch has got too complicated to build from scratch. oh, sure, we could do all kinds of things involving metadata on nostr and all that shit but you really should just pause, before you race off and do that, and go clone the git repo, and tell an LLM to explain it to you. 30 screenfuls of documentation later, you will be in agreement with me.

nah, just call git via your preferred language method for executing child processes. the end.