nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3xamnwvaz7tmjv4kxz7tpvfkx2tn0wfnszymhwden5te0dehhxarj9cmrswpwdaexwnanw2j The new UI of the app list page looks nice. How is the recommendation implemented?

This bug very amusing. So the top right corner has this OS level notification from Blowater. But blowater can't render any notes except kind 4. So everytime I get an notification from Blowater, I go to Coracle to see the content kind-1 or 30023

Yes! This is exactly the local-first vision. The database can synchronize with other databases and application always read/write from local.

When Damus becomes a billion dollar app, you can start your own hardware company. Let's have Nostr Native Phone.

nostr:nprofile1qqspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcpp4mhxue69uhkummn9ekx7mqpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcxuj6p8 If this web client is SSR, when it makes a lot of sense. But it doesn't make sense for pure client driven SPAs or native apps. Effectively it becomes a different relay interface. So why not extend the query interface of relays?

Looks like we all have the same problem. It's very good that we are exploring solutions independently. Creative solutions will emerge.

That could be a benefit if the client chooses to keep GBs of events in-memory. Blowater actually plans to "never" delete locally.

Many web clients still don't treat on-device storage the main storage and query from relays everytime.

I believe local-first approach is the only way to have decentralization product-wise and to have fast client tech-wise. Therefore, I like nostrdb's motivation a lot.

But what will be nostrdb's query interface? Function calls? Query languages? Can it answer questions such as what's all my notes which have been replied within 2 hours of creation? I would love to see a nostr "database" that provides graph algorithm queries.

I am exploring Tauri, it's like a better Electron. The native process is Rust instead of NodeJS. Maybe we can have 80% of the features in Browser and the user can choose to download a native app for the rest 20%. But this approach basically says goodbye to PWA mobile.

Mobile is just too different. An attempt to cross-platform mobile is very hard.

Their capabilities are pretty much the same, just running in another V8 isolate (Chrome)

At least in Blowater, my current solution is to treat IndexedDB as a huge string store. I don't query from it at all. I just load all events to memory on init and do manual map/filter/reduce on a huge event array. The performance is 100X better than querying from IndexedDB, even for 100K+ events.

Good idea

IndexedDB is slow as hell. Chrome implemented IndexedDB on top of LevelDB and Firefox on top of SQLite. Almost all fast-enough web clients cache events in JS memory instead of query from IndexedDB on every read.

This is also why I intentionally do not implement storage layer for nostr.ts.

Browser is not designed for local-first, client driven applications.

If you implement NostrDB on top of IndexedDB, you effectively implemented it on top of SQLite/LevelDB which is exactly what you planned to avoid at the first place.

I question my ability to write software every weekend. It's always I feel great on Monday and feel extremely stupid on Sunday

Can I have a heisenberg uncertainty with #Bitcoin?

Then you have a dumb governor. No offense.

I would like it to be encrypted instead of public or providing 2 options.

WHere is this beautiful place?

Despite being considered as the best desktop Nostr DM client, today I realized the DM part of the code is most horrible in https://blowater.app because of the encryption/decryption handling. For the same UI feature, it's much easier to add to kind 1 than to kind 4. Kind 30078 is also difficult because all of Blowater's 30078 are encrypted as well.

Is this the Nostr browser?

ji