I had wondered why I'm frequently redownloading everything every time I open the app. That can't be good for the relays. It's also redownloading everyone's PFP from the image hosts and the entire list of my followers starts at 0 every time I look at it.

Reply to this note

Please Login to reply.

Discussion

Is there a reason why this data isn't persisted? Maybe because it would write to flash too often?

Just dev time. I wasn't able to code it yet. I don't think it will reduce data downloaded by that much, though. The app has to ask if things have changed and the only available API answer is a list of the most recent events. The app would already have them, but they would have to be downloaded regardless.

Thanks for explaining! Might the set reconciliation protocol like in strfry eventually be helpful in this regard to reduce redownload data consumption?

Yep, something like a bloom filter where the app could send a compressed list of events it already has would be great. Upload payload must be small, though.

The trouble with bloom filters is it can easily become a DoS vector to the server. I suppose in the case of Nostr that risk could be mitigated with the payload being signed (where you aren't allowed to use bloom for read-only mode).

Another thought is some of the data is less important to redownload. Relay badges and people's profile pictures don't change often and it isn't a big deal if you display an old one for a while.

Those downloads are more sizeable than relay text so it might make a big difference to implement persistence of those in cache first?

Profile pics are already automatically further resized and cached by Coil to fit specific elements in the screen. That's where most of the disk cache goes to.