its Client-Only vs Back-ended battle
NOSTR did came along successful way along the social side
but its much more subtle problem on the technical side of things
we will get their when apps are lighter and faster
we will get their when NoorNote-pc finds a way to signal Amythest-android to not show same notification twice
such things cant just be another nostr nip, it needs to be a backed in software foundations
quotingi wrote this then polished in claude
nevent1q…qre2
The rationale for such fancy structures:
When your app serves any dataset, RAM must hold it entirely — not just what's on screen, but everything. The moment you open your Nostr client, memory is already allocated for your whole DM history, every conversation thread, every timeline — even if you haven't navigated there yet. See, that cost compounds across every feature you add: group chats, multiple feeds, relay subscriptions — it all stacks up.
How traditional development handles this:
In a frontend-backend model, data lives on servers. The app's only job is to fetch what's needed right now, paint the screen, then throw it all away. This is why mainstream web dev gravitates toward immutable, stateless patterns — not because immutability is efficient (in other fields it's considered a joke, a memory hog), but because the server absorbs the real cost. The client stays deliberately thin.
But we don't have a server.
also created this inaccurate infograph in grok
the point is:
-traditional model starts from RAM and optimizes downward
-client-only mode Must start from disk up
