How do you mean βit requires other NIPs to workβ? My suggestions? Or NIP-01?
Discussion
NIP-01. It only seems standalone and easy, if you aren't starting from scratch.
I think most people actually mean "Kind 01", not "NIP-01", as they're using SDKs.
We're writing an SDK, so we have to cover quite a bit, to make one working client.
Does βfrom scratchβ include bech and elliptic curve crypto? And websockets? Or just protocol specifics?
Because I think NIP-01 can be as easy as a collection of shell scripts with GNU and Bitcoin tooling. Designing a proper SDK is a whole different story, but this is not due to the complexity of NIP-01. But it has to do with scaling architecture.
For example: my proof-of-concept relay implementation became stuck at the questions:
- why allow multiple filters?
- why not require sorted JSON in the note format (signing issues would be solved without the need for a binary format)
#[4] is working on the SDK core features
The most amount of my time has been spent on nip44 really. Sure you can slap some things together in a couple weeks if that. I did when starting off, then realized quickly this wasn't going to scale professionally.
I have no interest reinventing the wheel on secp256k1, and the bitcoin core library is great... Except its fucking huge when compiled. When noscrypt is done I want to lean into it and see if I can get it pruned down along with x86 (and others) hardware intrinsics support for performance.
Also proper portable crypto libraries turn out to be a nightmare too. Implementation details, but doing it right takes the most time.
I want my users to be able to snag a package or source code and run 1 (maybe 2) commands and be up and running.
this is my base reason for choosing to use Golang
unfortunately, the bitcoiner go devs are shit, whereas, ironically, the ethereum go devs are actually pretty good (been digging through that shit today for my paid gig) - and ethereum go devs are better than the cosmos devs too, which is funny... the cosmos devs code reminds me of C, whereas the ethereum code is more idiomatic
Probably need embedded guys to get good C.
no, just not gonna happen
but after 8 years learning to be an expert with Go i think i can take on plugging in more performant or widely supported C things... i've actually kinda been enjoying the challenge of interfacing Go with C this last few days
go is great for almost everything natively, but for everything else there is a good C library... the secp256k1 library is a prime example, the one made by the btcsuite/decred guys is sooo crappy i can't stand it
and UI is an area i can probably find a decently simple but complete C library that lets me finally build some "friendly" interfaces - without contaminating my eyes with javascript
oh, ahaha yeah, embedded, c, 100%
but there is tinygo which is basically Go without GC
makes concurrency and dynamic arrays/maps much easier while keeping things tight
Why don't you just use noscrypt with a Go wrapper?
^^^^ true
i already did it anyhow, i needed a neat little interface that makes it easy to dial back to the btcec signatures but also neat enough to use as a MAC for the noise protocol implementation i started working on (mainly for a secure shell)
it uses the bitcoin-core/secp256k1 library directly and can be used either for signing/verification or verification only, with minimal overhead, it's more than 2x faster at verifying and about 5x faster at signing, so it definitely has utility as an MAC, as it was i already had determined i could use it to snip packets into 1.5kb chunks each with a distinct signing key for 8Mb/s, so, being this was the big overhead it's probably gonna be more like 20Mb/s especially if the SIMD sha256 based CTR encryption is also 2x or better, the signatures are the biggest overhead
I try not to be a language maxi. To me C is pretty close to synonymous with the binary/assembly which is my attraction. I'm pretty dumb so being able to quickly understand/map my code to hardware is helpful I think. I stick to strict C89 features (or lacktherof). When I write it, I can pretty easily imagine what that stack and registers will look like. I spend at least one pass before a release looking at an assembly dump. I obviously don't spend too much time on it because modern compilers are 1000000 times better than I will be at this, but I would consider myself a defensive C programmer.
yeah, i'm similar but i choose Go, and so i also have to deal with sometimes working around the default memory management strategy (for this reason i switched event data structures to use raw bytes where by default common idiom is to use immutable strings (which cause your app to generate tons of garbage and can't be zero-allocation or zero copy)
I did the same with C#. Almost everything that requires more than a few bytes handles alloc/free on umanaged memory from high performance allocators that can be configured at startup. You will notice a class called VNString. An immutable heap string that is very similar to the string type in C# but stored on the unmanaged heap and 0 copy slices.
https://github.com/VnUgE/VNLib.Core/tree/develop/lib/Utils/src/Memory
yeah, it's a huge cost, managing garbage, and for Go the immutable string is definitely a liability for fast network message processing... i mean, switching to mutable bytes (not immutable string) sped JSON processing almost to equal to raw binary!
ah yes, you will understand this pretty good, i have been working with that library heavily of late, and you can change the precomputed vectors size, the downside is that you are trading memory for computation, you probably want to parameterise it for battery vs storage balance
Yeah... I figured something was up. I generally prefer larger static segments over runtime performance hits, it's just when compiled the binaries are nearly 2MB. So it balloons quickly. It also means embedded applications are limited.
well, if you got battery problems and storage problems at the same time, yeah, but that's elliptic curves for you
making small devices that use low power implicitly requires a bigger chunk of memory to store those precomps
i'm pretty sure that there is a fairly high size limit at which point the two cost the same in energy
in the early days, because of how shitty javascript is, #nostrudel didn't even verify event signatures, and probably this is still a thing with some of them...
this is why i find it comical that people consider nodejs a serious server dev language
it's slower and uses more memory than python!!!!
anyhow, so if your device has space, use it, otherwise, you have to try and avoid verifying signatures...
perhaps advise downstream devs to do signature verification only immediately prior to display, as very often mute lists will exclude them from display (and the comedy of that whole charade with web devs is another larf itself, especially for the snowflakes and angry drunk people being trolled)
The security thing is the big one. No one should be putting their nsec directly into a bunch of different clients.
If you're writing for browsers you need to support at least NIP-07 for note signing. Mobile and desktop need NIP-46 for secure signing. NIP-46 itself depends on NIP-04 and/or NIP-44 for encryption.
Major clients don't use note IDs, they use bech32 identifiers. Those are defined in NIP-19.
Replies and common indexed tag types are in yet another NIP.
Then there's the outbox model, which isn't really defined anywhere at all, but is essential for a client to work with a distributed set of relays. That's pure institutional knowledge.
I agree with all of this except the need for nip46. Thats a nice to have, but not essential.
nip-65 is where the outbox model's data is defined tho
it's up to clients to use it for publishing and fetching events (my outbox = publish, your inbox = fetch)
it really is defined:
