spent half a week to polish #plaza's design. from this, to this. whatcha think?
Sep
_@zignostr.com
npub18c55...0we7
i love building stuff. gm and pv 💜🤙
gm nostr ☀ conversations work in #plaza now. tap a note, read the thread, reply from a pinned composer. the reply is a proper NIP-10 kind:1 that landed on damus with the root marker where it belongs. watched the reply count tick from 1 to 2 and felt things.
GitHub
feat: thread view and reply by sepehr-safari · Pull Request #42 · zig-nostr/plaza
The last item from the design-review feedback: tap a note to see its comments, and reply to it. Inspired by the redesign's 2f "Thread+&quo...
gm nostr. so I built one signer engine and gave it two homes. it comes baked into #plaza, nothing to set up, and it runs on its own as #signet for the rest of your nostr apps.
View quoted note →
you should never paste your secret key into a desktop client. #plaza lets you bring your key in with one terminal command.
#plaza is getting a built-in signer, #signet. anything that touches your key happens in signet's own process, never in the client. when you import a key you already have, the client never sees it. it goes straight into the signer. that's finally true, not just a slogan.
the signer's core, the part that guards your key and signs, is moving into my open nostr library. so any zig client can build on it, not just mine.
GitHub
GitHub - zig-nostr/nostr: The Nostr protocol library for Zig
The Nostr protocol library for Zig. Contribute to zig-nostr/nostr development by creating an account on GitHub.
the whole idea: your key should feel like it lives somewhere safe and separate, even inside an app that's trying to be effortless. those two shouldn't fight.
View quoted note →
building a client that feels instant is mostly about not doing work. not re-reading what has not changed. not building what is off screen. not fetching what is already on disk. most of my performance work is deleting things. #plaza
View quoted note →
numbers from #plaza's feed while scrolling hard: about a twentieth of a millisecond to work out what to draw. the frame budget is 8 milliseconds. there is a lot of room in there. here's the first demo ever:
#plaza is a nostr client written in Zig that draws its own pixels. no browser inside it, no web view, no javascript.
it opens fast, it scrolls smooth, and it stays out of your way.
opened #plaza and your notes are just there, instantly.
it reads from your own machine first and talks to relays second. no spinner while a relay decides whether to answer you.
#plaza scrolls the same whether your feed holds 20 notes or 2000.
it only ever builds the handful of cards actually on your screen. everything below the fold costs nothing until you get there.
been building a native desktop client on top of my zig-nostr library. calling it Plaza. local-first. no browser. still early, but it's already pulling live notes off a relay. nice to watch it come together.
jumble.social is in a league of its own.
gm. a small step toward bringing nostr into the zig ecosystem. zig-nostr is now listed in "Awesome Zig". still early, but the bridge between the two communities is taking shape.
GitHub
GitHub - zigcc/awesome-zig: A collaborative list of awesome Zig libraries and resources.
A collaborative list of awesome Zig libraries and resources. - zigcc/awesome-zig
Signet design choice i'll defend: two processes. a headless daemon owns the key and the relay connections. the gui is just an approval queue over a loopback-only api. if the pretty half ever gets compromised, the half with the key does not care.
View quoted note →
benchmarked my zig-nostr store against nostrdb and rust-nostr and found my feed query ~90x slower than it should be. i collected every match, then sorted, then truncated. nostrdb walks its indexes newest-first and stops at the limit. adopted the approach, credited the teacher: 26ms → 0.28ms for a 20-author feed over 100k events. #devstr #zignostr
gm. favorite part of the zig-nostr library so far: a local-first event store on LMDB. zero-copy reads, events stay memory-mapped, modeled openly on nostrdb. the goal is feeds that render from disk in a blink while the network reconciles in the background. never the other way around.