CraysChachi
Chachi is the Nostr group-room experiment that tried to make relay-based communities feel less like a protocol demo and more like a place you could actually return to. The useful story includes the product, the NIP-29 model, the OpenSats trail and the uncomfortable fact that the public app is currently not reachable.
A room is different from a feed
Chachi is interesting because it does not begin with the usual Nostr promise of another timeline. It begins with a room. That sounds simple until you look at how much of Nostr still behaves like a public square: notes moving past you, replies attached to people, bookmarks scattered across clients, search depending on relays, and every user slowly discovering that "open protocol" does not automatically mean "comfortable place to gather."
A room has different rules. You need a place, a topic, a memory, a way to enter, a way to leave, a way to remove noise, and ideally a way to keep participating without giving one company control over the social graph. That is where Chachi aimed. In November 2024, verbiricha announced Chachi as a web client for relay-based NIP-29 groups. The short description was group chat, but the bigger ambition was more interesting: every group could have both a chat and a timeline of posts, with future room for richer content types.
That small shift matters for a reader who wants to understand Nostr products. A feed client asks: who do you follow? A group client asks: where are your people gathering, who hosts the room, who moderates it, what can be posted there, and can another client understand the same room later? Chachi's best idea is that groups should not feel like a private Discord server wearing a purple Nostr sticker. They should be rooms whose important actions are signed, relayed and at least potentially interoperable.
The project also had a very practical tone. The README describes Chachi as mobile-friendly, bandwidth efficient and interoperable with different kinds of content. Those are not decorative adjectives. Mobile-friendly matters because group chat is a daily-use behavior, not a once-a-month developer experiment. Bandwidth matters because relays and clients do not all live in the same rich network conditions. Interoperability matters because a Nostr group that only one client can read is not really a Nostr group in the strong sense. It is just another silo with better vocabulary.
NIP-29 puts the room on a relay
To understand Chachi, you need the trade-off in NIP-29. The group is not a magical cloud of events floating everywhere equally. A NIP-29 group is anchored by a relay and a group identifier. That relay is not only a dumb pipe; it becomes the host of group state. It can know which groups exist, which users belong, which roles or moderation actions apply, and which events are acceptable inside that group context.
This gives the model a useful shape. A group can be public or more restricted. It can allow open joining or require approval. It can let admins delete group events, kick members or manage access. In other words, it can behave like an actual community space instead of a global hashtag that hopes everyone behaves well. If you have ever watched a hashtag become unusable because nobody owns the room, the appeal is obvious.
But the same model also asks for honesty. A relay-based group is not the same thing as a group that survives every possible relay failure. The host relay matters. If the relay goes down, changes policy, loses data or becomes hostile, the group feels it. That does not make NIP-29 useless. It makes it concrete. Nostr often wins by letting users and communities choose infrastructure, not by pretending infrastructure disappeared. Chachi sits right inside that tension.
That is why Chachi's official announcement was useful: it did not pitch only vibes. It talked about groups that could be readable by everyone or by authenticated users, and groups that could be open to new members or require approval. Those are the mechanics a serious group client has to face early. A room without access rules is a feed with a name. A room without moderation becomes a liability. A room without relay awareness teaches users the wrong lesson about where their community actually lives.
What Chachi actually shipped
The best public feature map is the Chachi README, and it reads like a project that was built far enough to be real, but not far enough to pretend completion. The shipped side included chat, posts, unread counts, direct messages, threads and PWA support. In groups, it listed creation, editing, joining, leaving and bookmarking. In administration, it listed accepting and rejecting join requests, deleting events, deleting groups and kicking members.
That is a serious surface. Group creation and joining are the obvious parts. The more revealing pieces are bookmarks, unread counts and moderation. Bookmarks mean the app expected people to return to groups, not merely discover them once. Unread counts mean the app was trying to solve the actual rhythm of chat: what happened while you were away? Moderation actions mean Chachi was not naive about public rooms. A group client that cannot remove bad events or bad actors is asking communities to do emotional labor with no tools.
The README is equally important for what it marks as unfinished. Synchronized unread counts were not done. Notifications were not done. Profiles were not done. Joining with invite codes and inviting people were not done. Role creation, role editing and adding or removing admins were not done. That matters because those are not tiny polish tasks. They are the difference between a clever prototype and a dependable community product.
Read those unchecked boxes as product truth. A group app without notifications can still work for small, intentional rooms, but it will struggle as a daily chat replacement. A group app without profile depth can feel anonymous or unfinished. A group app without mature role management is fine for early testing, but brittle for public communities. Chachi's feature list tells you exactly where the idea had legs and exactly where the product still needed road time.
The NIP list in the README is unusually broad. It includes the basic protocol flow, follow lists, NIP-07 browser signers, event deletion, relay information documents, private direct messages, bech32 identifiers, comments, long-form content, reactions, text-note references, relay-based groups, custom emoji, remote signing, Nostr Wallet Connect, lists, calendar events, live activities, zaps, Cashu wallet events, nut zaps, relay list metadata, protected events, video, zap goals and code snippets. You do not need all of that to send a message. You need it if you are trying to make a group client that can absorb many kinds of Nostr content without falling apart.
The codebase is bigger than the vanished demo
The public app may be unavailable, but the GitHub repository still says a lot. The active public code trail is `purrgrammer/chachi`, an MIT-licensed TypeScript project. GitHub shows 625 commits, 24 stars, 5 forks and 24 open issues by API check on June 6, 2026. The project was last pushed on March 31, 2026, and the repository metadata says it was updated on April 23, 2026. The GitHub web page also marks it as archived by the owner on April 23, 2026, which means it is read-only unless the owner changes course.
The stack is a modern web app, not a tiny static mockup. The package file uses Vite, React, TypeScript, Vitest, Tailwind-related tooling and a large set of interface libraries. For Nostr it brings in NDK, NDK's Dexie cache, nostr-tools and NDK wallet support. For local persistence it uses Dexie. For media and publishing surfaces it includes Blossom client support, React Markdown, Asciidoctor, Prism rendering, a media player, image blurhash support and custom emoji packages. For maps it includes pigeon-maps and geohash tooling. For payments it includes Cashu, bitcoinjs-lib, LNURL pay and Lightning invoice decoding.
That dependency list tells a richer story than the broken website. Chachi was not only a chat box. It was moving toward a room that could carry posts, files, long-form text, media, maps, emoji, zaps and wallet-adjacent actions. OpenSats later described the same direction: text notes, long-form content, polls, highlights, custom emojis, with planned work around video, audio, wikis and calendar events. The product idea was not "Nostr Discord clone" in the lazy sense. It was closer to a community client that could let many Nostr content types appear inside a group context.
The source tree reinforces that. GitHub exposes pages for community events, community settings, groups, group settings, joins, relays, settings and user profiles. That is exactly the kind of route map you would expect from a group product that has to manage both rooms and people. The code can still be read, forked and studied. The thing you cannot responsibly say today is that the hosted product is healthy. Code availability and service availability are different claims.
Who is behind it
The public builder trail points to verbiricha. The November 2024 Nostr announcement was posted from verbiricha's account, and the Chachi repository's maintainer file lists the npub `npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg` with relays `wss://frens.nostr1.com` and `wss://nos.lol`. NoBS Bitcoin covered the first release the next day and identified Chachi as a NIP-29 group chat web client. OpenSats later linked Chachi to the same Nostr identity in its grant announcement.
That is enough to name the public maintainer trail. It is not enough to invent a company, a team size or a hidden roadmap. The repo owner name is `purrgrammer`, the announcement name is verbiricha, the license is MIT and the project received an OpenSats Nostr grant. Everything beyond that should be treated carefully unless the builder publishes more.
This kind of restraint is important in the Nostr ecosystem. Many useful projects are built by one or two people, sometimes under persistent handles rather than conventional company pages. The right standard is not to demand a LinkedIn-shaped founder story for every protocol experiment. The right standard is to show the trail: public posts, public repo, maintainer file, grant listing, source code, dates, current state. Chachi has a trail. It also has gaps. A good profile shows both.
The uncomfortable part
As of June 6, 2026, `https://chachi.chat/` returns a 404. The original announcement also linked to a Gitea repository at `git.v0l.io/verbiricha/chachi`; the visible Gitea page currently does not show usable project contents, and a direct clone check fails with access restrictions. The GitHub repo is the useful public code source now, but it is archived.
That changes how you should approach the app. If you came here looking for a daily driver today, Chachi is not a simple recommendation. It may come back, someone may fork it, or the original builder may reopen the project, but the currently verifiable state is not "open the app and go." It is "study the code and the concept, then verify whether a live deployment exists before trusting it for a group."
This is not a hit piece. It is the opposite. Nostr needs honest memory. A project can be important even when the public app is offline. It can influence how people think about NIP-29 groups. It can show how hard group clients really are. It can give future builders a usable map of decisions: which NIPs to combine, how to handle group admin, how much content to allow inside a room, where unread state becomes painful, and why a hosted demo is never the whole project.
The archive state also makes the security posture clearer. Do not paste sensitive keys into a resurrected Chachi deployment just because the name is familiar. Check the domain, the repository, the deployment owner if visible, the signer flow and the permissions. Prefer an external signer or remote signing flow over entering private keys into a web page. That caution applies to every web Nostr client, but it is especially important when a project has changed availability status.
Why OpenSats noticed it
OpenSats included Chachi in its tenth wave of Nostr grants on March 27, 2025. That tells you the project was not merely a catalog curiosity. OpenSats framed Chachi as a relay-based group client implementing NIP-29, with a focus on mobile-friendly communication, open standards, Blossom for file hosting and less lock-in around where communities store messages and files.
The grant note is useful because it names the product pressure points. Communities are not only text streams. They need files, notes, longer posts, polls, highlights, custom emoji, maybe video, maybe audio, maybe calendars, maybe wikis. They need to know where their messages live and where their files live. They need clients that can read the same room instead of forcing everyone into one app. That is the practical problem Chachi was trying to solve.
OpenSats also described planned work around synchronized unread state, notifications, NIP-17 direct messages with unread synchronization, group administration, richer profiles, PWA installation, multiple login methods and Bitcoin features such as zaps. That list is almost a checklist for why group apps are difficult. A social feed can feel useful with posting, replying and following. A community room needs continuity. It needs presence across devices. It needs invitations, permissions, notifications, admin tools and trust around files and money.
This is why Chachi still deserves a page even in archived form. It sits at the point where Nostr stops being a personal broadcast network and becomes community infrastructure. That is a harder job. It requires more than a nice composer and a relay picker. It requires the boring, demanding parts of social software: state, memory, moderation, onboarding, recovery and shared context.
How to test Chachi if it comes back
If Chachi returns, do not start by asking whether the landing page looks alive. Start by testing the room model. Create or join a harmless public group. Check which relay hosts it. Check whether the group can be discovered from another client or at least through a NIP-29-aware path. Send a normal chat message, then a post, then a reply. Look for whether replies use the expected comment model and whether group-scoped content stays tied to the room rather than becoming a confusing global note.
Then test the parts that decide whether a community can live there. Can you leave? Can you rejoin? Can you bookmark the group? Does unread state make sense after you close the app and return? Do notifications exist? Can admins accept or reject join requests? Can they remove bad events without breaking the whole conversation? If a file is posted, where does it live? If a zap appears, does the payment trail make sense?
Finally, test the key flow like a suspicious adult. A web app should work cleanly with a browser signer, remote signer or another explicit permission model. If it asks for too much, stop. If it makes relay behavior invisible, slow down. If it cannot explain where group data is hosted, slow down again. Chachi's promise is strongest when it makes Nostr groups easier to use without hiding the infrastructure choices that make the group real.
The best version of Chachi would be a room you can enjoy without forgetting how it works. You should be able to talk, read, post, moderate and come back tomorrow. You should also be able to understand the relay, the signer, the file host and the protocol events underneath. That is the line Chachi tried to walk. Whether the original app returns or the idea survives through forks, that line is still worth studying.
Sources worth opening
This article keeps claims close to the public project trail. Start here if you want to verify the current state, read the code or understand the protocol choices behind Chachi.
- Chachi official website
- purrgrammer/chachi on GitHub
- Chachi README and feature checklist
- Chachi package.json and web stack
- Chachi maintainers.yaml
- OpenSats tenth wave of Nostr grants
- NoBS Bitcoin coverage of the first Chachi release
- verbiricha's Chachi announcement on Nostr
- Archived copy of the Chachi announcement
- Original Gitea project trail
- NIP-29: Relay-based groups
- NIP-22: Comments
- NIP-17: Private Direct Messages
- NIP-46: Nostr Remote Signing
- NIP-47: Nostr Wallet Connect
- NIP-51: Lists
- NIP-57: Lightning zaps
- Chachi on NostrApps
- NIP-44 encrypted payloads
- 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
