CraysFlotilla
Flotilla is the Coracle Social attempt to make Nostr feel less like a timeline and more like a community space: a Discord-like client where the relay is not background plumbing, but the border of the room.
A relay that feels like a place
Most Nostr clients begin with the user: your follows, your feed, your posts, your relays. Flotilla begins somewhere else. It begins with a place. You enter a community, you see rooms, you chat, you read threads, you send direct messages, you discover people, and the relay starts to feel less like invisible machinery and more like the building you walked into.
That is why the old one-line description undersold it. Flotilla is not just a relay chat client in the same way a venue is not just a room with chairs. Yes, chat is there. NostrApps lists the core abilities as browsing relays, chatting inside their communities, sending and receiving direct messages and keeping private notes. But the current official site presents a broader product: a decentralized Discord alternative for communities that want to join existing spaces or launch their own branded platform.
The official language is full of community operator concerns: personalize the instance, organize with your own relays, turn on events, threads, chat or zaps, connect group members, and avoid ads and spying. That is a very different promise from "here is another microblog client." Flotilla is trying to make Nostr useful for the people who run groups, not only the people who post into feeds.
If you are a reader coming from Discord, Slack, Telegram or a private forum, this is the important mental switch: Flotilla wants the community server to be a Nostr relay. The relay is where access, rooms, moderation, membership and history start to matter. That makes the product more opinionated than a generic client, but also more legible. You are not just following an algorithmic stream. You are joining a space whose infrastructure can, at least in principle, be owned by the community itself.
The relays-as-groups bet
The phrase behind Flotilla is "relays as groups." Hodlbod, the builder associated with Coracle, wrote in November 2024 that Flotilla began as a NIP-29 client and then went its own way because the basic unit felt different. In NIP-29, the group is identified by a group id hosted by a relay. In the Flotilla model, the relay itself becomes the top-level community, closer to a Discord server or Slack workspace. Rooms live inside that space.
That distinction is not nerd hair-splitting. It changes who is responsible for what. If the relay is the group, the community operator is pushed toward running or choosing the infrastructure for the group. If many unrelated groups live on one large relay, the relay operator becomes a very powerful landlord. Flotilla's argument is that moderator-led communities already have a center of authority, so their infrastructure should match that reality. The people who run the community should not have to beg a general-purpose relay host to protect or preserve it.
The story did not freeze there. Hodlbod's later guide for relay-based group implementations says rooms have migrated toward managed, NIP-29-compliant behavior. That is a good sign, because it shows the project learning from the broader standards conversation instead of standing outside it. Top-level space as relay, rooms as NIP-29-like managed groups: that combination gives Flotilla a shape that can be understood by both community admins and protocol implementers.
NIP-29 itself is still important context. It defines relay-based groups, membership, metadata, roles, moderation and join or leave requests. Flotilla's code imports and uses many of those event concepts: relay join and leave, relay members, room metadata, room members, room admins, room join and leave, reports, deletion, threads and chat messages. If you want to understand why Flotilla is more than a chat skin, follow those event kinds. They are the governance skeleton under the conversation.
What the app can actually do
In product terms, Flotilla gives you a community surface. The public site calls out multiple groups, an event calendar, zaps, threads, chat rooms and web-of-trust features. The Android listing says the same thing in more practical language: protect a community from censorship and surveillance by self-hosting on Nostr, switch between long-form threads, chat and encrypted Nostr direct messages, configure communities down to the server software and cross-post between public and community spaces.
The app routes back that up. The SvelteKit routes include home, spaces, join, chat, people and settings. There is a spaces route with a create path and relay-specific pages, a chat route with chat-specific pages, and app code for calls, components, core state, editor and utility layers. The package includes LiveKit, which lines up with call support; Capacitor, which lines up with mobile builds; and a Nostr signer plugin for Capacitor, which matters for mobile key handling.
Direct messages are not just a marketing bullet either. The core state code tracks direct message event kinds and builds chat threads by pubkeys. It also has a "note to self" path when the visible chat only contains the user's own key. The NIP-46 permissions string includes NIP-44 encrypt and decrypt plus signing permissions for the event kinds Flotilla needs. That is the kind of detail you want to see in a serious Nostr app: it knows that signing, encryption, event kind boundaries and relay routing are part of the product, not footnotes.
Recent mobile release notes around version 1.8.0 point to a product still being actively sanded down: relay badge overflow, settings placement, small-screen padding, richer link previews, event-summary paste behavior, fewer join or claim requests, bunker login, sharing to chat, calendar embeds, email rendering and better space search. None of that is glamorous in isolation. Together it tells you the app is moving from prototype toward daily community software, where small UX problems become real obstacles.
The code and the people
Flotilla sits inside the Coracle orbit. The official footer links to Coracle Social, the current source is hosted at gitea.coracle.social/coracle/flotilla, and the older GitHub repository under coracle-social/flotilla is archived. That matters for research: if you only open GitHub, you see the history, but not the freshest code. The Gitea repo is the current trail.
As checked on June 6, 2026, the Gitea repository describes Flotilla as a Discord-like Nostr client based on relays as groups. It is public, MIT licensed, not archived, defaulting to the dev branch, and recently active in early June 2026. The language mix is mostly Svelte and TypeScript, with Kotlin, Swift, Java, shell and Dockerfile pieces around the mobile and deployment edges.
The package file gives the stack in plain sight: SvelteKit 2, Svelte 5, Vite 6, TypeScript 5, Tailwind 4, DaisyUI, Playwright tests, Capacitor 8 for Android and iOS shells, Hono for the server side, nostr-tools, the Welshman libraries from Coracle, Pomade, GetAlby Lightning tooling, QR scanning, IndexedDB, link parsing, media compression and LiveKit. It is a serious web/mobile Nostr client, not a static demo.
There is also a white-label angle baked into the README. Environment variables let a deployer set the platform URL, name, logo, relays, accent color and description. A platform-relays setting can make Flotilla operate in platform mode, disabling normal space browsing and pushing the first platform relay as the home page. That is the product path for a community that does not want to send people into a general app first. It can launch its own branded front door.
Self-hosting is the point
Flotilla's strongest promise is not "use Nostr because Nostr." The stronger promise is: your community can have its own social infrastructure. That is why the site talks about no ads, no spying and bringing your data anywhere, but also about branded platforms, curation and turning on the features you need. Communities are messy. A cooking club, a Bitcoin meetup, a music fanbase and a private builder group do not need identical software.
The self-hosting path is concrete. The README includes commands for installing dependencies, building, starting the app, running the official container image or copying static build files into your own mount. That means a serious operator can inspect, deploy and customize rather than only consume. It also warns custom deployers to remove the Plausible analytics script from the app HTML if they do not want analytics going to a server hosted by the developer. That warning is exactly the kind of honest operational detail a community admin should notice.
For Crays, Flotilla matters because it points toward venue-like and member-club uses of Nostr. Imagine a city circle, a members-only hospitality network, a local creator scene or a private investment salon. The public web is useful for discovery, but the ongoing social life of the group needs rooms, calendar items, chat, trust, moderation and direct messaging. Flotilla is one of the clearer attempts to build that shape on Nostr instead of on a closed platform.
That also makes the product commercially interesting. A normal Nostr client has to win users one by one. A community platform can win a whole group if the organizer believes the infrastructure fits. The official site's "Book a Demo" link and white-label language suggest Coracle Social understands this. Flotilla is not only a hobby client; it is also a services and deployment story.
The honest caution
Do not confuse self-hosted with magically private. Flotilla can support direct messages and encrypted Nostr messaging, but group spaces are still shaped by relay policy, client behavior and the people who can access them. Hodlbod's implementation guide says relay-based groups are a better fit for low-stakes groups with many members than for conversations that demand the same privacy expectations as end-to-end encrypted small-group messaging. That is the sober version of the story.
Relays as groups also means relay choice is not cosmetic. If the relay disappears, changes policy, logs too much, fails to enforce access, fails to preserve history or becomes hostile, the community feels it. Flotilla reduces dependence on a single corporate platform, but it does not remove the need for responsible infrastructure. In fact, it puts that responsibility closer to the community operator.
For users, the mobile listings deserve adult attention too. Android builds request permissions that make sense for chat, calling and media, such as camera, microphone and network access. The Play Store data section says some data may be collected or shared. That does not make the app bad; it means a privacy-sensitive user should read the current policy, understand which build they are installing, and distinguish web app, Zapstore build, Google Play build and custom deployment.
That is the right standard for Flotilla: not hype, not dismissal. If your group just wants a public feed, Flotilla may feel heavy. If your group wants a place with rooms, identity, moderation, chat, long-form threads, events and a path to self-owned infrastructure, it is one of the most important Nostr apps to study.
Sources worth opening
Start with the official site for product positioning, then read the current Gitea repository rather than stopping at the archived GitHub mirror.
- Flotilla official site
- Flotilla web app
- Flotilla on NostrApps
- Current Flotilla source on Coracle Gitea
- Flotilla README
- Flotilla package.json
- Flotilla core state and event handling
- Flotilla routes
- Archived GitHub mirror
- Coracle Apps overview
- Flotilla on Zapstore
- Flotilla on Google Play
- hodlbod: Why not NIP 29?
- Relay-based group implementation guide
- NIP-29 relay-based groups
- 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
