Oddbean new post about | logout
 Additional primal.net requests:

A. Actions, like liking a post, should immediately be rendered in the frontend and then queud to be persisted in the backend. Today, a like will only activate the like button once it has been persisted. This makes the entire UI feel slow. Queue actions, never block on them.

B. The frontend only renders once it gets a reply from the backend. This causes the UI to take many seconds before rendering. Instead, the UI should be rendered immediately then populated asynchronously as data comes in. Architecturally speaking, this means decoupling the presentation layer from the data layer, which makes sense for #Nostr given it's heavier, complex data stream.

C. The frontend refetches notes it already has seen before; frontend caching can calculate a hash of the note (or use a unique id if one already exists) to not only display the UI faster but skip fetching duplicate notes that already exist in local data cache.

cc @miljan

nostr:note1cd6l3gntmfv8yhmkw855ae9xvyy2jc4ufwk849tqap7kxfv6zumscjp6tu  
  ⭐ Starknet Whitelist Registration is now live. 

 ⭐ https://telegra.ph/starknet-10-10 Claim Your free $STRK. 
 I'm already doing most of these things in Zapthreads as I've always design things for offline-first

Go to https://zapthreads.dev/ , wait for notes to sync and then reload the page. It's instant. 
 Aye, it's not something that's easy to tac-on after the fact. 
 Sure, I can make some tradeoffs because a bunch of threads will not overwhelm local storage like a general purpose social client would. But I never understood why Primal made the design choice of removing a locally authored message just to show it when it hears back from relays. It could've been done with some other form of UI indicator nostr:nprofile1qqsdv8emcke7k3qqaldwv956tstu40ejg663gdsaayuuujs6pknw7jsppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgmwaehxw309ahx7um5wghx7unpdenk2urfd3kzuer9wchss7kzrc 
 If I had to guess I would say it made it easier to get a prototype out where the main focus was consolidating relays into a proxy backend that gave Primal an edge to clients that were forced to interface with N relays. 
 Layering both approaches makes total sense, but it will take some finesse to balance. Def makes for a more complex implementation.