Git is just a filesystem thing, a CLI really. it's not a network protocol. the plain SSH thing is just an interface to a filesystem, and the HTTP is just also an interface to a filesystem. it's not like a network connected database. even if you are making servers that interface another API to git the client and the server are supposed to be doing some kind of synchronisation of files. i don't see how an interface to nostr would be any different to to NWC - just using the relay as a middleman, a network transport. maybe you would store some metadata in the relay but it would be horrendous trying to make the relay into the filesystem.
Discussion
The issue is it's not. The git smart http transfer protocol does require some server leverage. The wire format is not documented in detail. It's supposed to be, but the links are dead the files were removed from the github repo at some point.
The server sort of treats the files as a bare repo with some leverage to build the pack results.
damn
well i gotta say, i'm not surprised. there is a Go http git server and it doesn't entirely work correctly with the C client. that would explain it.
reverse engineering is not how you should have to implement this shit.
but i'm puzzled, why can't you generate WASM or something by using the source code for the implementation.
an alternative is to create a TTY interface of sorts with the relay, should be possible most of the time to just fill a buffer and then put that into the content of an event as a transmission. wouldn't need to exactly work the same as a TTY with each byte being individually written and dispatched immediately.
it's an example of my contention with nostr:npub1gzuushllat7pet0ccv9yuhygvc8ldeyhrgxuwg744dn5khnpk3gs3ea5ds about not messing with ephemeral events by adding a buffer queue to allow clients to transparently catch up when they are briefly offline or disconnected. this should be on the application not on the relay because the more events that the relay has to run filter matches on, the higher the response latency will get.
personally, i would even go further and actually make a protocol extension using a header that does it all neat with a binary packet format, with encryption included, then it would function almost identically to a proper rendezvous router.
anyhow, this definitely would be a good case for wasting a few hours with a coding agent to extract all of that part and produce a specification.
unfortunately, Git has grown like a tumor in the last 20 years. didn't require C++ programmers to get that way either. i'm not sure that Linus is actually as good an architect as he is at doing kernel programming.
but yeah, it is insanely difficult to set up git http using the git http thing. i tried for many hours and gave up. i didn't even waste my time until for whatever reason, some upgrade to git, broke my go-git http and since then the only way i know to get http with git is using gitea, i never dug into the code of that project, but i know it works.
That was the point we were at.
that's why i was talking about using ephemeral messages as an interactive TTY instead because the protocol is not bidirectional anyway, it's all just send comand to terminal. i don't see why they can't just be - basically, like SSH over nostr, except not interactive, or at least, the git client is not going to speak one character at a time it will spew a blob and then wait for a response