#[0] why is nostr doc stating p2p does not work? Maybe a silly question. I see only upsides: with your own relay and optional replicas you never have to worry about losing access to your own messages. Plus you don' have to ingest followers messages. Plus you can start nano and push your relay(s) on increasingly capable servers. What I am missing? Scalability?

Reply to this note

Please Login to reply.

Discussion

Well that’s a complicated question 😅

I would describe nostr as a pseudo p2p network. It’s not real p2p because everyone isn’t connected to everyone, but rather in a hub-and-spoke network.

Running your own relay gives you more freedom and security.

In a hub and spoke arrangement nostr is designed as an airport. But if makes sense for airlines to share runways and for passengers to pool together departure location, I don’t see the same benefits here.

Operating on your own messages requires the same amount of connections if relays are reserved or not. Looking up on followed’s is not instead because reserved relays introduce a latency shared don’t expose. Latency made visible in the “looking up message” boxes that litter the federated feed channel on iris web. But with parallel connections (and http3) this delay should not escalate much. Also promote reserved relays progressive scaling. Relays pooling would also restrict lookups mostly to LANs. I envision automatic orchestration already.

Where’s the bottleneck nostr is trying to manage here? Someone modeled extreme cases already I am sure.

I believe the bottleneck is mainly the complexity users have to manage. On nostr you can get up and running very fast, while on alternatives it’s more complex.

We are still early though, so it’s hard to say how the network will evolve. I do think we’ll see more centralized services, but the users have more freedom to select their operators.

Just like email and gmail