Oddbean

I have an #asknostr about Nostr. In a client, we select which relays to connect to. Is that list of relays that we have chosen to connect to stored on the client side, or does that list of relays become an event that gets sent to relays as well? I assumed the latter, that my relay list is published to relays, because if I spin up my keys in a new client it seems to have the same relay connections. But then if I change the relays there in that new client, it doesn’t seem to change the relays on my other prior clients. I assume this is because of the basic Nostr fact that there is no global state and thus relays can have different information about the same user/keypair. Or is some of the relay network connection list stored locally on the client as well? I guess a broader question is, what types of Nostr information are persistently stored locally on a client?

The relay list is saved as an event on your relays. There are actually a few different kinds of events for storing different sets of relays. And yea, the differences are usually because one relay has an out of date event or a client handles it badly and overwrites a previous event.

It depends on the client. Some broadcast your relay list. Some have a locally stored set of relays that doesn’t get broadcast out. Some use the outbox model. Some use caching services along with relays. Some clients will overwrite your relay list when you login to them if you’re not careful, although I don’t think that happens as much any more.

It depends on the client, maybe they are caching the relay list. There are many sources for relays.. Hard coded (app) relays, nip-05 relays, extension relays, relays embedded in notes, nprofiles, and the "actual" kind 10002 list as defined in NIP-65 https://github.com/nostr-protocol/nips/blob/master/65.md TLDR; it's messy, implementations differ, and making it performant is a challenge

I can tell you that changing a relay in Amethyst and punching "Save" absolutely publishes an event. There seems to be very little consistency between clients, though, so it is easy to get it boogered up. In my case, one of those relays is Citrine on the phone, and I export its database as a backup. What I'm learning is that relays and lists are messy. Check listr.lol when you get a chance.

Just an afterthought on that...it seems that anything network-related, even if stored in the client, is subject to change if another client publishes an event of that kind. Things like your default zap amounts or display themes aren't Nostr events and are always saved in the client. Backing up the state of a relay may be the only way to come back from a client publishing weird changes to your relays or lists.

It has always worked for me to use one or two clients on both mobile and the web and so I don’t have much clutter. I learned this when sometimes trying, several clients broke list of followeds, list of silences, list of relays. Now the experience is much better.

Clients seem to be converging on a combination of respecting & allowing you to manage your inbox/outbox relays (global state) while also allowing you to configure relays specific to the client (and that configuration may be stored locally or broadcast as a client-specific relay list) If you see inbox or outbox in a client relay config that's probably global state

there is relay lists, often called "app relays" and then there are nip-65 "inbox" and "outbox", both are published to relays and other users can see them in order to know where to send messages such as DMs that you will find them all of these things are on the network, not stored in the client

current state is a 'mixture of everything' probably. i think clients should have some 'bootstrap' relays but after the user becomes advanced they may let user decide and start saving that info on the relays. not many people care about relays. and some users really care about relays to the point of helping decentralize the network by using small relays. i think it is a good idea to write as many relays as possible. and read from some relays which have less spam and as much as your mobile data allows.

We can store anything we want really. If it’s private we can even store it by encrypting the data to yourself. So yes, pretty much everything is stored. Some apps even store user application settings so that they are synced between machines. For example in the upcoming Damus notedeck, we will be storing deck configurations (optionally public but default encrypted).

But what if a client has a problem and accidentally deletes or corrupts this information leading to its subsequent deletion/corruption on relays. It would be nice I think to have a prior export of npubs that can be easily imported to restore. Would also be useful for moving to a new identity. Kind of like a podcast app that allows export/import of RSS feeds. Thank you, Pablo, for all you do! 🙏

It varies across clients, but most clients will read/write the relay list they use. As with most things though, there are two standards; an old-hacky stringified-JSON in the follow list, and the more modern approach of using event kind 10002 to store read and write relays. This latter is (one of the) key pieces of the puzzle that we call “outbox model” (formerly gossip) - which is how a client knows where to read/write for specific pubkeys and is one of the key aspects that makes nostr credibly censorship resistant. We also have a NIP (87) for client-specific configurations which can serve as the basis to, for example, copy someone’s configuration of a particular client.