Craysalphaama
alphaama is not trying to be the calm social feed you hand to a cousin. It is a strange, open-source web client that lets you see Nostr as events, relays, keys, commands and experiments.
eskema/alphaama project. NostrApps flags the same thing the code makes obvious: CLI plus GUI, custom code, note inspection and testing. Treat it as a lab bench first and a daily social client second.A client that leaves the wires showing
Most Nostr clients try to make the protocol disappear. That is usually good product work. You open the app, follow people, read notes, reply, zap, mute, maybe change relays after something feels slow. The event shape, the relay request, the signature, the tag array and the signer prompt stay politely behind the curtain.
alphaama does the opposite. Its own README says it lets you interact with Nostr by exposing the protocol instead of hiding it. That sentence is the whole personality of the app. You are not invited into a tidy feed where Nostr is a brand sticker on top of a normal social product. You are invited into the machine room, where notes are events, relays are endpoints, profiles are replaceable records, identifiers are encodings and signing is an action you should understand before you approve it.
The official page is almost bare HTML. It loads a dark theme, a stylesheet, the alphaama core script and the page script. The live code checked for this article loads nostr-tools 2.23.1, fastdom, QR code support and a set of modules with tiny names: cli, p, e, m, r, q, u, b, w, d and h. That sounds cryptic until you read the modules: command line, profiles, events, messages, relays, user state, blobs, double-ratchet messages and other working parts. alphaama is not a landing page wrapped around a promise. It is a running pile of protocol pieces.
That makes it valuable in a very specific way. If you are learning Nostr only through polished clients, you can start thinking the feed is the protocol. It is not. NIP-01 describes a network built from events sent between clients and relays. Each event has an id, pubkey, timestamp, kind, tags, content and signature. Relays receive EVENT messages and answer REQ subscriptions. alphaama is interesting because it keeps that shape close enough that you can feel where the app ends and Nostr begins.
The command line is part of the room
NostrApps reduces alphaama to four useful clues: CLI plus GUI, run custom code, inspect notes and test stuff. That is a better summary than any glossy paragraph would be. The command line is not decoration here. It is a second way to touch the same object. Instead of only clicking through a fixed screen, you can ask the app to do things, inspect state, try commands and watch what comes back.
This matters because Nostr apps often fail in boring, invisible ways. A relay can refuse an event. A filter can be too wide. A profile can be stale on one relay and fresh on another. A direct message can sit on the wrong inbox relay. A signer can deny an operation. A client can show you a pretty note while hiding the reason it cannot find the thread. A tool like alphaama gives the curious user a fighting chance to see what happened.
There is a cultural choice in that. The README is blunt on purpose. It says alphaama is fun and weird, not for everyone, still changing, capable of bugs and bad decisions, and meant as a learning tool. You can read that as a warning label or as the most honest onboarding copy in the directory. Either way, it tells you the correct posture: do not arrive expecting handrails on every edge. Arrive with a test key, a few relay URLs and a reason to inspect something.
The custom-code angle is the sharpest part. It is useful because Nostr is small enough that little experiments can teach you a lot. It is risky because a web app that runs code and asks a signer to approve events is not a place for blind trust. If you paste code you do not understand into any Nostr tool, you are not being brave; you are lending your identity to a stranger. alphaama should make you more careful, not less.
Events, relays and profiles are not background scenery
The event module is one of the clearest signals that alphaama is built for inspection. The code describes it as a place to view and manage events. It knows about kinds, note rendering, zaps, encrypted payloads, drafts, signing and proof-of-work paths. You do not need to memorize every event kind to benefit from this. The point is simpler: alphaama treats the event as the primary object, not as an implementation detail hidden under a like button.
That changes how you read a note. A normal client asks whether the note is interesting. alphaama asks what it is made of. What kind is it? Which public key signed it? Which tags does it carry? Does it reference another event with an e tag, another person with a p tag or an addressable object with an a tag? NIP-19 then explains why the strings people share as npub, note, nevent or related identifiers are display encodings, not magic. alphaama is the kind of tool where those distinctions stop being trivia.
The relay module is just as important. Nostr is often explained as if relays are a neutral fog, but real use is more physical than that. You add read and write relays. You broadcast events. You discover that one relay accepts what another refuses. You notice that a profile, message or relay list only exists where somebody published it. alphaama's relay manager exposes that work. If something disappears, the first question is not "is Nostr broken?" It is "which relays did I ask, and what did they answer?"
The profile module adds another practical layer. It handles profile metadata, follows, followers and NIP-05 checks. That means identity is not treated as a centralized account record. A profile is data signed by a key, found through relays, sometimes verified through a domain, sometimes stale, sometimes missing. When you see that directly, Nostr becomes less mystical and more usable. It is a pile of signed records moving through relay choices.
Messages are where the experiment gets serious
alphaama is not only an event viewer. The code path for messages shows real ambition and real caution. The message module calls itself direct messages and points to NIP-17. That NIP uses NIP-44 encryption and NIP-59 gift wrapping so chat messages can move through public relays while hiding more metadata than old-style encrypted direct messages. In practical terms, alphaama subscribes for gift-wrapped events tagged to the user and tries to decrypt them through the signer path.
Then there is the double-ratchet module. Its own code comment describes forward-secret direct messages, vendored from nostr-double-ratchet, with kind 1060 outer events, encrypted header tags, kind 30078 invites and kind 1059 invite responses. That is not beginner-client territory. It is the kind of feature you test when you care about what private communication on Nostr might become, not merely what it already is in the most common clients.
Forward secrecy is easy to advertise and hard to ship responsibly. The useful part of alphaama is that the code comments do not pretend the problem is simple. They talk about invite handling, state persistence, reload behavior, decrypt caches and avoiding cross-module noise where one message system accidentally tries to process another system's traffic. That is the actual shape of messaging work on Nostr: not a slogan, but a lot of careful boundary keeping.
The signer abstraction is also worth noticing. alphaama looks for window.nostr, the NIP-07 browser capability exposed by extensions, and it also has a NIP-46 bunker path for remote signing. This is the right instinct for a tool that wants power without casually collecting keys. A Nostr app should ask a signer to sign or decrypt. It should not need your raw private key just to let you look around. Still, the safety rule remains yours: read the prompt, understand the event kind, and keep your main identity away from experiments until you trust the tool and your own workflow.
Who is behind the trail we can verify
The public project trail points to eskema/alphaama on GitHub and the live deployment at alphaama.com. The repository describes the project as A<3, uses the WTFPL license, has no published releases at the time of checking and is mostly JavaScript, with CSS and HTML making up the rest. GitHub showed 332 commits, 32 stars and 6 forks when this page was reviewed on June 6, 2026. Those numbers are not a quality score. They are a scale clue: this is a small public project, not a venture-backed consumer app with a support department.
The README also says the software is public domain, free and open source, written in vanilla JavaScript, HTML and CSS, and allowed to change in breaking ways. That matters more than the star count. It means you can inspect the code, but you cannot expect the social contract of a mature mainstream app. The author is telling you up front: this is a work in progress; it has bugs; it has bad decisions; it may break; it is not for everyone.
That honesty should shape our article, too. I am not going to invent a polished founder story where the sources only prove a repository, a deployment and a deliberately rough README. If you need a named team, audited releases, mobile store distribution and predictable support, alphaama is the wrong first stop. If you want a living notebook of Nostr client ideas, with code you can read and a UI that does not hide the mess, it becomes much more interesting.
How to try alphaama without burning your main identity
Start with a throwaway Nostr identity. That is not because alphaama is uniquely suspicious. It is because any experimental client that can sign, decrypt, run commands, manage relays and test messages deserves a clean testing setup. Make a new key, connect a signer you can control, add a small set of relays and do one action at a time. Publish a harmless note. Inspect it. Change relay settings. See whether another client can find the same event.
Then test the parts that make alphaama different. Use the CLI. Inspect a note you already know from another client. Decode a Nostr identifier and compare what alphaama shows with what NIP-19 says the identifier represents. Add a relay as read-only, then as write-capable, and notice how the app behaves. Open the profile view for a known public key and check metadata, follows and NIP-05. If you are testing messages, use a second test identity and keep the conversation boring enough that you do not care if you lose it.
Do not paste private keys into random places. Do not approve signer prompts because you are impatient. Do not run custom code from screenshots, chat messages or strangers unless you understand what it does. A tool that exposes the protocol can teach you faster than a polished client, but it also gives you more ways to make your own mistake. That is part of the bargain.
The reward is real, though. After an hour with alphaama, a Nostr event stops feeling like a mysterious post that lives somewhere in the network. You can see the event, the relay path, the signer, the profile lookup, the DM wrapper and the difference between display strings and wire data. That kind of literacy makes every other Nostr app easier to judge.
Why this odd tool belongs on the shelf
alphaama belongs in the App Hub because Nostr does not only need friendly clients. It also needs tools that keep the protocol visible for the people building, testing, debugging and learning. A network made of many clients and relays becomes healthier when more users can ask concrete questions: Which event did I sign? Which relay did I publish to? Which identifier am I sharing? Which encryption scheme is this message using? Which part is a client choice and which part is a NIP?
That is the role alphaama plays. It is not the app I would put first in front of a brand-new user. It is the app I would show to someone after they have used Nostr long enough to wonder what is really happening under the screen. The design is rough, the wording is rougher, and the source trail is refreshingly unvarnished. But the underlying idea is strong: if you want sovereignty, you eventually need visibility. alphaama gives you a messy, useful version of that visibility.
Sources worth opening
This article stays close to the official project trail, the live code and the Nostr standards it touches. Start here if you want to verify the claims yourself.
- alphaama live app
- eskema/alphaama source code
- alphaama README
- NostrApps alphaama listing
- NIP-01 basic protocol flow
- NIP-07 browser signer capability
- NIP-17 private direct messages
- NIP-19 bech32 identifiers
- NIP-46 remote signing
- NIP-59 gift wrap
- NIP-25 reactions
- NIP-27 text note references
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- NIP-10 text note threading
- NIP-11 relay information document
- NIP-19 bech32 encoded entities
- NIP-44 versioned encryption
- NIP-46 remote signing
- NIP-51 lists and mute lists
- NIP-56 reporting
- NIP-57 lightning zaps
- NIP-65 relay list metadata
