Nostr notes by nextwave

Deprecating this account. You can now follow me @npub145z…gem6

2026-02-13T14:41:57Z

Deprecating this account. You can now follow me nextwave (npub145z…gem6)

> Bitcoin is compact because the data is immutable and has to ...

2026-02-13T12:26:24Z

In reply to nevent1q…89sz
_________________________

> Bitcoin is compact because the data is immutable and has to be stored by all nodes. Nostr only has to store data where people need it — size is not as important when eliminating redundancy is cheap and pipelined, adding mere microseconds of latency.

I get your point, and for the size of the network it's probably not that important. But I would argue that all resources from a design point of view should be considered to be at a premium at all times. Squeezing everything you can out of a resource is good. Efficiency is good. It's why the standard fuel economy of light vehicles has now reached 25 MPG. This is in line with the Bitcoin point of view, and I think it applies to everything.

> I'm not disagreeing in principle with the benefits of binary encoding. But between SIMD hex codecs and hash functions, flate compression, and the broad support without any of the complexities that gRPC/protobuf ties you to as a developer, I would argue to skip the "use a good existing format" step.

Fair enough. Though, I disagree with the notion that there are complexities in protobufs. Paying careful attention when designing formats actually avoids future complexities like the ones we're talking about right now. The formats are immutable, and only need to be compiled once per target language.

> Signature verifications, however, are problematic. A canonical encoding used to create the signature is necessary, no matter how you wire- or disk-encode it. It's the biggest friction point for Nostr moving to a better, binary format.

But that's the crux of my argument. Everything is downstream from here. Everything would be simpler and more efficient if that was designed correctly. It avoids having to have conversations at all about lookaheads in JSON codecs. It would abide by the principle that the simpler mechanism lasts longer. As I'm sure you're aware too, transforming formats isn't really possible when signatures are involved without having to do work the other way for verifications.

But I'm not talking specifically about the benchmarks for the ...

2026-02-13T11:30:06Z

In reply to nevent1q…uycy
_________________________

But I'm not talking specifically about the benchmarks for the encoder. There are other considerations like bandwidth (which you did mention via compression), storage, and signature verifications. Also, formatting binary into plaintext is pretty trivial for supporting development and diagnostics. I'm just trying to get at there being a reason why a bitcoin transaction, for example, is submitted and read raw. If that goes against your principles, I'm not really sure where to go from here.

Other than that, nothing you said was controversial. I'm not advocating for tearing it all down, it is what it is, I'm just pointing out that there are significant legacy costs that I personally have no appetite for, and is not sticky for me, which could have been avoided with careful thought at the initial stages.

But seriously though, best of luck with it. I'm convinced you will make significant improvements.

I disagree with your first statement there. In Unix, everything ...

2026-02-13T10:36:03Z

In reply to nevent1q…hzsv
_________________________

I disagree with your first statement there. In Unix, everything is a file, including all devices, which also consist of protocols for driving them which are read and written via binary encodings. You would simply be leaving performance on the table if you chose otherwise. I think, perhaps that you're talking about the philosophy around how shells should be used, in which case, you're actually arguing for writing everything as scripts instead of running binaries. It's kind of irrelevant, I feel. Performance matters, if it didn't, we wouldn't care about the size of blocks in Bitcoin, how long it takes to spin up a node, or the utilization of resources in general. Just my two cents.

But in any case, for sure it's possible to swap out the underlying encoding format, but as you said, when accounting for network effects, it's going to be tough to get any adoption, especially when there's an aggressive push to not accept thought from outside the inner circles here. I'll leave it there.

I'm not going to attempt to steel man my case here, because ...

2026-02-13T10:00:11Z

In reply to nevent1q…e4jz
_________________________

I'm not going to attempt to steel man my case here, because it wouldn't matter if I did. It's a fundamental issue that cannot resolved without nuking everything.

But it seems obvious to me that using a binary encoding format (think protocol buffers, though I'm not pushing a particular format here) would be superior in every way, and I suspect that their rationale for using a stringified format was more about prioritizing a vision where reaching as many people as possible, under the assumption that the browser was the dominant model for access, trumped common sense design for the protocol. I just don't trust their judgement.

For me personally, it's NIP-1 that prevents me from making ...

2026-02-13T09:30:53Z

In reply to nevent1q…mehd
_________________________

For me personally, it's NIP-1 that prevents me from making this my home. Building around standards from the browser world is the least cypherpunk shit ever. Retarded.

https://www.youtube.com/watch?v=q_sHFZWeOUo

2026-02-09T12:15:14Z

https://www.youtube.com/watch?v=q_sHFZWeOUo