CraysJumble
Jumble is useful when you want a Nostr client that treats relays as places to explore, not just as invisible plumbing behind a single familiar timeline.
A client that begins with relays
Jumble is easiest to understand if you do not begin with the post composer. Begin with the feed switcher. Most social clients quietly choose relays for you, then present the result as one timeline. Jumble keeps the relay decision close to the surface. A new visitor can explore relays, a logged-in user can read a following feed, and a community host can preconfigure relay sets for a shared instance. The product is still approachable, but it does not pretend that relay choice is a boring implementation detail.
That emphasis comes from the project's own language. The README calls Jumble a user-friendly Nostr client for exploring relay feeds. The live site at jumble.social follows the same idea. The code does not reduce that to a slogan. Feed state can be following, pinned, a single relay or a relay set. The NoteList page changes its body depending on that feed state. Relay feeds can show relay information, display relay close reasons and detect algorithmic relays before subscribing. The reader is not only following people; the reader is also walking through relay-shaped rooms.
This makes Jumble valuable even for people who already have another Nostr client. It teaches a part of Nostr that polished timelines often hide. A relay is not just a server address. It has speed, policy, local culture, coverage, search quality, storage behavior and moderation choices. Jumble lets those differences become part of the reading experience. When a feed feels empty, noisy or surprisingly good, the reader has a direct clue: change the relay, inspect the relay set, or compare it with the following feed.
The feed can read more than short notes
Jumble is not limited to kind 1 text notes. Its supported event list includes short text notes, reposts, generic reposts, picture events, video events, short video events, polls, comments, voice messages, voice comments, highlights, long-form articles and addressable video events. The rendering layer also knows about relay reviews, emoji sets, follow packs, reactions, external-content reactions, group metadata, community definitions and live events. The app therefore behaves less like a narrow microblogging client and more like a reader for many shapes of Nostr social data.
That breadth matters because the Nostr network is no longer only a stream of notes. A person can publish an article, bookmark a post, repost media, react with a custom emoji, review a relay, join a group-shaped context or share a follow pack. Jumble's ContentPreview and Note components give those objects visual forms instead of treating them all as unknown JSON. Some events still fall back to unknown-note handling, but the intent is clear: Jumble wants the reader to stay inside the app while moving across many event kinds.
The practical benefit is patience. You do not need to switch clients every time a feed contains a picture, a long-form event or a relay review. The practical limit is interoperability. Jumble may understand an event kind that another client ignores, and another client may handle a custom format Jumble only partly displays. That is the honest condition of Nostr apps today. Jumble gives the reader a wider window into the network, but the network is still uneven.
Following, pinned people and relay rooms
The home page is not one hard-coded feed. Jumble's FeedProvider can select a following feed, a pinned-users feed, a relay feed or a relay-set feed. A logged-in user normally starts with following. A community-mode instance can start with an administrator-provided relay set. A reader can browse a single relay as a place, or combine relays into a named set. That gives Jumble a mental model closer to rooms and channels than to one universal social feed.
The pinned feed is useful because it solves a common Nostr problem without forcing the user to rebuild their whole follow list. You can keep a smaller set of accounts close, then read them separately from the larger following graph. The relay-set path solves a different problem: sometimes the unit you care about is not a person but a set of relays where a community, topic or style of posting tends to live. Jumble makes both of those choices first-class enough to be navigated, stored and revisited.
The timeline implementation also shows the cost of doing this honestly. Jumble merges timelines, deduplicates events, tracks reposters, hides deleted events, applies mute and muted-word filters, can hide replies, can apply trust thresholds and can hold new notes until the reader chooses to show them. That is a lot of local work to create the feeling of a calm feed. Relay-first software is not just a relay picker. It must also clean, merge and explain the stream that comes back.
Signers are a real product choice
Jumble offers several login paths because Nostr identity is not one thing. The account manager can use a browser extension through NIP-07 when window.nostr is present. It can create a Nostr Connect request for a remote signer using the default relays bucket.coracle.social, relay.primal.net and relay.damus.io. It can accept bunker URIs. It can import a private key as nsec or hex, and it can open ncryptsec. In development it can also use a public-key-only reading mode.
The private-key path includes a direct warning that using private-key login is insecure and that a browser extension is recommended. That warning belongs in the product, not only in a security guide. A web app that accepts an nsec changes the trust boundary. The browser profile, extensions, local storage, device compromise, future app updates and the site's deployment all become relevant. A NIP-07 extension or remote signer keeps the signing authority outside the web page and usually gives the user a clearer permission surface.
The Electron build changes the tradeoff again. On desktop, Jumble can store secrets through Electron safeStorage when encryption is available, and it refuses to write secrets in plaintext if safeStorage cannot encrypt them. That is better than treating browser localStorage as the only option, but it does not remove the need for judgment. A high-value identity should still use a signer setup the reader understands, and a new client should be tested first with a low-risk account.
The desktop build solves a real relay problem
Jumble's Electron path is not just packaging for convenience. The README says the desktop build runs relay WebSockets in the main process to bypass Chrome's per-origin connection cap. The RelayManager confirms the architecture. It keeps a SmartPool in the Electron main process, subscribes and publishes through IPC, relays event and EOSE messages back to the renderer, forwards close reasons and handles relay auth by asking the renderer to sign the auth event.
That detail is important for a relay-exploration client. Browser tabs can run into connection limits, background throttling and other browser-specific behavior. A client that encourages readers to move across relays and relay sets benefits from controlling the relay pool more directly. In Electron, the renderer is still the user interface, but the relay WebSocket work sits in a process designed to keep those connections alive and coordinate them.
The same desktop path also has security consequences. The secrets store uses Electron safeStorage, writes an encrypted secrets.enc file under the app data path, serializes writes to avoid concurrent corruption and refuses plaintext persistence when safeStorage is unavailable. The reader should see both sides. Desktop Jumble can be more capable than a tab for relay-heavy browsing, but it is installed software. Updates, operating-system keychain behavior and local device security matter.
Media upload is not hidden behind one bucket
Jumble supports media upload through Blossom and NIP-96. The media upload service strips sensitive image metadata before upload, then sends the cleaned file to the configured service. In Blossom mode it reads the user's Blossom server list. If no list exists, it uses recommended servers such as blossom.band, blossom.primal.net and nostr.media, then tries to create a Blossom server list for the user in the background. In NIP-96 mode it reads the service's well-known configuration and signs HTTP authorization before upload.
This is the right shape for a Nostr media client because media storage is not the same as relay storage. Relays carry events. Pictures, videos and files often live on separate HTTP services. A good client must help the user choose those services without pretending they are invisible. Jumble's settings can move between Blossom and NIP-96, and the upload result can produce NIP-94-style metadata tags that later become imeta tags on published events.
The reader should treat upload settings as part of identity hygiene. A media server can disappear, moderate files, enforce size limits, log access, transform files or fail under load. Stripping EXIF and GPS metadata helps reduce accidental leakage, but it does not make uploaded media private. If the post is public and the file URL is public, the file can be copied. Jumble gives more control than a closed platform bucket, but that control comes with choices.
Zaps use Bitcoin Connect and NIP-57
Jumble includes zaps without turning the app into a wallet. Its Wallet settings page connects through Alby's Bitcoin Connect, shows wallet connection state, supports NWC-compatible Lightning wallets, offers default zap amounts and comments, and includes a quick-zap setting. The lightning service creates NIP-57 zap requests, fetches a recipient's Lightning address or LNURL pay endpoint, signs the zap request, asks the callback for an invoice and either pays through a connected provider or opens a payment modal.
The code also validates zap receipts when possible. It checks preimage data when a preimage tag exists and can compare the receipt signer with the nostrPubkey advertised by the recipient's LNURL endpoint. If the endpoint cannot be resolved, the code is more lenient. That is a reasonable compromise for a social client. Readers want zaps to feel light, but a client still needs to avoid treating every kind 9735-looking event as equally trustworthy.
The main caution is the same across all NWC-style app payments. A connected wallet makes small payments feel close to a reaction button. That is the point, and also the risk. Use a wallet connection with limits, try tiny zaps first, confirm that the invoice amount matches what you intended and disconnect when you are done testing. Jumble makes zapping part of the social surface; the reader must still decide how much spending authority belongs inside that surface.
Direct messages have their own key story
Jumble's direct messages are one of the most technically distinctive parts of the app. The project includes a dedicated DM feature document, and the implementation is not a thin wrapper around old encrypted direct messages. It uses NIP-17 style private direct messages, NIP-59 gift wraps and NIP-44 v2 encryption. The key idea is that the user's identity key is not used for background decryption. A separate long-lived encryption keypair handles message encryption, while the identity signer is used for announcements, transfers and message seals.
The send path builds a plaintext rumor, wraps it in a seal and then wraps that seal in a gift wrap. The current format signs the seal with the sender's identity key and carries the sender's encryption public key in an n tag. During a migration window, Jumble can dual-publish both the current identity-signed format and an older encryption-key-signed legacy format. Both copies wrap the same rumor, so they share the same rumor id and can be deduplicated by the receiver.
This is deeper than a checkbox that says private messages. Gift wraps use randomized timestamps to reduce timing leakage. Jumble publishes self-copies so the sender's other devices can sync outgoing messages. DM relays come from kind 10050 lists, separate from ordinary read and write relays. The app keeps forward and backward sync cursors, stores messages in IndexedDB and tracks conversations separately per account. A reader does not need to know every kind number to use it, but the architecture explains why DM setup asks for relays, an encryption key and sometimes key sync.
Multi-device DM sync is explicit
Jumble's DM design recognizes a hard problem: if the identity key should not decrypt messages, a new device still needs a way to obtain the dedicated DM encryption key. The app uses a client-key and key-transfer flow. A new device can publish a client key announcement, then subscribe for an encrypted key-transfer event. An existing device sees the request, asks the user to approve it and sends the encryption private key encrypted to the new device's client key.
That flow uses custom event kinds defined in the code: 4454 for client key announcement and 4455 for key transfer, alongside kind 10044 for the public encryption key announcement and kind 10050 for DM relays. The details are not just technical decoration. They show the design goal. The identity key remains the source of account authority, but the day-to-day decryption key can be moved between devices with a user-visible approval step instead of being pasted as a raw secret.
There are still limits. Key transfer depends on relay availability, user attention and the security of the existing device. A local browser instance stores encryption and client keys through the app's local storage layer, while Electron can move secrets into encrypted safeStorage. If a device is compromised, the DM encryption key is valuable. Jumble's architecture is thoughtful, but no client can make private messaging safe if the reader treats every device as equally trusted.
Filtering is local, social and imperfect
A relay-first client needs stronger filtering controls than a client that only reads a small curated follow graph. Jumble has content policy settings for autoplay, video looping, NSFW display behavior, media autoload, profile-picture autoload, favicon URL templates and muted words. The note list can hide muted authors, hide content mentioning muted users, filter deleted events and remove notes containing muted words. The result is a feed that can be shaped locally even when the underlying relays are broad.
Jumble also has a trust layer. The UserTrustProvider builds a local web-of-trust map from the current user's follow graph and can consult an external reputation service to classify likely spammers. Feeds can apply minimum trust thresholds, hide spam and recommend pubkeys from the stronger part of that graph. This is a pragmatic answer to a real Nostr problem: open relays can carry everything from excellent posts to spam bursts, and the client has to help the reader survive that openness.
The tradeoff is transparency. Trust scores, muted words, relay filters and spam heuristics are useful, but they can also hide posts that another reader sees. Jumble's filtering is not a central moderation regime. It is local reading policy plus relay policy plus external signals. That is a healthier shape than one platform deciding the whole conversation, but it requires the reader to understand that a filtered timeline is an edited view.
Community mode makes Jumble hostable
Jumble is not only meant to be used at jumble.social. The README documents Docker setup and an optional community mode. A host can provide VITE_COMMUNITY_RELAY_SETS and VITE_COMMUNITY_RELAYS so visitors land on preset relay groups. The first preset can be shown by default, and visitors cannot delete administrator-provided relay sets. That makes Jumble useful for a community, family, project or event that wants a shared Nostr window without building a custom client from scratch.
This fits the relay-first identity of the project. A community does not have to ask every newcomer to understand relay selection on day one. It can publish a Jumble instance with a sensible set of relays already present, while still benefiting from Nostr identities, signed events and open clients. The host can shape the starting shelf without owning the underlying social graph.
The reader should still notice the difference between software and instance. Jumble the open-source client can be forked, hosted and inspected. A particular hosted instance can choose defaults, update cadence, deployment environment and community relays. If you use a high-value account, signer choice still matters. If you host for a group, relay selection becomes editorial responsibility. Community mode is powerful precisely because it makes those defaults visible.
Funding and maintenance are visible
Jumble is maintained in public on GitHub under the MIT license. The repository was created in October 2024, lists Cody Tseng as the project author in package metadata, and was pushed again on June 12, 2026 while this page was checked. The latest GitHub release checked was v26.6.1, published June 7, 2026, with changes around posting as another account, configurable Blossom cache servers, improved direct-message UI and reliability, standalone emoji and emoji-set management, translation fixes and UI refinements. The README points to OpenSats as sponsor support and gives donation routes through Lightning, Bitcoin and Geyser. That public maintenance trail is important for a client that asks readers to sign events, upload media and potentially connect wallets.
The repository's activity also explains why the app can feel broader than a small experiment. It contains web, PWA, Docker and Electron paths. It includes many settings surfaces, translations, local database code, media services, relay pooling, zap integration, DM infrastructure, desktop build configuration and release packaging. This is not just a weekend page that reads kind 1 notes. It is a living client with a lot of moving pieces.
A living client also has risk. Open issues, active releases and frequent changes mean the software is still evolving. That is good for features and bug fixes, but it means a careful reader should check release notes, recent commits and issue discussions before using Jumble as their main identity surface. In Nostr, a client can be replaceable, but the actions it signs are not imaginary. Public maintenance is a reason to look closer, not a reason to stop checking.
What to test before relying on Jumble
Begin with reading before signing. Open jumble.social, browse a relay feed, switch between relay and following views, inspect how notes, articles, pictures and relay reviews appear, and compare the same author in another client. Then connect a low-risk account through a browser extension or remote signer. Publish a small note, react, repost and try a zap with a tiny amount if you have a limited wallet connection available.
Next, test relays and media. Change relay sets, observe which feeds become richer or thinner, and check whether your posts are visible from another client. Upload a small image, verify whether the Blossom or NIP-96 service returns a durable URL, and inspect the resulting event tags in a tool that can show raw Nostr events. If you use desktop Jumble, compare relay behavior with the browser version so you understand what the Electron relay manager changes.
Finally, test private messaging only after setup makes sense. Configure DM relays, generate or sync the encryption key, send a message to a test account and confirm how another device receives it. Do not treat DM support as a magic guarantee. Device security, key transfer, relay availability and metadata still matter. Jumble gives the reader unusually thoughtful tools for relay browsing, media, zaps and DMs. The best way to use it is to keep those tools visible instead of pretending the complexity disappeared.
Sources worth opening
Open the live app, repository, README, desktop files, DM notes and protocol documents together. Jumble's identity becomes clear when the relay browser, signer choices, upload services and private messaging code are read side by side.
- Jumble live app
- Jumble settings route
- Jumble notes route
- Jumble GitHub repository
- Jumble README
- Jumble package metadata
- Jumble constants and supported event kinds
- Jumble feed provider
- Jumble feed switcher
- Jumble note list page
- Jumble relay feed page
- Jumble note list component
- Jumble content preview component
- Jumble Nostr provider
- Jumble NIP-07 signer
- Jumble Nostr Connect signer
- Jumble account manager
- Jumble private-key login
- Jumble Nostr Connect login
- Jumble client service
- Jumble SmartPool
- Jumble Electron relay manager
- Jumble Electron secrets store
- Jumble Electron builder config
- Jumble media upload service
- Jumble Blossom service
- Jumble image metadata stripping
- Jumble wallet settings page
- Jumble zap provider
- Jumble Lightning service
- Jumble DM feature document
- Jumble DM service
- Jumble NIP-17 gift-wrap service
- Jumble encryption-key service
- Jumble content policy provider
- Jumble user trust provider
- Jumble releases
- Jumble v26.6.1 release
- Jumble June 2026 encryption-key sync fix
- Jumble issues
- Jumble OpenSats project page
- Jumble Geyser project page
- NIP-01 basic protocol flow
- NIP-07 browser extension signing
- NIP-17 private direct messages
- NIP-44 versioned encryption
- NIP-46 remote signing
- NIP-49 private-key encryption
- NIP-57 Lightning zaps
- NIP-59 gift wraps
- NIP-65 relay list metadata
- NIP-68 picture-first feeds
- NIP-94 file metadata
- NIP-96 HTTP file storage integration
- Blossom repository
- Alby Bitcoin Connect
- nostr-tools repository
- Electron safeStorage documentation
- OpenSats
