Subnostr

I think git objects are for a different hosting system than we have here. Git is for working the files. Nostr is for sending the notes about them.

I think you're right on the money with putting the social side on Nostr being the best use.

However, git data itself is just text about the history of the repo. Commits over time. what the parents are, what I've changed. The data itself is also all text, or encoded data into text. Use of it is doing some work in a text editor and then recording that in git as checkpoint in time.

It seems to me you could export to a series of notes and also rebuild a git repo from these notes if they were all on the relay, to be found and parsed.

Matt 🚀 2y ago

You certainly can, I’ve already done that (wrote a git-remote-helper which would create (or pull) events) these events where as you says the individual objects and refs of a repository, it works but it’s a very bad idea for many reasons. So although we can, we definitely do not want to store a repo with events.

Here’s a couple screenshots of a prototype I built around this a couple weeks ago. Getting repos pushing/pulling over nostr and storing the contents of the repo is not the problem, that was easy, the problems come when some events exist on relay and not another depending on collaborators relays when pushing, this could be solved by storing the relay to publish to along with the repository metadata but I wouldn’t want to rely on a relay storing each git object. Nostr for social side is the way to go, git server sending updates to nostr relays as and when things happen but not the git objects themselves. That was the output from my exploration.

Note in the screenshot before pushing anything to a repo the remote protocol (nostr://)

Reply to this note

Please Login to reply.

Discussion

⚡A C V⚡ 2y ago

That sounds like you're allowing multiple collaborators to a single 'nostr' repo. Thats not likely a good idea on a public relay system. I was thinking a repo would belong a single identity. A 'nostr' repo for each identity involved as if each participant had their own 'public' hosted git remote repo, instead of collaborating together on a shared hosted repo.

It seems to me we would know if we constructed the notes correctly, if we lost one in the middle of the chain of commits, right? It should be pretty rare to lose a message when its broadcast to many relays. Git objects aren't appropriate because they're not chained. Everything would have to be in commit notes, with parents and timestamps. Git objects would be rebuilt as instructed by a series of patch contents in fully detailed commit notes.