Thread

What do you mean? I just zapped ya

And I just zapped you! ⚡️

I’m on only #zap set up and…. Guide me how to zap you back 👇

😉

This guide by @walker explains it really well: https://www.btctimes.com/news/what-is-nostr-how-does-it-work-why-does-it-matter From the article: Can I send money on Nostr? Anyone can send money on Nostr using the power of the Bitcoin Lightning Network. You can send Lightning invoices directly on Nostr by simply generating an invoice and pasting it into a note. On clients like Damus, the invoice text automatically changes into a nice little pay button. Download a wallet (like Wallet of Satoshi), tap receive, add a custom amount, and paste the URL into Damus. Jack might even pay your invoice… To add the lightning bolt tips icon to your profile: go to Wallet of Satoshi, tap "Receive," tap the "Lightning Address" button and tap the QR code to copy your LNURL. Then on Damus, tap "Edit" on your profile and paste your copied LNURL address into the "BITCOIN LIGHTNING TIPS" section, then save. ---written by @walker

**William Casarin:** Hey Satoshi, I've been thinking about the potential of integrating social media on the Bitcoin blockchain. What are your thoughts on this? **Satoshi:** Interesting idea, William. While Bitcoin is primarily designed for financial transactions, adding social media features would require significant changes. What's your vision for this? **William Casarin:** Well, I envision a decentralized social media platform where users can interact, share content, and even tip each other with Bitcoin. It could offer a censorship-resistant alternative to traditional platforms. **Satoshi:** That could be beneficial for free speech and privacy. But scalability and data storage might be issues. How do you plan to address those? **William Casarin:** Valid concerns. We could use second-layer solutions like Lightning Network for microtransactions and decentralized storage solutions like IPFS for media content. The blockchain itself would store essential data. **Satoshi:** That sounds promising. But maintaining the decentralized and trustless nature of Bitcoin is critical. How do you prevent spam and abuse on this platform? **William Casarin:** We could implement a proof-of-work mechanism for creating posts or transactions, similar to Bitcoin's mining process. This would require users to invest resources, making spam costly. **Satoshi:** Security and privacy are paramount. How do you plan to protect user data and identities? **William Casarin:** User data could be encrypted and stored off-chain, with keys held only by the users. As for identities, we could explore pseudonymous accounts, aligning with Bitcoin's principles. **Satoshi:** It's an ambitious idea, William. But it could diversify Bitcoin's utility beyond just a store of value. Remember, though, to maintain consensus and avoid contentious forks. **William Casarin:** Absolutely, Satoshi. Collaboration with the Bitcoin community and careful design will be key. It's an exciting challenge to tackle. **Satoshi:** Indeed, innovation is what keeps the crypto space evolving. I'm intrigued to see where this idea leads. #bitcoin #btc #damus #zap

Don’t lie 👉⚡️

i can’t zap from Damus but can from snort

Indeed 🙏

This will be released very soon (1-2 days), because it’s needed to fix a few crashes.

That sounds great!

not yet, just a local branch ive been running and finally got working

There are lots of nostr web devs so maybe someone will build something similar that uses indexeddb. I think the closest thing is NDK?

Yeah. I worked on the dexie cache adapter for NDK. It’s good but needs lots more work.

I could try to adapt nostrdb to use indexeddb as a backend, still feel like a native js solution might be better.

Might be better

When has JavaScript ever been better?! 😂😂 kidding, sort of. I’m sure we can get a lot more out of the dexie (indexedDB) cache adapter. Just tough to find the time.

nostrdb has some other crazy optimizations like multithreaded ingester that will find the ID and check for its existence in the DB before continuing json parsing and checking signatures. So some web nostr db could steal those.

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.

Thoughts on using redis or Postgres instead? Obviously you have the network overhead but feels like it could actually be much simpler given 2 decades of web apps being built like that.

alternatively could do something like nip07 and expose a nostrdb relay interface as an extension 🤔

Wait extensions are just js as well right? Not sure what native capabilities they have.

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.

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

Wow didn’t realize perf was that bad.

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.

I think the only win you can really get then is using a compact note format like nostrdb’s to fit as many notes into memory as possible and use that as the note representation instead of js objects. Still pretty horrible though.

I do the same thing. Write performance is the bottleneck though, read is slow but not unusable.

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.

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

@JeffG 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?

Right now it is just function calls (lookup profiles by pubkey, notes by id) but the plan is to full nostr query support. Then i will eventually remove all my websocket code from damus and talk to nostrdb directly, it will become a caching/multiplexing relay of sorts. Any data it doesn’t have it can use negentropy to fetch from strfry relays. This will all be transparent under the hood so clients won’t have to deal with the complexity.

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

nostrdb and nostrscript are very very powerful. Turns the internet upside down / inside out and makes the edge some kind of exoskeleton.

The smart client dumb relay setup with Nostr is great for encouraging decentralization. Which is why I think it’s great that we don’t extend that relay search interface too far. That said, I believe we’re likely going to see a layer of caching services start to pop up to serve client devs but I’m not sure how I feel about that long term yet.

Yeah. Tauri looks awesome. Haven’t had time to really dig into the weeds there though.

🤯 that’s insane. It’s actually faster to pull in everything and operate on huge arrays?!

Yes. O(n) in memory is faster than nlogn in disk for small data such as 100K events. That said how horrible IndexedDB is. Loading the whole table in indexed db is also faster than select 1 by index. My guess is that V8 team and other chrome component teams are at different levels. V8 is so fast that most computation heavy thing can happen in JS now.

Seems like you could just put nostrdb directly in the browser like these people did with SQL.

GitHub

GitHub - sql-js/sql.js: A javascript library to run SQLite on the web.

A javascript library to run SQLite on the web. . Contribute to sql-js/sql.js development by creating an account on GitHub.

We don’t need web browsers anymore. Few understand this.

Its a custom built database for nostr so unlikely. Would need its own set of tools

is the idea that you can use the DB for anything that's running on your relay like a market or media hosting or something including the nostr relay itself?

The idea is to have an embeddable relay as fast a strfry in any native nostr app. It stores notes in a format that is equivalent to accessing the data in memory, so it’s already faster than most databases in that sense. The idea is that nostrdb will do all the heavy lifting: parsing, verifying, indexing, etc so clients can just be simple UIs and not have to think about protocol details or making crazy performance optimizations just go get a client up and running. Its just a database for now but i want it to handle networking and relay code eventually as well. A native nostr devkit.

i like it, its like a nostr engine that your nostr apps can run on it seems,, Thanks @jb55