Read relays are used to seek events about you. Other users will publish the events they want you to see to your read relays.
Write relays are used to publish your events. Other users will seek your events from your write relays.
The number of read and write servers should ideally be kept between 2 and 4.
More details about mailbox model: https://mikedilger.com/gossip-model/
Sorry, I meant the relay sets stuff. In particular, the "pull from relays" "push to relays".
But I figured it was: you can create relay lists in the client, and push these list settings out to relays (so that you can load them elsewhere or in other instances of jumble on other devices).
Not sure _which_ relays you are pushing (and pulling) those sets to. I guess whichever read relays you have configured already?
And then I guess you can use these relay sets when youre browsing jumble.
Haha okay so I supoose I already understand it and I didnt need to ask. :)
Missing piece for me is using jumble on mobile, but I think that problem is unique to my mobile is not being friendly to backgrounded PWAs maintaining their websocket to receive Amber signing events
It seems the text on these two buttons is quite confusing, haha. Actually, it's a simple cross-device sync feature for relay sets. "Pull from relays" and "Push to relays" use the relays you've set as write relays.
Yup! That's kinda what I figured
I've received feedback from several users mentioning that they're confused about the wording on these two buttons. Do you have any suggestions?
Hm..
Well one extreme option is just to get rid of them. When a user navigates to this page, check for changes and merge in any remote changes. When a user makes new changes to the local settings (new sets, updating existing ones, etc) just push those changes out on completion. And you could include a "force refresh" button with a tooltip that explains (something like, "will check your read/write relays [link to these settings] for relay sets you've previously used").
I'm not sure if that would make things _more_ confusing though. And then you'd have to do some local caching stuff for that if you aren't already.
It really comes down to whether you want to jumble's relay set interface to be one-to-one with a user's remote relay sets, or if you want them to be able to have local-to-this-device sets that they don't publish.
Either way, it should be noted somewhere how that works, maybe before signup, especially if you go with "any changes you make here are automatically persisted out to your relays" as someone could end up overwriting remote data without realizing it
The reason why automatic saving to relays isn't implemented is that some people don't want to make their relay sets public. This can be solved through encryption, but it requires frequent encryption/decryption requests.
However, the current implementation seems to have caused more confusion. I'll think of a better way to improve this.
Update on the mobile thing: it works fine for me with nsec bunker via Amber in my mobile browser NOT as a PWA. Cool! I'll experiment with PWAs again later.
