Nostr Web Client

I've recently changed the penalty box timeouts depending on circumstance. "Forbidden" for example won't be retried for 86400 seconds. It still probably needs more refinement.

If mobile phones simply can't be full-fledged clients under the gossip model (and I don't know to what extent that is actually true), then there is a case for a client proxy that they offload to. Now we can talk about the architecture of such a thing and how it differs from an aggregating relay, and what exactly Relayable is... I think a client proxy should operate under the gossip model finding the relays to search on behalf of the actual clients, and the clients can do their simple configuration connecting to 3 or 4 of these proxy clients not needing to use the gossip model themselves.

I'm less interested in this model for the same reason I'm not terribly interested in custodial bitcoin... you can do it, but don't complain to me if you lose all your money or when you configure just one client proxy and it happens to be down.

Mike Dilger ☑️ 2y ago

> If mobile phones simply can't be full-fledged clients under the gossip model (and I don't know to what extent that is actually true)

The thought occured to me that maybe this idea that mobile phones can't handle lots of network connections came about due to firebase: google routes all apps through one channel to save battery. But this isn't because multiple connections devastate the battery... it is because multiple connections waking the phone up all the damn time when you are not using the phone devastates the battery. A client that makes many connections while you are using it doesn't seem to me that it would be a significant drain on the battery. The number of words processed is the same whether they all flow through one network connection or they flow through 100 network connections each 100th of the amount (neglecting the overhead which is probably quite significant, but probably a factor of less than 2). I could be completely wrong, but that thought just occured to me.

Reply to this note

Please Login to reply.

Discussion

nobody 2y ago

The problem is that TX/RX is costly (energy wise), and they receive the same events N times, where N is the number of relays they share with the poster. afaik there really isn't a way in the protocol to deduplicate server-side in any meaningful way.

Mike Dilger ☑️ 2y ago

The way I do it they receive the same event 2 times. My client only subscribes to person X's events on 2 of their relays (configurable, but that is the default).

But yes traffic TX/RX is costly. My desktop client has read 26 megabytes since I started it a few hours ago. Other clients I've heard of download gigabytes during that same amount of time. I think there is a lot of tuning and optimization that can be done even in my client, but also in the protocol (things like COUNT).

nobody 2y ago

I think I’ll capture some data on that. You’ve made me curious.

PABLOF7z 2y ago

What approach are you going to take to capture this data?