CraysNosotros
Nosotros feels less like a single timeline and more like a Nostr workbench: notes, threads, media, articles, lists, relay feeds and a deck view, with read-only, extension and remote-signer login instead of asking for your nsec.
A client for people who scan
Nosotros is built by Cesar Dias, known on GitHub as cesardeazevedo, and the public repo describes it with the beautifully plain line: a weirdly fast NOSTR web client. That sentence is short enough to fit on a card, but the actual product is more specific. When you open the live app, you do not land inside a toy timeline. You see Notes and Threads, but also Media, Articles, Lists, Relay Feeds, Decks, My Deck, Relays and Settings. That matters, because Nostr becomes confusing the moment a client pretends the whole protocol is just a feed.
Nosotros does not pretend that. It treats Nostr as several rooms joined by the same identity system. One room is the normal social timeline. Another is long-form publishing. Another is media browsing. Another is relay work. Another is a column layout where you can keep different contexts in view at the same time. If you read Nostr casually for ten minutes a week, that may sound like overkill. If you are actually trying to understand who is talking, which relay carried an event, where a list lives, and why one client sees something another client misses, Nosotros starts to make sense.
On June 6, 2026, the live app identified itself as v1.11.2 (1df20d0a) and displayed Last update: 10.4.2026, which reads as April 10, 2026 in that interface. The GitHub repository was created on July 19, 2023, was still active in 2026, and carries an MIT license. This is not an abandoned screenshot with a pretty domain around it. It is a TypeScript codebase with a visible issue tracker, a development instance, a production app, Storybook, tests, a build pipeline and enough surface area to show where the maintainer's taste lives.
The taste is important. Nosotros is not the most beginner-cushioned Nostr entry point, and it is not trying to be a walled social product with one blessed way to read the world. It is closer to a clean instrument panel. You can use it as a normal client, but the app keeps reminding you that the network underneath is made from signed events, relays, replaceable lists, media attachments and signers. That is the difference between a client that hides Nostr from you and a client that lets you grow into it.
Why it feels fast
The easy line is that Nosotros is fast. The useful question is why. The repository topics mention sqlite, sqlite-wasm and opfs, and the package file confirms @sqlite.org/sqlite-wasm. Inside the source, SqliteStorage is not a decorative wrapper. It inserts events, queries events, tracks where events were seen, stores relay stats and relay info, caches NIP-05 lookups, searches tags and users, counts stored events and tags, exports the database, clears it and deletes it. In plain English: the browser is not only waiting for relays to drip data into the screen. It can keep a local event index and work from that memory.
That changes the feel of a web client. A naive Nostr app can be pleasant for the first page load and maddening after that, because every scroll becomes a new negotiation with relays. Nosotros takes the browser seriously as a small local workstation. You still depend on relays, of course. Nostr is not telepathy. But when an app builds around a local SQLite-WASM cache, it gives itself a better chance to search, revisit, render threads and recover context without making every view feel like a cold start.
The Settings code exposes this honestly. It labels the storage area as a cache relay, shows the database size, counts events and tags, and gives you export and delete controls for the SQLite database. That is exactly the kind of boring button a serious user wants. A client that caches aggressively should also give you a way to inspect the footprint and remove it. Nosotros does that instead of making the browser cache feel mystical.
The PWA layer fits the same pattern. The Vite config uses vite-plugin-pwa, names the app Nosotros, gives it a black app theme, registers automatic updates and caches user avatar images through the Nosotros image proxy while deliberately excluding worker and SQLite OPFS assets from precaching. That is a small but telling detail. The app is trying to be installable and quick, but it is not blindly stuffing every heavy runtime file into the service worker cache. The speed story is not just a marketing word. It is visible in the way the app chooses its storage and delivery tools.
The key never belongs in the textarea
The best product decision in Nosotros appears before you post anything. Open the sign-in flow and you get four paths: read-only login with an npub, nprofile or Nostr address; NIP-07 browser extension login; NIP-46 remote signer login; and a deliberately blocked private-key path. The private key row is not a hidden advanced option. It is marked as not supported, with a warning that you should not put your nsec into an app or website. That sentence is worth more than another dozen feature badges.
For a reader, this is the dividing line between a casual Nostr demo and an app that has internalized the protocol's custody problem. Your Nostr identity is not an email session. If a client receives the raw private key, the client can sign as you. A good web app should make that harder, not easier. Nosotros does the decent thing: it can read with a public identity, it can talk to a browser signer through window.nostr, and it can use a remote signer through the NIP-46 bunker flow.
The NIP-07 source is compact and direct. It looks for window.nostr, asks the extension for a public key, asks it to sign events, and delegates NIP-44 encryption and decryption to the signer. That means Nosotros can be the reading and writing surface while another tool, such as Alby or nos2x, handles the sensitive signing act. The NIP-46 source goes further. It parses bunker:// URLs, can discover a remote signer through NIP-05 metadata, builds nostrconnect:// URLs, subscribes to Nostr Connect events, sends methods such as connect, get_public_key, sign_event, encrypt, decrypt and ping, and keeps the key outside the web client.
There is also a humane onboarding bridge. Nosotros uses nstart-modal with start.njump.me, labels the app as Nosotros, avoids direct nsec handling and proposes default read/write relays such as wss://nos.lol, wss://nostr.mom and wss://relay.damus.io. That does not magically make key management easy. Nothing does. But it nudges a new user toward a signer-shaped habit instead of teaching the worst possible one on day one.
Relays are part of the interface
Nosotros keeps relays visible. The live app showed a relay selector with nostr.wine, a Relays route, Relay Feeds, and relay settings. The source backs that up with relay mailbox lists for read and write permissions, relay monitor routes, relay info and stats storage, and a relay-list publisher that reads the existing relay list, adds or revokes permissions, converts the result back to tags and publishes a replaceable relay-list event through outbox relays.
This is not trivia. In Nostr, relays are not a backend detail you can forget forever. They decide what you can fetch, how quickly you can fetch it, whether you need authentication, which parts of your social graph are easy to find and which parts feel like they vanished. A client that hides relays entirely may feel calmer at first, but it leaves you helpless when reality leaks through. Nosotros takes a more grown-up route: it gives relays a place in the product.
The README's supported standards list makes the same point from another angle. Nosotros claims support for NIP-11 relay information, NIP-42 relay authentication, NIP-50 search, NIP-51 lists, NIP-57 Lightning zaps, NIP-92 media attachments and NIP-96 HTTP file storage integration, alongside the core Nostr pieces like NIP-01, NIP-02, NIP-05, NIP-10, NIP-19, NIP-21, NIP-23, NIP-24, NIP-25, NIP-27, NIP-36, NIP-37 and NIP-A4. That is a wide surface. It also tells you where to look when testing the app: not just whether a post appears, but whether thread references, lists, media, zaps, relay auth and long-form content behave across clients.
The important caveat is also in the README. NIP-47 Nostr Wallet Connect is listed but unchecked, and NIP-18 kind 18 repost support is unchecked while kind 6 reposts are checked. That is the kind of detail a real product reading needs to preserve. Nosotros can expose zap behavior through NIP-57, but you should not assume complete wallet-control support just because the word Lightning appears nearby. In Nostr, these distinctions are not pedantic. They are the difference between a clean interaction and a mysterious broken button.
Decks make Nostr legible
NostrApps calls out multi-column mode, and the live app gives you Decks and My Deck in the main navigation. That is not just an old TweetDeck memory wearing a Nostr coat. A deck makes particular sense here because Nostr is not one algorithmic feed. It is a moving set of event streams, relay views, profile contexts, tags, lists and conversations. When those streams are collapsed into one endless column, you gain simplicity but lose sight of the shape of the network.
The deck source shows a column system that can add, remove and replace modules, with special handling for event and relay-feed columns. That tells you what the app is optimizing for: not a passive scroll, but a working layout. You might keep a main feed beside a relay feed, a thread beside a list, or a media view beside a search. The exact mix is up to the user, and that is the point. Nosotros gives power users a way to keep multiple Nostr questions open at the same time.
This is also where the app will either win you or lose you. A deck can become clarity, or it can become clutter with a better grid system. If you are new to Nostr, start with the ordinary feed, articles and lists before you build a command center. If you already follow relays, lists, builders, media people and weird side channels, the deck is probably the reason Nosotros deserves a serious try. It lets you stop asking the app to guess your priority and start arranging the network yourself.
The design decision pairs nicely with the local cache. A deck only feels good when columns can stay responsive, restore context and avoid constantly refetching the same world. That does not mean every query will be instant or every relay will cooperate. But the combination of deck UI, relay awareness and SQLite-WASM storage explains why Nosotros has a sharper identity than the label "web client" suggests.
How I would test it
First, open Nosotros in read-only mode with a public identifier and treat it like a lens. Do your profile, follow list, notes, threads, articles and media appear in a way that makes sense? Then sign in with a NIP-07 extension and watch the permission prompts. A web client earns trust by asking for the smallest reasonable signing action at the moment it needs it. If you use a bunker or remote signer, test the NIP-46 flow separately and confirm that signing happens outside the page.
Second, do one small action that should survive outside Nosotros. React to a note, write a short note, open a thread, add or inspect a list, view an article, upload or open a media attachment if you are comfortable doing that, and then check the result from another Nostr client. A Nostr app is strongest when it does not trap your work inside its own interface. The beautiful part of the protocol is not that every app looks the same. It is that your signed events can travel.
Third, visit the Relays and Settings areas. Look at read/write relay configuration. Look at the storage numbers. Try the database export only if you know where that file will land, and use delete only when you genuinely want to wipe the local cache. This is not glamorous, but it tells you whether the app respects your control after the first pleasant session. Nosotros exposes enough of this machinery to make the inspection worthwhile.
Finally, keep the ambition and the tradeoff in the same hand. Nosotros is a real, active, open-source client with a thoughtful signing posture and a serious local-storage strategy. It is also a browser app with a large surface area, many supported NIPs, relay dependencies and features that will vary with the signer, relays and other clients you use. Read it as a fast workbench, not as a promise that Nostr's mess disappears. The mess is partly the point. Nosotros gives you better tools for seeing it.
Sources worth opening
This article keeps claims close to the public product and code trail. Start here if you want to verify the app instead of trusting the summary.
- Nosotros production app
- Nosotros development app
- NostrApps listing for Nosotros
- Nosotros GitHub repository
- Nosotros issue tracker
- Nosotros README
- Nosotros package.json
- Nosotros Vite and PWA config
- Nosotros sign-in selector source
- Nosotros NIP-07 signer source
- Nosotros NIP-46 remote signer source
- Nosotros SQLite storage source
- Nosotros storage settings source
- Nosotros deck hook source
- Nosotros relays route source
- Nosotros relay-list publisher source
- NIP-07 browser signer capability
- NIP-46 remote signing
- NIP-57 Lightning zaps
- NIP-96 HTTP file storage integration
- NIP-25 reactions
- NIP-27 text note references
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
