It probably also depends on the number of people someone is following. If you aren't following many people (single to double digits), you'll see everything they post. Once you start getting into hundreds and thousands of people you are following then you'll only see those that are loudest / posting all the time and those that only post occasionally will get lost in the noise.
only got to watch for a few minutes earlier, but saw you were working on a timeline element. any idea why if i look at the Articles in someones Profile, that they are all out of order ?
Maybe its just a UI thing, but is there a way to "undo" a (or I guess negate an existing) reaction in #noStrudel or #primal ? Went to go view a reaction but ending up reacting to it unintentionally...then tried to undo it by clicking on the reaction, but just reacted to it twice instead 🤣
I'm still new to Nostr and trying to wrap my head around all the different NIPs so excuse me if I get something wrong here. Seems like we are missing out on a big opportunity to combine the different content types together though? The current NIPs (understandably) are trying to replicate what we have today (Twitter, Instagram, Youtube, etc.) instead of envisioning what the future could look like.
With the way it stands today we've replicated the artificial silos of information. Text threads go over here, pictures over here (with comments), videos over here (with comments), blog posts over there (with comments). They were that way before because of the Platforms that existed, but do they need to be that way in the future?
What if someone creates a Blog Post that gets people talking? Some people may want to reply to it by commenting, but maybe others want to make a video response to it. Maybe others want to make their own blog posts, or make their own Podcasts? These things are happening today but their connections are not being inherently captured in the data because of the way it's structured (from what I can tell).
I would love to see a world where we can have "Multimodal Threads", where we pull together all the different ways people communicate into the conversation instead of having separate channels for everything. Where I can go to a Blog Post (or Video, or PodCast, etc.) and see replies sent in through different mediums. Maybe that's just me though...
# 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
Can you talk about/describe Replacing Relay URLs a little more? It seems like a pretty interesting idea. Do you see using a DHT then?
I love that I'm able to see the raw events in the UI. I'm still working my way through all the NIPs and its really helpful to see what all is being sent. On that note, I have a question about NIP-10 and #noStrudel (sorry if its a silly question). I see in your reply above that it's a reply to the root of a thread, but there are two "e" tags. Is there a reason/benefit to using two (reply & root) in that case (since NIP-10 says a reply to root should just have a root "e" tag)? Thanks!
nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr , I have to say I've been loving #noStrudel so far. For looking at posts of people I'm following, I've had a much better experience than on other platforms. On primal.net I'm lucky if I can even get the "Latest Notes By Your Follows" to even show up (and I'm only following a couple people)...!