Yeah.
Discussion
Linux and Git probably need to be replaced, eventually.
Eventually, any kernel that bloated probably needs to be replaced. I have mentioned Uxn as one of possible directions. On the other hand, first we need to replace the networking stack... Like here is something in Uxn utilizing 9p protocol: https://hacklab.nilfm.cc/xrxs/about/
I'm a dunce at operating systems, I'm afraid.
I just see it getting increasingly bloated and it's turning into a big ball of mud.
And git is just so sticky because programmers all learn git as soon as they start programming and their brains get rewired that way. They literally become incapable of designing an alternative.
But maybe someone uncorrupted will eventually come up with something better.
For starters, let's define what this alternative should be capable of. Just to make sure not to reinvent Git again.
I'm thinking it should lean more toward configuration management and less toward strict source control.
Creating linked-lists of files (notes could be used for this) that are interoperable. The trust is created by the npub signing the list and his WoT would immediately see when he published a new list.
Or something like that. Something like composer does, for environments.
This would mean that someone else could publish a different list without having to ask the first person for permission, because they're not overwriting anything. They're just publishing their own configuration lists and signing it with their own npub.
And people could coordinate interoperability by agreeing on a range of compatible config lists that don't create conflicts within their use cases.
As one idea, if you force me to make one in 5 minutes. 🤣
OK, so basically blockchain of commits. Interesting. Need to meditate on that.
It would be rather easy to test the interoperability, if you had an agreed-upon test suite. Then they could just use any list that passed the test.
Test-driven configuration management. TDCM
Performance is what concerns me with this one though. As merging someone else's changes would inevitably require fully "rendering" both their and our chains into the final set of files, then creating a diff between theirs and ours, then creating a new "block" to implement these changes in our chain. Reliable, but quite slow.
Well, it would be more or less quick depending upon the size.
And couldn't older blocks be compressed, somehow?
If the blocks were notes, could you just make them replaceable notes?
It doesn't have to be an immutable blockchain, just a coherent one. Is that possible?
I don't know about that. Besides, replacing the older ones would make it impossible to revert to any previous state. Sometimes one needs that. In fact, this is one of the main Git's "selling points".
Still, this is something to meditate upon too.
Well, we've developed a NIP for versioning notes, so the replacement note says which note it's replacing, so you could still trace back to a previous state by pulling the previous version of that note back up and using it as a replacement for your replacement.
Then the chain would have layers at places where it was altered.
Git has this, with git replace. You always see the replacement commit, not the original.
Ok, now we're reinventing Docker/ZFS/OverlayFS, but on top of notes, that's even more interesting. That being said, if the versioning NIP is in place... Then I'd say about 60% of the concept is already there.
It's not in place. The PR has been sidelined because it's not a git-focused implementation. 😒
Luigi only uses the git.
Where can I find this PR?
What does Mario use?
I think "This specification is designed to provide the foundations by which file hosting and version control, akin to GitHub or SharePoint, may be implemented on Nostr." sentence was a bit excessive. Versioned documents exist in much more domains than just these two.
Also, why not just introduce optional "prev" and "ver" fields to NIP-01?
Because the NIP-01 stuff isn't supposed to be versioned, as it's the Twitter-clone base and for some reason, they don't want us editing our posts. (Everyone wants this, but oh well.)
Come on, NIP-01 still is in draft. I think *every* event should be (optionally) versioned, with the most recent version being the "source of truth" unless stated otherwise. Current clients can just ignore these fields if they don't want this functionality...
I'm not the one who isn't implementing it. 🤷
Funny that you say that, as our NIP was dismissed for the exact opposite reason. Basically, nobody has heard of any version control system, other than git.
https://github.com/nostr-protocol/nips/pull/997#issuecomment-1905954945
Now, THAT link contains some real nonsense.
Side question: how do current public Nostr relays treat event fields they don't understand (and that don't participate in the event signature)? Are they discarded or saved "as is"?
Is discarded, then any new fields must reside in tags, which is not very convenient for performance. If retained, then there is a chance to just extend some clients.
I don't really know. I haven't spent much time working with my relay.
Anyway, if we put the version info into tags, nothing is violated and this information will be relayed for sure. And such notes wouldn't be for a "normal" client consumption anyway, so, like they say, "it has a chance of working".
The problem is more that the Twitter-clones and Wordpress-clones would quickly fill up with version notes. They seem to display anything Kind1 and , so everyone has to pick other numbers.
Here is the blog one: https://github.com/nostr-protocol/nips/blob/master/23.md
30023 might work too. I mean, for source code storage, one could even choose 777777 to be sure not to clash with anything else.
Yeah, any random number.
I'm creating and posting wiki test notes, for someone else's project, and you can see them on njump. So, they do get through to the relays, they just don't get displayed in clients because of the unusual number. Which is good.
Well, that was my first, and last, foray into an OS repo. Obvious waste of time is obvious.
I understand, but "no one uses anything else other than Git" is a sheer example of narrow-mindedness. I think this platform deserves better curators.
I would rather it had no curators. I would rather I don't have to ask who I need to sleep with to get a PR through because there are no more PRs.
Mere humiliation ritual, IMO.
Why should anyone have to pass judgement on things that won't effect them?
The proof is in the implementation. We just wanted to have a public place to announce our idea, but notes are better for that.
Nobody can stop me from posting a note and the idea got much more action on here, in the normal flow of posts, than it did rotting in their repo.
Fuck their repo.
Isn't that sort of the point of nostr? Permissionless development. You don't need a NIP merged by some centralised set of maintainers.
Yeah, the Nostr Central Committee rejected my idea and...
This was one of the main things that drew me to development on nostr
It's the only thing that has kept me from storming off. 😂
Other developers have left because they didn't understand that they can just ignore the repo.
Like, why can't Kind 1 notes be versioned?
They can.
Just make them like that and they're like that.
Yeah. A git repo was never the right vehicle for a set of 50+ specifications which are usually only dependant on one or two others.
A global state, which is embedded into a git commit id, is antithetical to nostr
But we do need a place to publish and discuss ideas and I'm going to use a note-based Wiki for that.
We're already doing that, really, by publishing in our various repos and then writing a note announcing it, but we could just skip the repo bit.
Sort of a developer knowledge base.
Do you have a spec for this?
nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf has a client and an upload tool I've used to create test notes.
He's added the whole "Zettel" aspect, which is 🤌, and I want to try loading some NIPs in, so that we can see how it all works and maybe make some adjustments.
I'm just going to move the NIPs all over to notes.
I'm going to move yours, too. Fight me. LOL
What's the client called? Do you have a link?
Here's his stuff.
I'd love to see the evaluation of the validity of a NIP, or a version of a NIP, scored in terms for ACK and nACKs from my WoT, clients implemented, clients that actively break it, etc. That would be more useful than whether it gotbmerged or not.
Trust-rankings, yeah, and interoperability and implementation stats. You could even have an automated test attempt to write notes according to all existing models and see if they're properly displayed and post the results (accepts NIPs with eventIDs bunchofnumbers, otherbunchofnumbers, etc.)
And I like my idea of "like" notes, so that you can increase trust for objects (including other notes) and notify your followers of them.
Would be cool to have a list of those "like" notes, so that you could keep track of your favorite things.
I got the idea from the highlighter.
Okay, GN. ☺️
Guess I should nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr because this is a hellthread now. 😂 Can barely read it.