What if we just want people to understand that their reasoning is flawed?
It's better to quietly try and understand what you don't know than to loudly proclaim what you are certain that you do.
Rationalism is the universal alignment
# What Can We Get by Breaking NOSTR?
"What if we just started over? What if we took everything we have learned while building nostr and did it all again, but did it right this time?"
That is a question I've heard quite a number of times, and it is a question I have pondered quite a lot myself.
My conclusion (so far) is that I believe that we can fix all the important things without starting over. There are different levels of breakage, starting over is the most extreme of them. In this post I will describe these levels of breakage and what each one could buy us.
## Cryptography
Your key-pair is the most fundamental part of nostr. That is your portable identity.
If the cryptography changed from secp256k1 to ed25519, all current nostr identities would not be usable.
This would be a complete start over.
Every other break listed in this post could be done as well to no additional detriment (save for reuse of some existing code) because we would be starting over.
Why would anyone suggest making such a break? What does this buy us?
- [Curve25519 is a safe curve](https://safecurves.cr.yp.to/) meaning a bunch of specific cryptography things that us mortals do not understand but we are assured that it is somehow better.
- Ed25519 is more modern, said to be faster, and has more widespread code/library support than secp256k1.
- Nostr keys could be used as TLS server certificates. [TLS 1.3](https://tools.ietf.org/html/rfc8446#section-4.4.2) using [RFC 7250 Raw Public Keys](https://tools.ietf.org/html/rfc7250) allows raw public keys as certificates. No DNS or certification authorities required, removing several points of failure. These ed25519 keys could be used in TLS, whereas secp256k1 keys cannot as no TLS algorithm utilizes them AFAIK. Since relays currently don't have assigned nostr identities but are instead referenced by a websocket URL, this doesn't buy us much, but it is interesting. This idea is explored further below (keep reading) under a lesser level of breakage.
Besides breaking everything, another downside is that people would not be able to manage nostr keys with bitcoin hardware.
I am fairly strongly against breaking things this far. I don't think it is worth it.
## Signature Scheme and Event Structure
Event structure is the next most fundamental part of nostr. Although events can be represented in many ways (clients and relays usually parse the JSON into data structures and/or database columns), the nature of the content of an event is well defined as seven particular fields. If we changed those, that would be a hard fork.
This break is quite severe. All current nostr events wouldn't work in this hard fork. We would be preserving identities, but all content would be starting over.
It would be difficult to bridge between this fork and current nostr because the bridge couldn't create the different signature required (not having anybody's private key) and current nostr wouldn't be generating the new kind of signature. Therefore any bridge would have to do identity mapping just like bridges to entirely different protocols do (e.g. mostr to mastodon).
What could we gain by breaking things this far?
- We could have a faster event hash and id verification: the current signature scheme of nostr requires lining up 5 JSON fields into a JSON array and using that as hash input. There is a performance cost to copying this data in order to hash it.
- We could introduce a subkey field, and sign events via that subkey, while preserving the pubkey as the author everybody knows and searches by. Note however that we can already get a remarkably similar thing using something like NIP-26 where the actual author is in a tag, and the pubkey field is the signing subkey.
- We could refactor the kind integer into composable bitflags (that could apply to any application) and an application kind (that specifies the application).
- Surely there are other things I haven't thought of.
I am currently against this kind of break. I don't think the benefits even come close to outweighing the cost. But if I learned about other things that we could "fix" by restructuring the events, I could possibly change my mind.
## Replacing Relay URLs
Nostr is defined by relays that are addressed by websocket URLs. If that changed, that would be a significant break. Many (maybe even most) current event kinds would need superseding.
The most reasonable change is to define relays with nostr identities, specifying their pubkey instead of their URL.
What could we gain by this?
- We could ditch reliance on DNS. Relays could publish events under their nostr identity that advertise their current IP address(es).
- We could ditch certificates because relays could generate ed25519 keypairs for themselves (or indeed just self-signed certificates which might be much more broadly supported) and publish their public ed25519 key in the same replaceable event where they advertise their current IP address(es).
This is a gigantic break. Almost all event kinds need redefining and pretty much all nostr software will need fairly major upgrades. But it also gives us a kind of Internet liberty that many of us have dreamt of our entire lives.
I am ambivalent about this idea.
## Protocol Messaging and Transport
The protocol messages of nostr are the next level of breakage. We could preserve keypair identities, all current events, and current relay URL references, but just break the protocol of how clients and relay communicate this data.
This would not necessarily break relay and client implementations at all, so long as the new protocol were opt-in.
What could we get?
- The new protocol could transmit events in binary form for increased performance (no more JSON parsing with it's typical many small memory allocations and string escaping nightmares). I think event throughput could double (wild guess).
- It could have clear expectations of who talks first, and when and how AUTH happens, avoiding a lot of current miscommunication between clients and relays.
- We could introduce bitflags for feature support so that new features could be added later and clients would not bother trying them (and getting an error or timing out) on relays that didn't signal support. This could replace much of NIP-11.
- We could then introduce something like negentropy or negative filters (but not that... probably something else solving that same problem) without it being a breaking change.
- The new protocol could just be a few websocket-binary messages enhancing the current protocol, continuing to leverage the existing websocket-text messages we currently have, meaning newer relays would still support all the older stuff.
The downsides are just that if you want this new stuff you have to build it. It makes the protocol less simple, having now multiple protocols, multiple ways of doing the same thing.
Nonetheless, this I am in favor of. I think the trade-offs are worth it. I will be pushing a draft PR for this soon.
## The path forward
I propose then the following path forward:
1. A new nostr protocol over websockets binary (draft PR to be shared soon)
2. Subkeys brought into nostr via NIP-26 (but let's use a single letter tag instead, OK?) via a big push to get all the clients to support it (the transition will be painful - most major clients will need to support this before anybody can start using it).
3. Some kind of solution to the negative-filter-negentropy need added to the new protocol as its first optional feature.
4. We seriously consider replacing Relay URLs with nostr pubkeys assigned to the relay, and then have relays publish their IP address and TLS key or certificate.
We sacrifice these:
1. Faster event hash/verification
2. Composable event bitflags
3. Safer faster more well-supported crypto curve
4. Nostr keys themselves as TLS 1.3 RawPublicKey certificates
Better keys: YES
Nostr can only ever be as good as its keys. Maybe we can orchestrate a migration path.
Dump DNS: YES
Nostr will never be censorship resistant as long as it relies on DNS. DNSSEC can temporarily bridge things, but ultimately DNS is based on an authority.
Binary protocol: NO
This adds friction to people integrating with Nostr. Performance has many solutions, but high barrier to entry has few.
Is it more likely that:
A) A fresh wound is sports-car red, gets dry and clumpy in about a minute, and smudges like lipstick
B) This isn't real blood
C) These AP credited photos from apnews.com were modified
I haven't been watching or reading much of anything about this event, but arguing the difficulty of intentionally grazing someone seems like a distraction. 
Nostr needs the ability to rotate keys. Better management can't recover from loss, and "just start over and embrace anons" is defeatist.
"Let me tell you about my blood - it's absolutely tremendous, folks. Nobody has blood that coagulates faster than mine, believe me. The doctors, they come to me and say "Sir, we've never seen anything like it." It's true!
My blood clots so fast, it's like - boom! Instant scab. While other people are still bleeding, I'm already healed. It's really quite amazing. Some might even say it's unnatural, but I assure you it's 100% me. All natural. No fake clotting here!
You know, they say the average person's blood takes 6-8 minutes to clot. Mine? We're talking seconds, maybe microseconds. It's like my blood knows it's too important to waste time flowing out of me. Smart blood, very smart.
And let me tell you, this fast-clotting blood of mine, it's a sign of incredible health. The best health. My doctor said he's never seen such perfect blood in his life. Of course, I'm not surprised. I have the best genes, and clearly, that extends to every drop of blood in my body.
So remember, when it comes to blood clotting, nobody does it better than me. It's just another example of how I'm winning - even at the cellular level!"
- an LLM
Any time I hear someone arguing specifically against TikTok, I know there's few worldly things we can honestly discuss.
How could we structure our messages in a way that facilitates discussing whether or not something is true, without allowing the discussion to devolve into the implications of the outcome?
I agree, but it's too much to pitch in an elevator. You need a smaller gem to get people interested in the bigger vision.
Don't sell the hardware, sell a killer app and let people explore
Yes. Casual Lightning use incurs too many on chain transactions.
A cashu mint can create sats without locking actual Bitcoin (Fake Wallet https://github.com/cashubtc/nutshell/blob/f32099bce7ecca54338ebc1a551883fbdb883af2/cashu/lightning/fake.py#L31). So the zaps you receive may or may not be real, i.e. convertible to Lightning sats. So you should either zap those sats onwards, or withdraw to a real wallet asap (claim from the mint).
It this thing takes on and there will be lots and lots of such (potentially fake) sats on Nostr, this will inflate Bitcoin supply and damage it's reputation when many sats turn out unclaimable.
TLDR I hate this shitcoinery.
I reserve "shitcoin" for bad faith efforts, and I think cashu is a legitimate effort to solve a hard problem. Still, it has serious flaws.
7 bits are 12.5% cheaper than 8
Of course DNS is easier: it's run by an authority. Why should nostr lean on that when it's already capable of publishing verifiable data?
Sign Things And Relay Them
Conversational: Claude paid
Coding: ChatGPT or GitHub Copilot
Local: Llama3 8B abliterated (https://huggingface.co/failspy/Meta-Llama-3-8B-Instruct-abliterated-v3-GGUF)
The abliterated variants seem more capable than the originals.