cows are amazing biological machines.
The protein upcycling capabilities on the latest version for converting low quality plant proteins into high quality ones 👌
incredible stuff when you think about it.
Go to your profile and update your lightning address. Some clients may cache your old address so theres not much you can do in those cases except wait for awhile.
nostr will have the best tech and the most devs, people won’t be able to ignore that for long. other clients on other protocols will run into heavy handed moderation issues due to centralization of power, government pressure, and lack of user keys. This is the main risk I see for mastodon, bluesky and big tech, regardless of current user numbers.
As long as people care about freedom and building a sovereign presence in cyberspace, nostr is inevitable.
It’s possible most people don’t actually care about these things, but at least we’ll have the best solution for people who do. Those people are the coolest to hang out with anyways.
ah right… I am blessed (cursed?) with the knowledge about how all this works at every layer of the stack, and think deeply about how implementations of these protocols lead to different outcomes. I see nostr as the outcome that leads to the most freedom for individuals, perhaps thats why its clearer to me as to why this is the proper solution. education is the key i guess.
notedeck should reach theoretical optimal performance. Loading the database is just a single mmap calI. There is no heavy serialization needed. The initial queries just scans the local index for note ids (u64). Once we have those, its a quick btree lookup into virtual memory for a flatbuffer-like binary note pointer. Effectively zero copy queries for every note in the database.
Will be very surprised if someone can make a faster client than this. This will be faster than any sqlite or postgres client. Notice the cold start time. It’s instant to load, even for databases that are terabytes in size.
On top of this, we skip the entire web stack for rendering and render directly to the gpu on every platform, we can render 1000s of frames per second with hundreds of nostrdb queries per frame.
People may think I’m exaggerating for marketing or promotion but i’m really not. Any web client will never be faster than notedeck, because the web does not have access to virtual memory capabilities. This is a the reason I am calling it a next-gen client.
Someone once said damus was slow and I took that personally. nostr:note10hgpd27h3kuq7ufs90m23kdvmj0p3f4m20t8cpqdew6zk6r68n4qan5alu
It becomes an issue when you want to do more ambitious things. Current clients are memory constrained. Not needing to worry about memory and letting the OS page things in/out for any size db when doing algo queries and other types of local processing is quite nice.
Local first also enables lots of use cases, like using the app offline and having everything resync with negentropy when you’re back online. Also fast local fulltext search for privacy, p2p and local network syncing…
The local algo thing is cool because the wasm algo api can have full query capability assuming the presence of a local db as an api, so local algos will be much faster. Coding everything to an in-process local relay enables lots more use cases and increases reliability in the presence of rogue relays in the outbox model… i need to write this up 😅
its an optimized, memory aligned binary format, with full local query capability, virtual memory mapped so you can page in gigabytes to terabytes of notes, with no synchronization or serialization required in/out, with an early exit json parser on duplicate notes for max performance. but yeah… “simple cache”
This is a culmination of over a year of work, creating a custom nostrdb database written from scratch in C, and a taking everything i learned from damus ios to build the highest performance nostr client possible.
This is a next-gen nostr client. notedeck will be our main tech platform going forward, free from apple restrictions, and will scale to any use case we throw at it. Can’t wait to share all the cool stuff we have planned for this. nostr:note1dwl50kcq6ejej5pnvm63zgm4qgqa4ktsr0xtcnksfq6uch2l0l2qyzd6tm
its an optimized, memory aligned binary format, with full local query capability, virtual memory mapped so you can page in gigabytes to terabytes of notes, with no synchronization or serialization required in/out, with an early exit json parser on duplicate notes for max performance. but yeah… “simple cache”
Seems relatively straightforward. Just need to make sure the number of relays queried doesn’t get too big. Will need to prune relays if other relays cover all pubkeys in each relays timeline query 🤔
Is this how your implementations work @PABLOF7z@hodlbod@Mike Dilger ? https://i.nostr.build/auNu78hGBpwKIXKi.jpg
For example, in this example, we wouldn’t bother querying R4 since it is covered by R3, and we wouldn’t bother querying R2 since it’s covered by R1? So you would only need 2 relay queries here
I’m tired of them talking about aliens. So they are underwater now. just fucking show us then. Let’s see some high res pictures, videos, and radar data.
i personally believe its a bunch of ufo wackos that got into government positions and actually believe what they are saying, but are not good at skepticism.
Oddbean new post about login | logout
Notes by jb55 | export