CraysCoracle
Coracle is a Nostr client for people who want the feed to be shaped by relays, lists, trust and communities instead of one global timeline: a Svelte PWA with custom feeds, web-of-trust moderation, white-labeling, zaps, NWC and Android builds.
A client built around relays
Coracle should be read as a relay-aware Nostr client, not only as another web timeline. Its README says the project is focused on what is unique about Nostr, especially relay selection and management, web-of-trust based moderation, content recommendations and privacy protection. That sentence is the product's center of gravity. Coracle exists because Nostr does not have one platform database, one algorithm and one moderation department.
In ordinary use, Coracle still looks like a social client. It has notes, threads, replies, profiles, notifications, follows, searches, zaps, media previews, direct messages, communities and lists. The difference is that the app tries to keep the relay layer visible enough to matter. Notes can show relay context, relay pages have detail views, users can manage read, write and messaging relays, and feeds can be built from people, relays and topics.
That makes Coracle valuable for readers who want to understand why Nostr behaves differently from centralized social media. Missing posts, duplicate posts, relay quality, community boundaries, group membership, private messages, media uploads and zap receipts are not random glitches. They are consequences of a network made from many independently run servers. Coracle tries to make that mess navigable without pretending it does not exist.
The current public project
The public repository is `coracle-social/coracle`. GitHub described it on June 11, 2026 as an experimental Nostr client for browsing, filtering, zapping and creating custom feeds, with a homepage at `https://app.coracle.social`. The repository was created on November 25, 2022, used Svelte as its main language, carried the MIT License and had current activity as of June 2026.
The repository version in `package.json` was `0.6.33`. The GitHub releases API did not expose a normal release list, so the changelog and package metadata are the better public version trail. The top changelog entry for 0.6.33 included default and relay feeds, feed controls moved to a desktop sidebar, polls and reposts. Nearby entries mention bunker login fixes, NIP-55 signer upgrades, video thumbnails, default relay updates and NWC wallet management.
Coracle is associated with hodlbod and the coracle-social organization. The README links to a Geyser funding page for people who want to support development with sats. That funding route, the long changelog and the surrounding Welshman libraries make Coracle feel less like a single website and more like a working client family: app, libraries, Dufflepud helper service, Android packaging and white-label instances.
What a regular user sees first
Coracle's live metadata describes it as a Nostr client for regular people. That is a useful counterweight to the technical README. The app is meant to feel like a web client: open the site, log in, read a feed, search, follow, reply, react, send a message, publish a note, zap a post, open a profile, view notifications and create or browse more specialized feeds.
The feature list covers the usual social-client jobs: threads, social posting, profile search, QR profile sharing, NIP-05 verification, note composition with mentions and topics, content warnings, mute and keyword mute, profile pages, follow and follower counts, thread muting, collapsed threads, invoice rendering, quote rendering, link previews, image and video rendering, notifications and multi-account support. Coracle is not only a settings dashboard for relays.
The deeper product choice is that those normal actions are surrounded by Nostr-specific controls. A feed can be tied to relays, people or topics. A profile is not simply a row in one database. A message may depend on signer support, relay lists and encryption mode. A zap involves Lightning, wallet setup and Nostr event receipts. Coracle tries to make those details available without forcing every user into a developer view.
Custom feeds are the main reading tool
Coracle's custom feed system is one of its most distinctive parts. The README says feeds can be customized by person, relay and topic using NIP-51. The app source includes feed creation, editing, selection and form components, while the changelog repeatedly mentions feed controls, relay feeds, topic feeds, global feeds, default feeds, WOT feeds and performance work around feed loading.
This matters because Nostr does not have a single canonical home timeline. A user may want a feed from specific people, a feed from a topic, a feed constrained to a relay, a feed shaped by a list or a feed filtered through trust scoring. Coracle's approach lets the reading surface become a user-controlled object rather than an opaque algorithm owned by the platform.
The cost is that the user has to care about what the feed means. A relay feed is not the same thing as a topic feed. A WOT-filtered feed is not the same as a raw global feed. A person list is not the same as a community. Coracle is strongest when the user understands these distinctions and uses them intentionally instead of expecting one default stream to represent the whole network.
Relay management is not hidden
Coracle has spent much of its history working on relay behavior. The changelog includes entries for relay pages, automatic relay discovery, NIP-65 support, relay hints, relay indicators, relay-filtered feeds, relay cards, relay review pages, quote relay selection, inbox relay warnings, local relays, tor or local relays, relay fallback to zaps and broadcasting user relays when publishing. That is not accidental product noise. It is Coracle's core subject.
The source includes views for relay lists, relay detail pages and relay reviews, and shared components for relay cards, relay actions, relay status and relay title. A relay card can show whether a relay is used for reading, writing or messaging, whether it has metadata, which NIPs it supports and what contact or description data it exposes. Those details help users see relays as part of the social interface.
The practical benefit is simple: when a note is missing, a zap receipt does not appear or a DM does not arrive, Coracle gives the user more context than a blank feed. It can show which relays were involved and lets users join, leave, inspect or review relays. That does not make the relay layer effortless, but it makes the network less mysterious.
Web of trust is a moderation choice
Coracle uses web-of-trust scores to reduce spam and improve feed or group suggestions. The README names web-of-trust based moderation and content recommendations, and the feature list says WOT scores help produce less spam and better group and feed suggestions. The changelog has repeated entries for WOT feeds, WOT badges, WOT popovers, WOT display changes and hiding muted replies.
This is a meaningful moderation model. Instead of one company deciding what everyone sees, Coracle can let the user's social graph influence which people, posts, groups and feeds feel trustworthy. A WOT score can make a feed less noisy without requiring a universal blacklist. It can also help a group or community recommend relevant accounts without pretending that relevance is objective.
The risk is that trust systems can become invisible bias machines if users do not understand them. A web of trust can improve spam resistance, but it can also reinforce cliques or hide unfamiliar voices. Coracle's interface needs to make WOT visible enough for users to notice when it is shaping a feed. Used carefully, it is a reader-controlled filter. Used blindly, it becomes another algorithm with softer branding.
Login is deliberately flexible
Coracle supports several login paths. The README lists login via browser extension, nsecbunker and pubkey. The changelog adds work around NIP-46 signer connections, NIP-55 Android signer support and bunker login fixes. The package also depends on `@welshman/signer` and a `nostr-signer-capacitor-plugin`, which points to the product's split identity as both web app and Android package.
For a web client, signer choice is not cosmetic. A browser extension can sign events without handing the web app a private key. A bunker-style remote signer can move signing authority to another service or device. Pubkey login can offer read-only browsing. Android signer support lets a mobile package integrate with the platform's Nostr signing flow. Each option changes the user's security model.
A careful Coracle user should know how they logged in. Read-only pubkey browsing is not the same as posting. A browser extension is not the same as pasting an nsec. A remote signer is not the same as a local mobile signer. Coracle gives users multiple doors because Nostr identity is portable, but portability only helps when the user understands which door is active.
Zaps and Wallet Connect sit inside the client
Coracle supports Lightning zaps and Nostr Wallet Connect. The README lists Lightning zaps and reactions, NWC support, wallet setup onboarding and a platform zap split configuration. The source includes wallet settings, wallet connect and wallet disconnect views, plus a zap view that handles zap messages, amounts and split payments. The changelog shows ongoing work on zaps, NWC wallet management and zap receipt fetching.
This makes Coracle a social client that can participate in Nostr's money layer without becoming a wallet. The app can help a user set up a wallet, open a zap dialog and send sats to a note or person. NWC allows the app to request wallet actions through a separate wallet connection. That is useful because the feed can stay a feed and the wallet can stay a wallet.
The same warning applies here as with every NWC client: a wallet connection should be scoped. The user should know which wallet is connected, which spending permissions exist, whether the connection has a budget, whether it expires and which app is allowed to use it. Coracle makes zaps feel social, but the money boundary belongs in the wallet configuration, not in vibes.
Communities, groups and lists are not side quests
Coracle supports several group-like surfaces. The README lists NIP-72 communities, NIP-87 closed groups, private group calendars and listings, cross-posting between communities and the main feed, NIP-51 person lists, customizable and shareable feeds and lists, and customizable invite links. The source includes group list, invite creation, invite acceptance, list create, list edit and list detail views.
This is where Coracle's white-label direction starts to make sense. A group may not want a generic global Nostr feed. It may want its own look, default follows, onboarding lists, relays, upload providers, zap split, market toggle and app copy. The README says Coracle is intended to be fully white-labeled by groups, and the environment template exposes many of those knobs.
Communities and closed groups also reveal a hard Nostr problem. A community needs membership, moderation, discovery, calendar events, posts, listings, invitations and relay choices, but Nostr does not give a platform owner one centralized membership table. Coracle's group and list tools are attempts to build usable social spaces from events, relays and signer-controlled identity.
White-labeling changes who Coracle is for
Coracle is not only `coracle.social`. The README explicitly says the app is intended to be white-labeled by groups of various kinds. The environment variables allow a maintainer to define dark and light themes, DVM relays, search relays, default relays, default follows, onboarding lists, upload providers, Dufflepud URL, platform zap split, platform pubkey, app name, app URL, app logo, wordmarks, app description, client name, client ID and market availability.
That configuration surface is unusually important. It means Coracle can be a community shell, not just a single public client. A group can choose the people new users see first, the relays the app trusts by default, the upload providers it prefers and whether markets or zaps are enabled. The app can become a branded interface over Nostr without cutting users off from protocol portability.
The tradeoff is governance. A white-labeled instance has defaults, and defaults matter. They shape who feels visible, which relays receive traffic, which upload services hold files and where zap splits go. A reader using a Coracle instance should ask whether they are using the generic public app or a customized community build, because the interface can look similar while the defaults differ.
Media depends on helpers and upload paths
Coracle renders links, images, videos, invoices and previews, and it supports media upload paths. The README says integrated media uploads use NIP-96, while the changelog later records a period where NIP-96 support was dropped and user Blossom servers were used. The environment template currently lists Blossom URLs and a Dufflepud service URL for link previews and image uploads.
This shows a familiar Nostr media tension. Social users expect media to just work, but Nostr events usually reference media rather than hosting it. A client needs upload providers, preview generation, proxy choices, file metadata, authentication and privacy controls. Dufflepud helps Coracle with previews and uploads; Blossom-style storage gives users another route for media hosting; NIP-96 and NIP-98 provide protocol hooks for HTTP storage and auth.
The user-facing question is where the file goes and who can see the request. Uploading media to a helper service is not the same as publishing text to relays. Fetching link previews can reveal what a user is reading. A Coracle instance's configured Dufflepud and Blossom services therefore belong in the trust model, especially for communities that want predictable media behavior.
Markets and calendars show the app's range
Coracle has supported more than notes and follows for a long time. The README lists NIP-99 classifieds, NIP-52 calendar events, private group calendars and listings, and a market toggle in the environment configuration. The changelog includes entries for NIP-52 time-based calendar event publishing and rendering, NIP-99 classifieds publishing and rendering, price tag frequency support and several community or calendar fixes.
These features matter because they show Coracle treating Nostr as an event system, not only as a social timeline. Calendar events, listings and community posts can all be signed events that clients interpret differently. A group using a white-labeled Coracle instance might care more about events and listings than public microblogging. That is a different product rhythm from a normal global feed.
The caveat is that specialized Nostr event types need other clients and relays to cooperate. A listing that only one client renders well is less portable than a text note. A private group calendar depends on relay access, signer behavior and client compatibility. Coracle's range is a strength, but users should test which partners, relays and clients understand the same event types before relying on them for a real group.
The Welshman stack underneath
Coracle is built with Svelte, Vite and a family of Welshman packages. The package metadata includes `@welshman/app`, `@welshman/content`, `@welshman/editor`, `@welshman/feeds`, `@welshman/lib`, `@welshman/net`, `@welshman/router`, `@welshman/signer`, `@welshman/store` and `@welshman/util`. That stack is part of why Coracle can work as both an application and a source of reusable Nostr patterns.
The Welshman packages appear across the codebase: signer handling, relay derivation, event routing, feed construction, app state, content parsing, editor behavior and utility functions. Coracle's app files then compose those pieces into views for home, search, feeds, relays, wallet settings, messages, groups, lists, publishing and notifications. The architecture is not a thin HTML shell around one API call.
For developers, this matters because Coracle is also a reference point for building relay-aware applications in Svelte. A reader interested in product use can ignore the internals. A builder should notice them. Coracle's real contribution may be partly in the open-source app and partly in the library approach that makes relay routing, feeds, signer state and event repositories easier to reuse.
PWA first, Android also present
Coracle's public app is a web app, but it is not only a website in the old sense. The README lists installable PWA support, and the Vite configuration generates favicons, manifest data, protocol handlers and PWA assets. The live site advertises a web app manifest and includes content security policy settings, Plausible analytics and app metadata for the Coracle brand.
Android support exists through Capacitor. The README includes Android build instructions, `package.json` has Capacitor dependencies and release scripts, and the Android manifest sits in the repository. The changelog includes safe-area fixes, Capacitor upgrades, NIP-55 signer library upgrades, `ws://` relay support on Android and database export fixes on Android. That is real platform work, not just a browser shortcut.
Even so, Coracle's center remains web and PWA. A user can open it from the browser, install it like an app and carry the same client shape across devices. Android packaging helps mobile users and signer integration, but Coracle should be compared primarily with serious web clients and community shells, not with a native mobile-first client like Amethyst.
Privacy is partly about defaults
Coracle's README names privacy protection, and the product choices make that concrete in several ways. Relay selection lets users decide where events are read and written. Web-of-trust filtering can reduce spam without relying on one moderation operator. Signer options can keep private keys out of the web app. Pubkey login can allow read-only browsing. Local relay and tor or local relay work appear in the changelog.
Privacy also depends on instance defaults. The environment template includes default relays, search relays, signer relays, DVM relays, indexer relays, default follows, onboarding lists, Blossom URLs and a Dufflepud helper. A white-labeled community can make reasonable choices for its members, but those choices shape network exposure. Search and upload helpers can see requests. Default relays can see traffic. Default follows shape the first social graph.
The safest Coracle habit is to inspect defaults, not merely trust branding. Which relays are used? Which upload providers are configured? Are zaps enabled? Is a platform zap split active? Which signer method is used? Which feeds are WOT-filtered? Coracle gives the user and instance operator many controls, but privacy comes from understanding how those controls combine.
What to test before relying on it
A practical Coracle test should begin with login. Open the app with a read-only pubkey, then with the signer method you actually plan to use. Confirm that posting, replying, reacting and editing profile data behave as expected. If using Android, test the signer integration and database export path. If using a remote signer or bunker, test connection recovery and what happens when the signer is offline.
The second test should be relay behavior. Create or inspect a feed, change relay constraints, open relay detail pages, review which relays are used for reading, writing and messaging, and publish a test note while watching which relays accept or reject it. Then search for the same note from another client. This reveals whether Coracle's relay model matches the user's expectations.
The third test should cover money, media and groups. Connect a wallet with a small NWC budget, send a tiny zap, verify zap receipts, upload a harmless image, inspect the configured upload path, create or join a low-risk group, test an invite link and try a list-based feed. Coracle's strength is many surfaces working together. A user should test those surfaces together before trusting them with a community.
Who Coracle fits best
Coracle fits users who want more control over the shape of their Nostr feed than a default timeline gives them. It is especially useful for people who care about relay choice, custom feeds, web-of-trust filtering, communities, lists, Nostr search, zaps and white-label group spaces. It also fits builders who want to study a working Svelte client built on reusable Nostr libraries.
It is less ideal for someone who wants every hard Nostr concept hidden. Coracle can be friendly, but it is not trying to erase relays, lists, trust graphs, signer choices and community defaults from view. Those are part of the product. A simpler client may be better for a first five minutes. Coracle becomes more valuable once the user starts asking why a feed looks the way it does.
For communities, Coracle is particularly interesting because it can be configured as a branded interface with chosen defaults. That makes it useful for groups that want Nostr identity and portability without sending every member into a generic global app. The group should still document its defaults clearly. A white-labeled client is only empowering when users know what has been preselected for them.
The reader takeaway
Coracle is one of the most important Nostr clients for understanding the relay-shaped version of social media. It does not simply fetch notes and display a feed. It turns relays, relay hints, relay reviews, custom feeds, lists, WOT scores, zaps, communities and white-label configuration into visible parts of the app experience.
That makes it less polished in the single-platform sense than a tightly controlled centralized app, but more honest about what Nostr is. The network is not one server. It is many relays, many clients, many signers, many communities and many defaults. Coracle gives users a way to work with that reality instead of hiding it until something breaks.
The best way to use Coracle is deliberately: choose a signer, inspect relays, understand feed filters, keep wallet permissions small, check upload helpers and know whether the instance is generic or white-labeled. Used that way, Coracle becomes more than a web client. It becomes a map of how Nostr social software can be assembled.
Sources worth opening
Useful primary sources are Coracle's own site, repository, README, changelog, package metadata, environment template, app source files, funding page, related Welshman and Dufflepud projects, and the NIPs behind its relay, feed, signer, wallet, community and media behavior.
- Coracle public app
- Coracle app host
- Coracle GitHub repository
- Coracle README
- Coracle changelog
- Coracle package metadata
- Coracle license
- Coracle environment template
- Coracle Vite configuration
- Coracle web manifest
- Coracle Android manifest
- Coracle app routes
- Coracle feed create view
- Coracle feed edit view
- Coracle feed form component
- Coracle relay list view
- Coracle relay detail view
- Coracle relay review view
- Coracle relay card component
- Coracle relay actions component
- Coracle web-of-trust popover
- Coracle wallet settings view
- Coracle Wallet Connect view
- Coracle zap view
- Coracle note info component
- Coracle publish card component
- Coracle media detail view
- Coracle invite create view
- Coracle funding page on Geyser
- Dufflepud helper service repository
- Welshman Nostr library organization
- Nostr NIP-04 encrypted direct messages
- Nostr NIP-05 identifiers
- Nostr NIP-17 private direct messages
- Nostr NIP-22 comments
- Nostr NIP-32 labeling
- Nostr NIP-42 relay authentication
- Nostr NIP-44 versioned encryption
- Nostr NIP-46 remote signing
- Nostr NIP-47 Nostr Wallet Connect
- Nostr NIP-50 search
- Nostr NIP-51 lists
- Nostr NIP-52 calendar events
- Nostr NIP-55 Android signer application
- Nostr NIP-57 Lightning zaps
- Nostr NIP-65 relay list metadata
- Nostr NIP-72 moderated communities
- Nostr NIP-78 application-specific data
- Nostr NIP-87 closed groups
- Nostr NIP-89 recommended application handlers
- Nostr NIP-96 HTTP file storage integration
- Nostr NIP-98 HTTP auth
- Nostr NIP-99 classified listings
