nostr-sdk is probably better setup to do that. nostrdb is more for building high-performance apps on top of. I haven't focused too much on dev docs.
Let's say I want to write a little rust CLI that just stores like "notes to self" as nostr notes with some random kind, and saves them to my relays.
What crates should I use? enostr? Fine with forking it if some small things need changing? Or https://github.com/rust-nostr/nostr/tree/master/crates/nostr-sdk with `ndb` feature (cc nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq3qamnwvaz7tmwdaehgu3wd4hk6tcqyp5dsyt9jxqspd76g07z3a73lsf923rxuyg43p4eu7anymm9a3p8ycr9xgs )?
Want to make a nostr thing this week and would like to try out nostrdb while I'm at it ...
Discussion
Cool -- my goal would eventually be to build "high performance apps" but I need to start somewhere ...
if you want raw performance using nostrdb-rs directly is best, since when nostr-sdk wraps it, it kills the perf as it is no longer zero-copy.
the enostr stuff is old and crufty. i was working on a networking side of nostrdb at one point but it fell by the wayside for the time being
Very helpful. Thanks for explaining!
the main point of enostr/nostrdb_net is to avoid parsing json twice, enostr basically just barely and badly parses some high level tokens (OK, EOSE, AUTH, etc, subscription ids, etc) without parsing the json. then it passes the websocket &str directly to nostrdb for processing.
Also extremely helpful! Makes a ton of sense.
nostr:nprofile1qqsprwdgjszdhucrfelp3p46nhzvd5mk7gu6zxp8r0fwc4n63zv9pnsppemhxue69uhkummn9ekx7mp0rqtknc, yeah, you can use nostrdb APIs directly for the zero-copy queries and nostr-sdk for the networking stuff.
You can eventually clone the nostrdb instance and pass it to nostr-sdk just to automatically save the events received from the relays into nostrdb.