WuMing on Nostr: In a hub and spoke arrangement nostr is designed as an airport. But if makes sense ...
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.
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.