Crayslumilumi
lumilumi is a Nostr client that understands a very ordinary truth: sometimes you are not at a desk, your connection is not perfect, and the app still has to respect your attention, bandwidth and keys.
A client built for real network conditions
Most Nostr clients are easiest to understand when you imagine a laptop, a decent connection and a user who never worries about what the feed is loading in the background. lumilumi starts from a different place. Its own public description is plain: it lets you switch between full and low-data modes. That sounds modest until you remember how image-heavy a social feed can become, especially on mobile, especially outdoors, especially when your relay set is pulling a noisy public timeline.
The Japanese Nostr Scrapbox page puts that point more concretely: lumilumi pays attention to mobile data use when people are doing Nostr outside, including whether images inside kind 1 notes should be shown and whether user icons should be loaded. That is not a cosmetic preference. It changes the economics of reading. A client that can turn off avatars, avoid automatic image loading and replace icons with generated boring avatars is saying: your network conditions are part of the product, not an inconvenience you should silently absorb.
The project lives publicly at lumilumi.app, with source code in TsukemonoGit/lumilumi. The repository describes it simply as "the nostr web client." It is open source under MIT, written primarily in Svelte, and its public GitHub trail shows a project that has been worked on steadily since June 2024. The visible contributor list is led by TsukemonoGit, with additional patches from people including kuuote, nikolat, Helche, ikuradon, mattn, hikyae and dependency automation.
That matters because lumilumi is not just a hosted web page with a few relay calls attached. It has the shape of a real client: feed rendering, event cards, settings, signer integration, relay choices, profile surfaces, zaps, polls, maps, custom emoji, channels and long-form article support. You can feel the difference between a demo and a client when the edge cases start appearing. lumilumi has clearly been designed around those edges.
The Japanese onboarding shape
One of the most useful things about researching lumilumi is that the best explanations are not all in English. The Japanese guide "lumilumiではじめるNostr" walks newcomers through starting with the app, and it reads like a product made inside an active local scene rather than a generic global landing page. It talks about choosing relay sets, using Japanese relays such as wss://relay-jp.nostr.wirednet.jp and wss://yabu.me, searching for people, and understanding why signing matters.
That local context gives lumilumi a different flavor from many English-first Nostr clients. It is not only trying to say "Nostr is decentralized." It is trying to help someone actually enter the network: pick relays, set a display name, understand that their key is the identity, publish a relay list and start reading without needing to become a protocol historian on day one. The guide also points people toward signers and key-handling options rather than treating private-key custody as an afterthought.
The signer story is especially important. lumilumi is a web client, so the question is never merely "can I log in?" The useful question is how the browser is allowed to sign events. The project's own ecosystem references include NIP-07-style browser signers and Android options such as Amber for remote signing. That keeps the app in the right Nostr posture: the client is where you read and publish, but the key should be handled with care.
There is also a charmingly practical streak in mono's Zenn posts. In the OpenSats application write-up, mono describes lumilumi as a Nostr web client with lightweight modes: not displaying icon images, not loading images automatically, and making the app friendlier to people living with low data. That is product thinking from use, not from a conference slide. You can tell someone has actually been outside with a phone and a Nostr timeline.
Small settings that are not small
NostrApps lists lumilumi with environment-specific settings, a progressive blur slider for warning content, mute words, mute threads, mute users, mute kinds, location tagging, polls, status editing, channel creation and birthday celebration animation. Read that list slowly. It looks like a pile of settings, but underneath it is a coherent idea: a Nostr client should let the reader decide how much of the network enters the room.
Image loading is the obvious example. If you are trying to save data, a timeline should not behave like a vending machine for every preview image, avatar and embedded file it can find. But content comfort is just as important. Warning-content blur gives the reader a middle state between "show everything" and "hide the world." Mutes by word, thread, user and kind create a more granular boundary. A normal platform hides that boundary behind algorithmic taste. Nostr clients have to expose it as tools you can understand.
The settings are not all local. The README calls out synced settings for mute lists, mute-by-kind lists and custom emoji lists. That is a very Nostr-specific distinction. Some preferences should travel with you because they are part of how you operate on the network. Other preferences may belong to one client or one situation. lumilumi's relay setting model reflects the same tension: it supports the standard kind:10002 relay-list approach and also an app-specific relay mode that the README frames as useful when switching contexts, including outdoor use.
Then come the social features that sound small until you have watched a community use them. The birthday feature adds a special animation and a cake marker beside names. Petnames, based on NIP-02 contact lists, help you keep local human labels for people. Geohash location tags let notes carry place context. Article viewing brings NIP-23 kind:30023 writing into the client. The README also mentions a voting feature with multiple options and real-time results. These are not random ornaments; they are ways of making the open protocol feel less like raw infrastructure and more like a place people inhabit.
That is where lumilumi becomes interesting. It does not try to win by being the loudest client in the room. It tries to make the room adjustable. Your data budget, your tolerance for images, your relay behavior, your mutes, your articles, your maps, your emoji lists and your social rituals all belong inside the experience.
The codebase shows its range
Open the package file and you get the outline of the machine. lumilumi uses SvelteKit, Svelte 5, Vite, TypeScript and a Cloudflare adapter. Its Nostr layer includes nostr-tools, rx-nostr, rx-nostr-crypto, @rx-nostr/crypto, nostr-typedef, @konemono/nostr-login, @konemono/nostr-content-parser and nip07-awaiter. That stack says the app is not just rendering static notes; it is doing reactive event flow, signer waiting, content parsing and typed Nostr work.
The rest of the dependencies explain the product surface. @google/model-viewer and three point to the 3D view. leaflet and sveaflet explain the mapping layer. light-bolt11-decoder and QR-code tooling sit near zaps and payment flows. Markdown plugins support richer reading. svelte-boring-avatars fits the low-data avatar mode. This is the nice thing about source code: it quietly confirms what the feature list claims.
The component tree goes even further. You find event cards for regular notes, picture-first events, channels, articles, zaps, highlights and application-specific data. There are components for custom emoji, relay menus, user status editing, zap invoices, polls, birthday festival visuals, muted indicators and settings panels. A Nostr client with that range has to make choices about event kinds, relay filters and the amount of protocol weirdness it is willing to show the user. lumilumi appears comfortable living close to that weirdness.
The README even lists keyboard shortcuts: n opens note entry, Ctrl+Enter posts, and pressing Esc twice closes the entry. Those little details are often where an app stops being a novelty and starts becoming a daily tool. You do not add shortcuts because a directory listing needs them. You add them because somebody is using the thing enough to want rhythm.
Who will love it
lumilumi is not the first client I would hand to someone who wants the most polished one-click mainstream Nostr experience. That is not an insult. It is a clue. This is a client for users who want to tune their environment, who care about data use, who like seeing how Nostr settings travel, who want a web client with Japanese community roots, and who enjoy the fact that Nostr apps can still feel handmade in the best sense.
If you are testing it, do the test properly. Use a low-risk key or a signer you trust. Turn image loading off and see how readable the timeline remains. Publish or inspect a kind:10002 relay list. Try the search route. Open a long-form kind:30023 article. Look at how mutes are stored. Check how the app behaves when you change relay context. If you are on mobile, pay attention to whether the low-data choices feel like real relief or just a label.
The best thing about lumilumi is that it makes a quiet argument about Nostr design. A decentralized network does not become humane just because the protocol is open. It becomes humane when clients give people practical control over what they load, what they see, where they publish and how much energy the timeline is allowed to demand. lumilumi is one of the clients trying to make that control visible.
Sources worth opening
This article keeps claims close to the public project trail. Start with these pages when you want to verify the product yourself.
- Official project
- GitHub repository
- Project README
- Package file
- NostrApps listing
- Japanese Nostr Scrapbox page
- Zenn guide: starting Nostr with lumilumi
- Zenn post: OpenSats application write-up
- NIP-02 contact lists and petnames context
- NIP-23 long-form content context
- 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
