CraysRelay Tools
Relay Tools belongs to the part of Nostr most people only notice when something breaks: the relay layer. It is built for the person who has to look inside a relay, understand what is moving through it and make decisions without pretending that moderation, access control or server policy are someone else's problem.
The app for the person holding the relay keys
Most Nostr apps begin with a familiar picture: a feed, a profile, a composer, a notification badge, maybe a wallet button if the app lives near Bitcoin. Relay Tools starts somewhere else. It starts with the machine room. The public description is blunt: an Android app for browsing and managing relays. That sounds dry until you remember what a relay is in Nostr. A relay is not a background detail. It is the server that receives events, stores them or refuses them, answers subscriptions, enforces local policy and decides what it is willing to carry.
If you run a relay, you are not merely hosting a neutral pipe. You are choosing how your corner of the network behaves. You may run a small friends-only relay, a paid relay, a topical relay for a community, a venue relay, a public relay with spam defenses or a relay that exists because one event kind matters to your project. Relay Tools is interesting because it gives that operator a mobile surface. Not a dashboard buried in a browser tab on a laptop, but a phone app that can look at relay events, classify them by kind and call management methods against the relay.
That changes the reader we should imagine. Relay Tools is not the first app you hand to someone who only wants to post a note. It is the app you look at when you are already asking harder questions. Which events are actually arriving? Which kinds are filling the relay? Which pubkey is causing trouble? Did this relay expose management methods? Can I act from Android without pasting a private key into the wrong place? Those questions are not glamorous, but they are where a lot of Nostr becomes real.
What the public listing actually says
The strongest concise description comes from the NostrApps listing: Relay Tools is an Android app for browsing and managing relays. The same listing names the developer as cloud fodder, links the app to Zapstore and flags the app type as Android. It also lists the app as not open source. That last point matters. We can describe what the public project pages and related documentation prove, but we should not pretend we audited the Android code. For a relay management app, that honesty is not a footnote. It is part of the product judgment.
The feature list is compact and unusually technical: manage multiple relays, view relay events classified by kind, call NIP-86 methods on events and use NIP-55 Amber support. Each item tells you the intended audience. Multi-relay management says the app expects more than a casual one-off check. Event browsing by kind says the app treats Nostr's event model as the thing to inspect, not as invisible plumbing. NIP-86 says the app can reach into the administrative side of a relay. NIP-55 says Android signing can be delegated to a signer app instead of forcing Relay Tools to hold the user's private key.
That combination is why this is not a normal app-store review. The app's usefulness depends on the relay you point it at, the permissions you give it, the management API your relay supports and the key you use for administrative actions. Relay Tools can be a convenience layer, but it is convenience over powerful operations. The right mental model is closer to a mobile operations console than a social app.
Cloud fodder and the relay.tools world
The public trail around Relay Tools points to cloud fodder, the builder associated with relay.tools. The NostrApps page names cloud fodder as the developer of the Android app. The relay.tools site itself presents the broader product as a way to launch and manage Nostr relays, discover community relays and create several relay types, including invite-only and paid relays. OpenSats also describes relay.tools as a platform for setting up and managing relays, with hosted and self-hosted paths. Put together, the Android app looks less like an isolated experiment and more like the mobile piece of a relay-operator stack.
That stack is worth understanding because it explains the design pressure behind the app. The open GitHub organization includes Relay Creator, a Next.js application that provides a UI and API for creating Nostr relays. Its README says it requires pnpm, MySQL and Prisma ORM. The user stories describe topical relays with keyword filters, invite-only relays with pubkey allow lists, paid public relays that require Lightning payment before posting and free public relays with block lists. The docs explain a deployment made from multiple systemd-nspawn machines: haproxy, strfry, relaycreator and mysql. Spamblaster, another relaytools repository, is a Go plugin for strfry that handles spam control and curation.
This is the important part: Relay Tools, the Android app, sits near real infrastructure. It is not just a client pointed at public timelines. It exists in a world where someone is creating relays, configuring policies, watching logs, blocking pubkeys, charging sats for access, giving moderators authority and trying to keep a relay usable. That is a different kind of Nostr product. It assumes the user is willing to be responsible for a server boundary.
NIP-86 is the real product surface
The phrase "NIP-86 method calling" can sound like protocol trivia. It is not. NIP-86 is the Relay Management API. It defines a JSON-RPC-like HTTP interface on the same URI as the relay's websocket, using a special content type and management method names. The methods can be gentle, such as asking for supported methods, or serious, such as banning a pubkey, allowing a pubkey, banning an event, allowing an event, changing the relay name, changing the description, changing the icon, allowing a kind, disallowing a kind or listing blocked IPs.
If Relay Tools lets you call NIP-86 methods on events, the app is giving you a buttoned interface over actions that can change who may post, which event may remain and what the relay presents to the world. That is the appeal. You do not have to build a custom HTTP request each time. You can inspect an event and act in context. But it is also the danger. A good relay-management client must make the action unmistakable. Banning a pubkey is not like muting someone in your personal client. It changes the local server's acceptance policy. Banning an event is not a dislike. It can remove that event from your relay's public surface.
NIP-86 also requires authorization. The NIP points to NIP-98 HTTP auth and says management requests need a valid Nostr authorization event, with a payload tag required. In plain language: the relay should not accept administrative calls just because some app knows the URL. The request must be signed, and the relay must decide whether that key has the right to manage it. When you evaluate Relay Tools, this is one of the first things to test. Which key is signing the management request? Can the app show you the method before it is sent? Does the relay reject calls from keys that are not administrators? If the answer is fuzzy, slow down.
Amber and the Android trust split
The NostrApps listing specifically mentions NIP-55 Amber support. That is a strong design clue. NIP-55 is the Android Signer Application spec. It lets an Android Nostr client ask a separate signer app to sign events, encrypt, decrypt or return the public key. The client does not need to hold the user's private key. Amber is the best-known Android signer in this part of the ecosystem, so Relay Tools supporting Amber means an operator can keep key custody separated from the relay-management interface.
That separation matters more here than it does for a playful timeline app. A relay operator's key may carry administrative power. If a mobile app can ban pubkeys, allow event kinds or trigger reports, the key behind those actions has consequence. NIP-55 creates a better trust split: Relay Tools can prepare the thing that needs signing, Amber can present the signing request and the user can approve or reject it. The app still deserves caution, because a client can ask for powerful signatures, but the architecture is healthier than typing an nsec into every tool that wants to help.
For the reader, the practical test is simple. Install the signer first. Connect Relay Tools through the signer flow. Watch the permissions. Look at the event kind or method being approved. Avoid "remember this forever" permissions until you understand what the app asks for repeatedly. Convenience is good, but in relay operations convenience should arrive after clarity.
Event kinds are the map
Relay Tools also advertises event browsing classified by kind. That may sound like a small feature until you have watched a busy relay. Nostr does not carry one generic content object. It carries event kinds. A short note is kind 1. A report is kind 1984. A NIP-42 authentication event is kind 22242. NIP-98 HTTP auth uses kind 27235. Other clients, communities, marketplaces, lists, long-form articles, badges, reactions and private-message systems all bring their own kinds and conventions.
A relay operator needs that shape. If a relay is supposed to serve a tiny topical community and it is suddenly full of unrelated high-volume kinds, you need to see it. If a moderation flow depends on reports, you need to recognize kind 1984. If a relay is rejecting writes because authentication is required, you need to understand NIP-42. If a paid or invite-only relay says it supports certain limitations in its NIP-11 document, you want to compare the policy with what is actually arriving.
This is where a mobile relay browser can become educational in the best way. It can show you that Nostr is not magic. It is structured traffic. When a tool sorts by kind, it gives the operator a vocabulary. You stop saying "the relay is weird" and start saying "this kind is noisy," "this key is posting outside the expected policy," "these reports are arriving," or "this client is sending events my relay never meant to store."
Moderation is local, not universal
The relaytools user stories make the moderation philosophy plain. A topical relay can have moderators. A moderator can use the relay explorer and choose "Delete Post," which sends a kind 1984 report for a specific message. The relay responds by deleting the post. Another action, "Delete All from Pubkey," adds the pubkey to blocked pubkeys and sends a report for that pubkey. Future posts from the same pubkey are blocked by that relay. If a moderator cannot log into relay.tools, they can send a kind 1984 report from another client, and the relay can act on it.
That is a very Nostr-shaped compromise. Moderation is not a global erase button. It is local relay policy. The event may still exist elsewhere. Other relays may keep it. Other clients may display it. Your relay decides what it will carry, and your community decides what it wants its local surface to feel like. Relay Tools fits that model because it gives the operator a closer view of the relay's own boundary.
This also means Relay Tools should be judged by whether it helps you act with restraint. A useful moderation app does not make every action feel like a dramatic ban hammer. It helps you inspect, understand and choose the least destructive action that matches your relay's policy. There is a big difference between removing one off-topic event, blocking a spam source, and changing a relay's whole allowed-kind policy. A good operator feels that difference before clicking.
Where Relay Tools meets strfry and the deployment stack
The relay.tools ecosystem leans heavily toward real relay deployment rather than abstract documentation. The public site says it helps people launch their own relays and mentions top Nostr implementations such as strfry and nostr-rs-relay. The GitHub deployment docs show a local relay.tools installation built around machines for haproxy, strfry, relaycreator and mysql. The Spamblaster repository is explicitly a strfry plugin for spam control and curation, with modes such as private, public, allow list and block list.
That matters because a relay-management app is only as meaningful as the servers it can talk to. If your relay exposes NIP-86 management methods, Relay Tools has something to operate. If your relay has NIP-11 metadata, clients can discover what it claims to support. If your relay requires NIP-42 authentication, clients and operators need to understand why writes or reads are rejected. If your policy engine sits behind strfry, the operator experience depends on how those decisions are surfaced.
In other words, Relay Tools is not trying to replace the relay software. It is trying to give the human operator a portable control surface. The relay still has to enforce. The relay still has to authenticate. The relay still has to log, store, reject, delete and publish according to its configuration. The app becomes valuable when it lets you see enough of that behavior to make better decisions from your phone.
Closed-source changes the verdict
NostrApps lists Relay Tools as not open source, and I did not find a public Android source repository for the app itself. That does not automatically make it bad. Plenty of useful apps are closed-source. But it changes the standard of trust, especially because this is not a low-risk content viewer. It is a relay-management app that can sit near administrative actions and signing flows.
For ordinary users, the practical consequence is modest: this probably is not your first Nostr app anyway. For relay operators, the practical consequence is direct: test Relay Tools on a non-critical relay first. Use a signer. Watch every approval request. Confirm that your relay rejects unauthorized management calls. Keep your own logs. Do not connect a production relay with real community consequences until you have seen exactly how the app behaves with your relay software.
The open-source parts around it help build context. Relay Creator, Spamblaster, the deployment images and the docs show the kind of infrastructure cloud fodder and the relaytools project are building. They give us confidence about the project's domain. They do not substitute for an audit of the mobile app. The clean sentence is this: Relay Tools appears to come from a serious relay-operator ecosystem, but the Android app itself should still be treated as a closed-source administrative client.
What to test before a live relay
Before you touch a real community relay with Relay Tools, build a small test path. Point the app at a disposable relay or a relay where you are comfortable experimenting. Confirm that the app can add and distinguish multiple relays. Browse events and check whether the kind classification matches what another client or command-line tool sees. Trigger a harmless NIP-86 call, such as asking for supported methods, before trying any destructive action. If the relay does not answer, learn whether the problem is the relay, authentication, URL shape or app behavior.
Then test authorization. Try a management action with a key that should not have admin rights and make sure the relay rejects it. Try the same with the correct key and inspect the signer prompt. If Amber asks you to sign something, read it. If the action creates a report, look for kind 1984. If the action changes a pubkey list, verify that future writes from that pubkey are handled as expected. If the app says it deleted an event, check the relay from another client or query path.
Finally, test recovery. Can you reverse the action? Can you unban a pubkey? Can you see the allowed and banned lists? Can you explain to another moderator what happened without hand-waving? Relay operations are not only about buttons. They are about accountability. The best operator tool is the one that lets you act and then reconstruct why the action made sense.
Who should actually install it
Install Relay Tools if you run a relay, moderate a relay, test relay software, help a community operate its own infrastructure or want to understand the server side of Nostr without living entirely in shell commands. It is especially relevant for Android users who already use Amber or want to keep administrative signing separated from the app doing the browsing.
Skip it, at least for now, if you only want a friendly Nostr timeline. A social client such as Damus, Amethyst, Primal, Iris, noStrudel or Coracle will teach you more about ordinary use. Relay Tools is for the moment after that, when you realize that the health of a Nostr community depends not only on clients, but also on the relays that carry its records.
The cool thing is that this is where Nostr starts to feel less like a product category and more like a public machine you can understand. Relay Tools lets you put a hand on one of the levers. That is useful. It also means the lever is real. Use it with curiosity, but do not use it casually.
Sources worth opening
This article keeps the Android-app claims close to the public listing and uses the wider relay.tools repositories and NIPs to explain the surrounding technology.
- Relay Tools on Zapstore
- Relay Tools on NostrApps
- relay.tools official site
- cloud fodder Nostr profile
- OpenSats grant note for relay.tools
- relaytools/relaycreator repository
- Relay Creator README
- Relay Creator user stories
- relaytools documentation repository
- relay.tools installation guide
- relay.tools extended documentation
- relay.tools local setup guide
- relay-tools-images deployment repository
- Spamblaster strfry plugin
- Monitorlizard relay monitoring repository
- Cookiecutter deployment agent repository
- NIP-86 Relay Management API
- NIP-55 Android Signer Application
- NIP-56 Reporting
- NIP-11 Relay Information Document
- NIP-42 Relay Authentication
- NIP-98 HTTP Auth
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
