Oddbean

Nostr Clients should not care about local storage. Local relays should do that (and much more) for them. Splitting responsibilities is good. It's also why Clients shouldn't host nsecs. That's the role of signer apps. We just need more of them.

Actually there is a "browser relay", Snort has it, Spring browser too. Not sure about Snort, with Spring it's a fake Websocket interface installed to global that will redirect all requests to a custom "local-relay" url to a relay running in a service worker. There's a dumb relay in sw now, which I didn't bother to make efficient yet, but it can be improved. The main limitation is browser js performance and storage size limits, I guess. But this is only for your own app. If you wanted to share this relay, that's possible too using postMessage for cross-origin communication (with the same fake websocket installed in the app to trick the libs it's using (ndk/nostr-tools) to use the local relay). Haven't tried it though, there a limitation will probably be that the relay tab must be kept open.

A local relay, a local signer, and a client… that’s a lot of apps to download to join nostr. I think a wallet and a client is memeable. 3 apps is a bit much. Building the local relay inside the client seems okay.

Nothing. They are free to do so. But will always prefer separating them out. You will have more control over the database than expencing each app to code all the controls on what to keep and what to delete over time.

Expecting every app to conform with your local relay is in itself a task too. I see what you’re saying though, it probably would be easier for each dev building a mobile client since they could abstract away the storage & retrieval of things, but making a user download 3 apps seems like a bit of a heavy lift don’t you think? I’m not 100% decided yet, just making a point. I haven’t built a mobile client. Would you want a desktop app to work this would too? 3 programs.

Yep: signer, local storage, and client for desktops too. It will become more acceptable if you reuse the same signer and storage for many clients. There is no point in duplicating databases into each Nostr app we use. And you are supposed to use lots of them, one for each specialty flow.

Was more so poking fun at the above comment. That there is too much to do to get nostr going. First time users you don't need to run your own relay, you can but totally not necessary for a beginner.

my premise is that you are absolutely infinitely more qualified than me; here's my two cents: The cool thing about using nostr is that you own the notes in the sense that you store them. I think this aspect need to be maximal emancipated from relay. This feature is revolutionary: your nostr client as ultimate reliable backup of your microblog. Owning data is a client resposibility as I see it :)

A mastodon instance can delete my years of microblog because I don't own them in that sense. The person who own the instance own his and my speech. I can own my backup files of what I post. Client side reliable not-compromisable full storage (with some technical limits or hard cap) is what I would achieve on nostr.

splitting responsibility is also adding attack surface to my storage; relays are intended to be changed, to fail, be censored and censor. In this cases you can switch relays. They need to be treath in an adversarial way in a lot of ways. So I think at the total opposito of your statement 😅💜

A self hosting relay is useful for being indipendent at sharing your content with others, it is superflous, in my opinion, at storing/backupping them as all notes originates, transitates and are stored in the clients. Keep it simple :)

but thats the way you backup everything pre-nostr. All internet services are designed to store data in the server as a reliable source. With nostr I see a natural shift to client first-class database storage. Then, a second backup could be selfhosted with relays to have data redoundancy and for all threat model/preferencies.

you are mistaken, Nostr isn't better than Mastodon because it offers unique storage solution. You can backup your Mastodon posts just as well, the difference is Mastodon server owns your identifier, so even if you upload all your posts to your own Mastodon server, you lose your identity (and thus followers). Nostr commits posts to your public key, and demands that your followers look for you using that key. of course, it doesn't answer how should your followers find you except by a coincidence of publishing and reading from the same relays. Pkarr.org offers an answer to that question, but it is not compatible with Nostr keys unfortunately

I agree, the revolution with nostr is "own your identity". But this don't exclude what I'm saying: on nostr the natural first database become the client. Imagine this: you are writing a post on mastodon. You send it but no connection; for a connection error the post is frozen in your client. This is mean that this post "never existed"; the post never reached the server where the ultimate database resides. Now see the exact situation composing a nostr note. One/some relays doesnt received the notes? It still exists in the ultimate database that is your client. A relay not having some notes is intended to be possible; could be also an intentional choice to not send a particular note to some particular relays. There could be exceptions (running out of storage on device...) but the shift I see is natural: with nostr clients are the new ultimate uncontested databases of information and this could enable a lot of cool feature. Relays could be backups of this data, multimedia-server-storage (all that isnt "notes", see blossom for example...); but assignin them responsibility on notes-data-retention is a big step in a wrong derection in my opinion. :)