CraysCitrine
Citrine turns an Android phone into a personal Nostr relay: a local event store that other apps on the same device can read from, write to and keep using when the network disappears. It is not glamorous in the timeline-client sense. It is more useful than that.
The phone becomes a relay
Citrine is one of those Nostr apps that sounds boring until the penny drops. It is not a client where you scroll. It is not a signer where you approve events. It is not a wallet where zaps become visible. Citrine is a relay that runs on Android. The phone becomes a little server, and other Nostr apps on the same device can talk to it.
That changes the mental model. Most users meet Nostr through clients: Amethyst, Damus, Primal, Coracle, noStrudel, Iris, Yakihonne. The client feels like the app, so the rest of the stack quietly disappears. But Nostr is not only the client. It is a dance between keys, events, relays and the client interface. If the relay layer is invisible, you can use Nostr without understanding where your own history actually lives. Citrine makes that layer visible without asking you to rent a server.
The official GitHub description says it plainly: Citrine is a Nostr relay for Android, and it allows Android Nostr clients to send and receive events from the application. OpenSats describes the same idea in more human terms: every other Nostr app on the phone can connect to Citrine over `ws://localhost`, read events from it and write events to it. That single local address is the quiet trick. The phone does not need to reach a public relay to hand an event from one local app to another local relay.
If you care about sovereignty, this is where the word gets less ceremonial. A public post can go to public relays. That is the point. But not every event deserves the same treatment. Drafts, private lists, encrypted direct messages, muted accounts, local history and events you want to keep before rebroadcasting can live on your own device first. Citrine is not a guarantee that nothing ever leaves the phone. It is a tool for changing the default direction: local first, public when chosen or when the app reconnects.
Why local storage changes the feeling of Nostr
The ordinary Nostr failure is not always dramatic censorship. Sometimes it is much smaller: you open a client on a bad connection and it feels empty. A relay is slow. Your timeline has to be fetched again. A client loses sync. Your contact list looks stale. Your phone is offline, so the whole social world seems gone even though your own device is sitting there with plenty of storage and compute.
Citrine pushes against that feeling. If your Nostr clients use a local relay on the same phone, they can write events to a place that is always reachable while the app is running. You can draft, post to the local relay, keep a record, and let Citrine broadcast queued events when connectivity returns. OpenSats' relay report says this ability shipped in the v1.0.0 line with Android sharing support from a community contributor. The exact user experience still depends on the client, but the architecture is clear: the phone can keep doing Nostr work while the wider network is temporarily missing.
This also makes caching less wasteful. Without a shared local store, each client may refetch similar events from public relays: profiles, follows, notes, reactions, lists. With Citrine, the phone can become a common store for local Nostr apps. That does not magically solve every relay problem, and it does not replace public relays for discovery. But it makes the device less helpless. Your phone can remember.
There is a privacy angle too. OpenSats frames it sharply: many clients still depend on a few large public relays for storage, which is fine for public posts but awkward for DMs, drafts and private list updates. A local relay does not make encrypted metadata disappear, and it does not remove the need for careful client design. But it does mean the canonical copy of sensitive or personal events can be kept close to the user instead of being sprayed across third-party infrastructure by default.
That is why Citrine belongs beside Amber in Greenart7c3's Android stack. Amber answers the question, "Where should my key live?" Citrine answers, "Where should my events live?" A serious Nostr setup needs both questions. Keys without storage are fragile. Storage without signer hygiene is risky. The pair gives Android users a way to separate the user interface from the more durable parts of identity and history.
What Citrine actually does
The README keeps the feature list practical. Citrine can export the database, import the database, export only events from your own account, manage the relay's port, icon, user and start-stop state, broadcast events after coming back online and add content resolvers. It is the opposite of a flashy product page. It names the chores that make a personal relay useful.
Database export and import are not side features. They are the whole point of a personal relay. If your phone becomes a real Nostr store, then moving phones, recovering data and separating your own events from everyone else's become basic survival tasks. A normal social app treats export as an afterthought. A relay app has to treat export as part of the product contract.
Exporting only your own account's events is especially important. A relay can store many events that are not yours: notes you fetched, profiles from people you follow, replies, reactions, tagged events, cached material pulled in for reading. Sometimes you want the whole database. Sometimes you want only your own signed history. Citrine's README makes that distinction visible, and it matters for backup hygiene. Carrying your own event trail is a different job from carrying a large cache of the network.
The relay management controls also matter. A user needs to start and stop the relay, choose a port, identify which local user it belongs to and make sure other apps can find it. If that sounds too technical, remember what Citrine is doing: it is putting server behavior on a phone. The interface has to make relay operation boring enough that ordinary Nostr users can run it, but explicit enough that they understand when the relay is active and reachable.
Content resolvers are the newer piece many readers will miss. OpenSats' project page says recent work focused on content-resolver integration so apps on the same phone can query the relay without extra setup. In Android terms, this points toward Citrine being more than a socket in the background. The app participates in the operating system's way of letting apps exchange or request content. That is exactly where a local relay should live: close enough to other apps that it can become infrastructure, not just a hobby daemon.
The Android build is not a toy
The repository is not an abandoned demo. As of June 6, 2026, GitHub API data shows `greenart7c3/Citrine` is active, not archived, with 709 commits on the public page, 126 stars, 7 forks, 12 open issues, an MIT license and Kotlin as the primary language. The repo was created on February 5, 2024 and was pushed as recently as June 3, 2026. That is a living infrastructure app, not a catalog ghost.
The Android build tells the same story. The Gradle file uses package name `com.greenart7c3.citrine`, sets the minimum SDK to 26, and the current pre-release build metadata lists version `3.0.0-pre2`. The source tree has the expected shape for an Android service-style application: database, server, service, provider, UI, utilities and OkHttp-related code. The manifest requests network access, foreground service permissions, boot completion, notifications and storage access, and it defines content-provider permissions for reading and writing Nostr events.
Those permissions are not ornamental. A relay on your phone needs network sockets. A long-running relay needs a foreground service. A relay that can run after reboot needs boot completion. Export and import need storage access. A content provider needs explicit permissions. F-Droid lists these permissions in plain view for version 2.0.0, which is good because users should know that a personal relay is not a tiny widget. It is a local service with real privileges.
F-Droid currently lists Citrine 2.0.0 as the suggested version, added on March 12, 2026, requiring Android 8.0 or newer. GitHub's stable latest release is v2.0.0, published March 11, 2026, with APK assets for arm64, armeabi-v7a, x86, x86_64 and universal builds plus signed manifest files. The download paths also include Zapstore, Obtainium, GitHub Releases and F-Droid. That distribution mix is very Greenart7c3: keep the app outside one gate, but make verification possible.
The release pages include a GPG verification path for manifests and hashes. That is not just a developer nicety. If you are installing a relay that will handle your local event history, you should care where the APK came from. F-Droid adds its own reproducibility and source correspondence language. Zapstore brings a Nostr-native app-store route. GitHub Releases expose direct artifacts. The right choice depends on your update habits, but the article's advice is simple: install from a source you can keep updated and verify when you can.
Greenart7c3, Amber and the sovereign Android stack
Citrine is built by Greenart7c3, the same developer behind Amber. OpenSats announced long-term support for Greenart7c3 in October 2024 and named him as the creator and lead developer of both projects. That funding context matters because Citrine and Amber are not random adjacent apps. They are two halves of the same user-sovereignty problem on Android.
Amber is the signer. It lets Nostr apps request signatures without each client holding the user's private key. Citrine is the relay. It lets Nostr apps store and retrieve events through a local service instead of depending entirely on public relays. Together they give Android a more serious Nostr stack: keys in one dedicated signing app, events in one local relay, clients free to become interfaces instead of pretending to own everything.
OpenSats' LTS announcement said the grant would support continued work on Amber and Citrine, better user experience with Amethyst, testing integrations with web applications such as Snort and Coracle, and NIP-55 libraries for external signer support. That is a useful signal. Greenart7c3's work is not only about one app. It is about making the Android side of Nostr behave more like an ecosystem, where clients, signers and relays can share responsibilities.
The official Greenart7c3 site now frames Amber, Citrine and Morganite together as apps for owning Nostr identity, data and media. That phrase can sound like marketing until you map it to the actual products. Amber is identity and signing. Citrine is data and relay storage. Morganite points toward media. The trio is a coherent thesis: the important parts of a user's Nostr life should be held by tools the user can inspect, move and update, not buried inside one all-purpose client.
For Crays readers, that is the reason Citrine is more than a relay curiosity. If Crays venues, profiles, creators or commerce flows ever rely on Nostr records, we do not only need nice front ends. We need ways to keep local copies, verify provenance, operate when connectivity is imperfect and recover from app churn. Citrine is a small Android implementation of that broader lesson.
Stable release, pre-release and where the work is going
The clean stable story is v2.0.0. Its release notes focus on performance, web-app hosting, search and the event screen. The database indexes and Kotlin coroutine handling were changed to improve relay performance. Hosted web apps gained better performance and started on their own ports. The events screen got a better interface, full-text search was used for search queries, events could be expanded in the event screen, and there was an option for downloading tagged events.
That matters because a relay's usefulness is partly speed. OpenSats' March 2026 relay report gives numbers from the broader development arc: write speed improved from roughly 10 to 68 events per second, and read speed from about 1.2 to nearly 5 queries per second, with the sensible caveat that device and database size matter. On a phone, those numbers are not trivia. Mobile hardware has battery, heat and storage constraints. A relay that feels slow will not become a habit.
The newer development trail is v3.0.0-pre2, published May 20, 2026 as a pre-release. It adds Negentropy support through NIP-77, external signer and NIP-42 AUTH support to the relay aggregator, NIP-51 mute-list handling in the relay aggregator, a cap of three relays per author with configurable source and indexer relays, rejection of reposts that embed protected events, local, Wi-Fi and Tor addresses with copy actions on the home screen, a redesigned settings hub, mute-list preservation during age-based deletion, lower relay-aggregator battery drain and performance improvements on hot paths.
That list is dense, but the direction is clear. Citrine is moving from "local relay that stores my stuff" toward "local relay that can help coordinate how my phone talks to the wider Nostr network." Negentropy can help with more efficient set reconciliation. NIP-42 matters when relays need authentication. NIP-51 mute lists matter because a local aggregator should honor the user's own curation choices. Tor and Wi-Fi addresses matter because a phone relay is only useful if you know how to reach it in the context you actually use.
Pre-release means you should treat it like a development build, not the safe default for everyone. But it is the most revealing window into the roadmap. Citrine is not standing still at export/import. It is becoming more aware of relay aggregation, privacy, battery cost, protected events and cross-app ergonomics. Those are the exact problems a personal relay has to solve before it becomes ordinary.
What to check before running a relay on your phone
If you install Citrine, start with a simple test. Run the relay, note the local address and port, connect one Android Nostr client that supports it, publish or fetch a harmless event, then stop the relay and see how the client behaves. The goal is not to produce a perfect setup in ten minutes. The goal is to understand which app is writing to which relay and what still depends on public infrastructure.
Then test offline behavior deliberately. Put the phone in airplane mode, use a compatible client, write something non-sensitive, and see whether Citrine queues and later broadcasts as expected. Check whether the event appears in public relays after reconnecting. Check whether the local copy remains available before and after the network returns. A personal relay earns trust through boring repeatability.
Backups deserve the same attention. Export the full database once, export only your own account's events once, and label both clearly. A local relay gives you more ownership, but ownership includes maintenance. If your phone dies and your relay database was never exported, the sovereignty speech will not comfort you. If you export sensitive local events to cloud storage without thinking, you have only moved the privacy problem.
Finally, watch the operational costs. A phone relay can use battery, storage, foreground services, network permissions and startup behavior. That is normal for what Citrine is doing, but it should not be invisible. Check whether it runs at boot, whether notifications are clear, whether storage grows too quickly, whether your Android build has battery restrictions that stop the service, and whether the version you use is stable or pre-release.
Citrine is a serious app because it makes the relay layer personal. It will not remove the need for public relays, and it will not turn a phone into a hardened server. What it does is more grounded: it lets the phone keep a local piece of your Nostr life, speak WebSocket to clients, survive offline gaps, and carry event history in a way a normal social app would never bother to expose. That is not a small thing. It is the kind of small infrastructure that makes an open protocol feel less fragile in everyday hands.
Sources worth opening
This article keeps claims close to the public project trail. Open these if you want to inspect the code, install route, funding context or Nostr standards behind Citrine.
- Greenart7c3 official site for Amber, Citrine and Morganite
- Citrine GitHub repository
- Citrine README and feature list
- Citrine changelog
- Citrine v2.0.0 stable release
- Citrine v3.0.0-pre2 pre-release
- Citrine on F-Droid
- Citrine on Zapstore
- OpenSats project page for Citrine
- OpenSats report on Nostr relay advancements
- OpenSats long-term support for Greenart7c3
- NIP-01: Basic protocol flow and relay messages
- NIP-42: Authentication of clients to relays
- NIP-51: Lists and mute-list context
- NIP-77: Negentropy syncing
- Citrine on NostrApps
- NIP-86 relay management API
- Nostr protocol NIPs repository
- 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
