Nostr Web Client

presenting: i2p

here are my thoughts from what I have read from your posts:

nostr is inherently an unreliable transmission medium, as notes may be rejected, reordered, delayed, or not delivered for a multitude of reasons and relays will be built with this assumption

the current design doesn’t implement any flow control or retransmission I believe, so this can be a problem

implementing another TCP like layer on top of nostr events is vulnerable to a meltdown, where the lower layer having losses causes delays in the upper layer causing retransmissions and more load on the lower layer

there is also the fact that nostr and IP have different service quality goals

on nostr latency can be in the seconds, caching will exist and QoS can be applied for different events

IP has some loss and reordering tolerance, but it is expected that paths have mostly constant latency and throughput, and that path switches happen rarely

Reply to this note

Please Login to reply.

Discussion

semisol 1y ago

there is also the problem of encryption, the naive approach puts too much load on the main key that may be stored on a TPM or similar for security

session keys should be established, but at that point you are reinventing TLS and may as well publish unencrypted packets

another problem is overhead: from base64 encoding binary data to having things like WS and 2 reliable transmission stacks

and in the end relays are just a rendezvous point for client/server, and there are already solutions like TURN

for privacy benefits you can use the already actively developed project I2P, and there is no advantage to NWS

876b56c9... 1y ago

Yea i2p is cool but it need a rust version to make it better and safe