Oddbean new post about login | logout nostr:nevent1qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcprfmhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtmpd3kqz8nhwden5te0wfjkccte9ehx7um5wghxyctwvshhgun4wd6x2eqprdmhxue69uhhyetvv9ujuun0da68xetjwejhyuewv46j7qg5waehxw309aex2mrp09skymr99ehhyee0qqsyh7y4gy0d58ne264cz0ra28z9wgn9sgm4wv8uattv2eykdhuw0yslva5l7
Isn't it better to run a native desktop client at that point? @Magister Michael Dilger M.Sc. is Gossip built with a pocket internal relay store?
Why? Just because it's "native"? You are of course free to use what you think is best for you but I don't think this approach is any worse. It's just one kind of tech used to create client. What is the clear benefit that you feel like you gain for not using webview for UI?
It's much faster?
I don't know if it is even that much faster when most of the delay is loading content anyway. I think that webview is well optimized for showing this kind of content and strfry performs really well. Tere aren't that many native Linux clients either. For me Gossip was pretty unstable and crashed couple of times when I tried it. Don't get me wrong, noStrudel is no perfect either but haven't had it crashed like that.
I haven't used noStruedel. Gossip avoids the web stack to avoid attack surface. That may matter to you, or it might not. And there are lots of other factors to consider when choosing a client.
Webview is more vulnerable for side-scripting attacks and such than other techniques for sure and I'm not against optimizing for security. I'm not really against having a native client either, quite the opposite. I just don't think there are that many native linux clients out there and this approach isn't too bad. It does give me well performing local client.
I did something like this, but only as a test. Is better than PWA. Only one issue, can't use webextensions (nip07), but if it works ... . + Appimage
It shouldn't be that hard to have window.nostr added. I first tought of using existing extension but many of them just save private key in plain text. I'm actually looking into that right now and trying to make friends with Rust, D-Bus and Secret Service but we'll have to see how well that goes, no promises. I should definately be able to put something together. Allready have window.nostr object added from my node module and JS talking to Rust backend through Tauri calls. Also already managed to make some test saves to KWallet from Rust so basicly I should have most of the pieces already. Still have to put them togheter in a user friendly way. Maybe add some backup alternative saving place for those who don't have KWallet, Gnome-Keyring or KeePass which all should work with Secret Service. Anyway, I'm sure there still are many problems to solve along the way so we'll see.
Gossip does not use pocket. I built things in this order: nostr-types, gossip, chorus, pocket. I backported pocket into chorus so now chorus uses pocket. But pocket only has a very simple interface, just enough for a relay, not nearly good enough for a client to use. That may change but I'm not working on such. Gossip uses it's own LMDB storage which is a tad less efficient but much more fully fleshed out for client usage. Also Gossip isn't interacting with it's local database in the same manner it would with a relay. I know that some other clients create a local relay style cache, but that is not what we are doing. We have a custom internal API that is nothing like querying a remote relay.
Do you think the custom internal API makes more sense than the relay interface and people should stop talking about embedding relays in clients?
I think a client has more things to store than just events that came from relays. So it makes sense to store those in something that doesn't reflect a relay's storage system. But when it comes to fetching events from local storage, I think having a similar interface to fetching events from a relay makes sense. Pocket-db provides sucn an interface where you pass in a Filter (like you would in a REQ) and it returns the matching events. At some point gossip's internal database changed its interface over to the same kind of thing. But we also extract data out of events and store it into faster access structures. If we had to parse events every time we wanted to know who you follow, or what somebody's metadata says, etc, that would be too costly. You can think of this local storage like a cache, but the interface looks like a custom set of tables.