Actually, I mean... using a local git to version events isn't actually a totally dumb idea.
nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn 🤔 The native version, instead of just the data dump as .csv?
Discussion
Nobody can version like git, after all. Could git-version all of your high-signal events.
I actually do that, already, for all of my long-form stuff, like 30041, 30023, and 30818.
Could also do lists. Would give you a local version of every list, to use as recovery. Could even look at versions of the list.
That's what Obsidian tries to do, right, with its vaults? We could do Nostr vaults, in the native version, in addition to the retainment history on nostr.land. Those cover two different use cases, really, as you could have local versions that you never publish to the relays, but just edited as drafts.
a nostr-style interface to a git repository would be pretty cool
A nostr app to view git repos that also uses a git repo. 🤝
Building that, right now, because WTF not, right? 😅
I put it in the enterprise tab, so that you have to auth to the gitcitadel.nostr1.com relay, to use it. otherwise, the page doesn't display.
you can even make it a structured version... a branch per pubkey, or a directory per pubkey, symlinks between a list of kind numbers and events of such. etc. and an endpoint that gives you the whole log via standard http-git
I was also thinking that you should be able to somehow link in your local changes to a repo, when viewing the ngit repo info. Like, as additional branches with a "local" flag, or something. Would just need to tell the system in which local folder you keep your repos.
one of the best things about this type of data is that it's all mutable. no merge conflicts. you can always merge any branch to any branch, makes scripting the git log writes simple
stella makes a custom nostr event store in 3... 2... 1...
it would be perfect for the archival use case. sic it on a bunch of other relays to subscribe to all their events and then charge a subscription fee to access it. it's not meant to be fast - it just has everything, grouped by npub and kind (and maybe address tag, so you are covered for searching all these book things).
We could do something like that for the git server implementation. we'll see.
well, i'm just sayin, you could use a git repo as a database back end for a relay. khatru has a pluggable interface for that. idk about what languages you work with, i know cody made a local relay in javascript and maybe there is a php relay too?
all it would be doing is interfacing between the nostr protocol messages to calls to write files in a directory and then call git commands to commit it to the log. it would just be a different database back end, essentially, one that you could also treat as a git repo via git-http.
nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 We have git running on the server, anyway, so that would probably be a useful backend for the GRW, right?
Doesn't even need to be a relay, since we can just put controls into the GUI and access it directly.
indeed, it could just subscribe to the relay and make commits based on the stream.
Yup.
Means you can version events independent of replacing them, as you could just auto-commit changes at intervals and then restore whichever committed even you like, with the event publisher I have in there, by entering the commit hash. I then pulls that version, removes id, sig, created_at, and then republishes it.
the unified searching and display, is cool, too. shows the local and remote git cards on the repo page. you can then filter for only local and view those or click on a a remote and the local branches are displayed under the git server ones. Pretty cool. Just using GitHub, for now, but Chip is gonna get me an API for our own server. Could do Gitea, OneDev, GitLab, etc. Might go add those, now. What else is out there?
I integrated account tokens, so that you can write to github from GRW. read is allowed, automatically, for public repos, but it's rate-limited to 60/hour and I went over that with testing. 😅 Okay, next feature, integrate account tokens from env...
also makes it easier to use private servers, right? need to see if I can hook up the GitCitadel OneDeve. 🤔
It's all just a shaky PoC, but it's helping me think up new integrations and functionality, and figure out how things work.
It's funny how everyone else is using AI to try to build real products, which is LOL.
Nah, this is what AI is good at: hacking out prototypes. And bug-finding.
yeah, AI is good at prototyping. it can help find bugs, especially by automating testing, but it can be laboriously slow at actually figuring them out. like, i use claude sonnet 3.7 with junie, and i think that if i had a model that actually knew Go's syntax and grammar rules, it would perform about 10x faster, so often i'm looking in its logs it's saying "oh, we have unused imports, this won't compile" like *duh* it is learning go all over again every time i do something with it. that is a pretty wasteful way to use it.
i also noticed that it doesn't seem to have a principle wired up in it, that if it instruments code with logging that the AI can then accelerate debugging this way. i suggested that in a bug report on junie that i sent out last week after blowing up the i think 128kb token buffer several times on one problem.
IMO the best use of git for Nostr events is for long-form content. Being able to, for instance, do version control on a full publication before it is broken down into 30040 and 30041 events and pushed off to relays could have a use case.
Smaller content, such as text notes or comments, are generally one-shot and don't really need versioning.
That said, git could be useful if one wanted to do version control on a local archive copy of one's Nostr profile and associated events. Dump everything into .jsonl files, perhaps.
Yeah, let's think of a smart git integration for the Tauri client.
yeah, that is precisely the use case i see it being for. the idea i see is that you store the document as unsigned collection of these events, that originates in an asciidoc master version. there needs to be a bidirectional codec between the master and storage format, and the rest is handled by standard git commits, and because the document is already segmented neatly, there should be very few chances of several people working on different paths having a merge conflict issue, but it can be fixed i guess. probably just to poll the log in case a user is editing a section of the document that has been updated in the repo.
git itself, for actual signed nostr events tho. so simple. everything is already atomic, there can't be conflicts, although there might be a problem with forks.