Nostr Web Client

Does “from scratch” include bech and elliptic curve crypto? And websockets? Or just protocol specifics?

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.

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago 💬 2

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

Laeserin 🇻🇦 1y ago 💬 2

Probably need embedded guys to get good C.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago 💬 2

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

Laeserin 🇻🇦 1y ago 💬 2

Why don't you just use noscrypt with a Go wrapper?

ChipTuner 1y ago

^^^^ true

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

ChipTuner 1y ago 💬 1

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago 💬 1

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)

ChipTuner 1y ago 💬 1

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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!

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago 💬 1

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

ChipTuner 1y ago 💬 1

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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)