I don't want nips to tell me how to design my data structures and API. Too many of you OOP devs leaking code abstractions into the protocol specs IMO. nip44 was a lot of work to abstract away from the API into an architectural blueprint. I enjoy reading scientific white papers and RFCs way more because it doesn't tell me how to write code. Even NIP01 couldn't explain the spec without code.
I'm just grumpy when reading
Same. The whole part about the NEG-MSG payloads is missing. What are the mysterious hex-encoded strings?
Right, and your highlighting the parts where I have to use my imagination to fill in the blanks. It's like either I copy your code example or fill in the blank and hope it works. At least with nip44 I had vector testing to anchor me
as far as i know, the Hornet relay is written in Go and has a better sync protocol than negentropy
What is its sync specification?
this is the relay implementation:
https://github.com/HORNET-Storage/hornet-storage
this is the codebase that implements this frangible variant of merkle trees:
https://github.com/HORNET-Storage/scionic-merkletree
i don't know exactly how well it works, haven't tested it, and actually i'm kinda facepalming right now because i was actually almost working with him but he never offered to pay me, i did some stuff and had a share of a bounty dangled at me and all this led to bad blood between me and him
but now i'm looking at it... here's a Go relay codebase that IS NOT from fiatjaf or mattn...
gonna give it a good poke
tbf it uses the zebedee library that is mostly fiatjaf but it looks like they wrote their own relay core
also, i had a bit of a look at it... not really that fussed over their architecture or naming schemes, and it looks like they use libp2p and ipfs as part of the protocol... didn't really want to dig too deep into it.. and it is worth emphasising that it's still early beta, but their GUI for managing the relay is pretty nice from what i saw
also, it has early stages of also implementing negentropy in it too
This.
The biggest mistake I see in the fiat spec world, is that they become bloated with everyone else's wishes.
I like the way that the NIP process has developed, though it has its criticisms.. It's reasonably organic, and the only mandatory NIP is NIP-01.
This process gives me a lot of flexibility. For example, I like NIP-04 because it gives basic secure notification capability for any npub. That's incredibly useful, but understand all of the metadata issues, so exploring NIP-17
Anyway, we have something great going here. These are good problems to have and sort out early.
I figure explaining the spec in terms of JSON is fine, since JSON is the structural framework of the protocol messages. But yeah mixing implementation details leads to confusion.
Less code examples, more Gherkin acceptance criteria.
this is the thing about OOP programmers, they are retarded
c++, java, rust, javascript... retarded
functional, imperative and structural typed have proven to be more efficient to compile and easier to reason about, many times over, these people are literally dumb turds
I just rewrote everything from functional to OO and now it's a hot mess and I can barely understand what I built.
Having OO regret.
Code blew up to 3 times the size and now I'm trying to refactor it back down. 😏
Agonizing over which class to put in which method and stuff, and I only have 4 classes, so far.
