Relays / Local relays

Local Relays for Homes, Venues and Teams

A local relay can turn Nostr from a global feed into a room, venue, team or community layer with its own context.

Relays Local relays Endpoints, policy, metadata and reliability before the next dependency.

Relays NIP-11 Sources

Relays29 min readLocal relays

Local Relays for Homes, Venues and Teams

A local relay turns Nostr from a global feed into a room, venue, team, home or community layer with its own context, rules and memory.

The global network needs local rooms

A global Nostr feed is powerful, but many of the moments people actually care about are local. A conference wants schedules, speaker notes, live questions, badge updates, after-event archives and hallway context. A venue wants members, reservations, menus, room status, event posts, staff announcements and local reputation. A team wants internal notes, project updates and operational logs without forcing everything through a public default relay. A family may want a shared archive. A hotel, cafe, club or coworking space may want digital memory tied to a real room.

A local relay gives those events a natural home. It can be public, private, paid, invite-only, member-only, device-local, venue-local or tied to a physical place. The point is not to fragment the network for the sake of control. The point is to give local context a place to exist without surrendering identity to a closed app. You can bring a Nostr key into the room and leave with the same key.

This is where the relay layer becomes more than plumbing. A public feed is good for global speech. A local relay is good for situated context. The room has a purpose. The operator understands the people. The event kinds can be limited. The rules can be visible. The archive can match the place. The moderation can be human instead of abstract. Nostr stays portable because the identity and event model remain open, but the room gets memory.

You should not use a local relay for everything. If something should be broadly discoverable, publish it beyond the local room. If something is only meaningful to attendees, members, residents, coworkers or family, local storage can be healthier than broadcasting the same event to giant public relays. The skill is deciding which events deserve global reach and which deserve local context.

A good local relay does not compete with the public network. It completes it. It lets Nostr handle the kind of social reality that huge default feeds do badly: rooms, memberships, operations, neighborhoods, venue presence, temporary events and small communities with memory.

Local does not mean isolated

A well-designed local relay sits beside public relays. You can use the same public key, carry identity into the local space, publish some events locally and keep broader social context elsewhere. Your identity remains portable while the room gains its own operational layer. That is the difference between a local Nostr relay and a normal private platform: the venue or team can host context without owning the person.

Isolation happens when clients hide the boundary. If a local relay is the only place a client writes, and the user never understands that, local becomes lock-in. If the client says plainly which events are local, which are public, which are mirrored and which are private, local becomes agency. You can decide whether a conference question stays in the event room, whether an announcement goes public, whether a team note remains internal or whether a photo should be published elsewhere.

NIP-65 relay lists matter here. A user can publish where they prefer to read and write. A project key, venue key or community key can publish a relay list that points clients toward the local room. That does not force every client to obey, but it gives the network a map. Without that map, local discovery becomes word of mouth and copy-pasted endpoints.

Local also does not mean offline. A home relay can be reachable only on a private network. A venue relay can be available on site and mirrored to a public endpoint. A team relay can be private but backed up. A conference relay can run for an event and later expose an archive. A mobile relay such as Citrine can make a phone a local event store for nearby clients or for one user's own apps. The shape depends on the job.

Think of locality as scope, not geography alone. A local relay can belong to a place, a device, a group, an event, a team, a product, a household or a temporary project. The common thread is that the relay has a smaller social contract than a global public relay.

Decide what the local relay should remember

The first design question is memory. What should the relay keep? Public venue posts? Staff-only notes? Member RSVPs? Event schedules? Chat messages? Moderation actions? Badge state? Booking requests? Point-of-sale context? Wallet messages? Sensor updates? Family photos? Long-term archive copies? If you cannot answer what the relay should remember, you cannot choose retention, auth, moderation or software sensibly.

Memory can be short. A conference relay may keep live questions and schedule updates for the event and archive them later. Memory can be durable. A family or club archive may keep photos, notes and member history for years. Memory can be operational. A venue relay may keep current room state, menu updates, service messages and local reputation. Memory can be personal. A home relay may back up your notes and keep them available to your own clients.

Retention should match the memory. Do not keep private coordination forever only because storage is easy. Do not drop public event history after a week if people expect an archive. Do not store wallet-adjacent traffic longer than the product needs. Do not promise an archive if nobody is backing up the database. A local relay is close to people, which makes careless retention more personal.

The event kinds also matter. A simple home relay can accept ordinary notes and profile events. A group relay may need NIP-29 event kinds and moderation flows. A venue relay may need calendar, badge, reservation, menu or custom application events. A wallet-adjacent local relay may need encrypted NWC traffic. Each extra event family adds product complexity and policy responsibility.

Design the smallest useful memory. If the local room only needs schedules and questions, do not build a full social network. If the home relay only needs backup, do not expose it publicly. If the venue needs public discovery and private staff flow, separate those roles. Local infrastructure is strongest when it is boringly clear.

Membership and doors need standards

Local relays often need doors. Not every key should write to a staff relay, a family archive, a member lounge, a venue operations room or a group chat. NIP-42 gives relays a standard way to authenticate clients by challenge and signature. That proves which public key is present. It does not decide whether the key is a member. It gives the relay a clean way to ask before applying local policy.

NIP-43 goes one step closer to access. It defines a way for relays to advertise membership lists and for clients to request admission on behalf of users. That is useful for local relays because membership should not live only in a hidden operator spreadsheet. If the room has a door, clients should be able to understand admission, request access and explain rejection. NIP-43 is draft optional, but the direction is important: local relays need visible membership language.

NIP-29 relay-based groups show another pattern. It defines groups that are only writable by a closed set of users, while they may be public for reading or not. Groups can have moderators, admins, roles and event types for group state. This is local thinking expressed as group infrastructure. A relay can enforce participation rules instead of asking one global feed to behave like a private room.

Doors should be humane. A client should tell you that a relay is local or private before you fail. A signer should show which relay asks for auth. A rejection should explain whether the key is not admitted, payment is missing, auth failed, the event kind is blocked or the group is closed. Local rooms feel trustworthy when the boundary is legible.

Do not confuse membership with identity custody. The local relay may decide who enters the room. It should not own your identity. You should be able to use your key elsewhere, leave the room, publish public material on other relays and keep your broader social graph.

Groups and venues are the strongest local use cases

NIP-29 is important because it treats groups as relay-enforced spaces. That fits a lot of real life. A club may want member posts and moderator approvals. A conference may want rooms and session-specific conversation. A venue may want staff posts, customer-facing announcements and event channels. A school, studio or coworking space may want project rooms. These are not just hashtags. They are rooms with rules.

The Nostrbook comparison of group implementations points to the practical tradeoff: relay-based groups can give moderators and relays real enforcement power. That can be exactly what a local group needs. It can also make the relay operator more important than in a purely public feed. The group is portable only if clients, members and operators design exit and mirroring carefully.

Venues add a physical layer. A cafe, hotel, club, resort or event space can use a relay to hold local state: events tonight, table announcements, local offers, staff messages, community notes, member badges, artist lineups, booking confirmations or creator access. People can arrive with a Nostr key instead of creating yet another venue account. The venue gets context. The person keeps identity.

Local relays can also be temporary. A festival relay may live for a weekend. A pop-up event relay may run for one evening. A hackathon relay may keep project notes until winners are announced. Temporary relays need clear expiration. If the room is temporary, say what happens after the event. Will the archive remain? Will events be mirrored? Will private coordination be deleted? Silence creates bad assumptions.

The best venue pattern is layered. Public announcements can go to public relays and the local relay. Member-only context can stay local. Staff operations can use a private relay or restricted group. Wallet or booking traffic can use a separate sensitive lane. One relay can do some of this, but one mental category should not hide all of it.

Home and personal relays are about custody of your own events

A home relay has a different personality from a venue relay. It may exist only so your own clients have a reliable place to store, read and back up your events. Umbrel's Nostr relay app, nostr-rs-relay setups, Nostr Relay Tray and Citrine all point toward the same desire: you may want a relay close to you, under your control, with rules you understand.

Citrine is especially interesting because it runs on Android and can turn a mobile device into a personal storage hub for Nostr data. That changes the meaning of local. Local can mean "on my phone" rather than "in my city." Your clients on the same device can read and publish to a local event store. That can support backups, offline access and shared state across apps without sending every experiment to public relays.

Nostr Relay Tray points to another audience: people who want to launch and control a relay from a desktop environment, with filtering and local control. That can be useful for testing, personal archives, small groups and learning. It also creates a responsibility: if you expose the relay publicly, you are no longer only running a personal tool. You are operating infrastructure other clients may depend on.

Home relays are not automatically private. If your relay is reachable from the internet, other people may connect. If it is behind Tailscale, LAN-only, Tor-only or device-local, the access model changes. A home relay can be great for backup and terrible for public discovery if nobody else can reach it. That is fine as long as you know the job.

The healthy personal setup is usually mixed. Use public relays for public reach. Use a personal or home relay for your own copy, offline access or archive. Publish a clean NIP-65 list so others know where to find you. Do not assume your private home endpoint should be your public identity's only home.

Software choices should follow the local job

Local relays can run on different stacks because local jobs differ. strfry is known for high-performance relay work. nostr-rs-relay is a Rust relay with SQLite persistence and a long history in the ecosystem. nostream has been widely used for hosted public relays. Khatru is a Go framework for building custom relays. Grain, Nostrify, Nostr Relay Tray, Citrine and other tools cover different operator styles. The right choice depends on what you need, not which name sounds most advanced.

If you need a personal backup, choose something simple, maintainable and easy to recover. If you need a venue relay, focus on auth, policy, monitoring, backups and client compatibility. If you need NIP-29 groups, choose software or a framework that understands group behavior. If you need wallet-adjacent routing, isolate that flow and test permissions carefully. If you need a high-volume public endpoint, a local-relay guide is not enough; you are now doing serious operations.

Access control is a key software question. Can you restrict writes by key? Can you support NIP-42? Can you advertise NIP-11 correctly? Can you handle membership? Can you filter event kinds? Can you set retention? Can you export data? Can you monitor health? Can you return useful rejection messages? A local relay without these features may still be useful, but only for simpler jobs.

Do not overbuild. A local relay that serves one meetup does not need enterprise architecture. A relay that stores a club's long-term member history does need backups. A phone-local relay does not need public DNS. A venue relay may need a status page. A team relay may need explicit moderation and access requests. Start with the social job, then pick the technology.

The operator's skill matters as much as software. A simple relay with a careful operator is safer than a complex stack nobody understands. If the room matters, make sure someone knows how to restart, restore, update, rotate keys and explain failures.

Privacy and retention get more personal when the relay is local

Local context can be sensitive. A public note about a conference talk is different from a staff note about a guest. A member RSVP is different from a global post. A family archive is different from a public profile. A wallet-related local event is different from a venue announcement. When the relay is close to real people and places, privacy mistakes feel less abstract.

Authentication exposes your public key to the relay. Membership lists may reveal who belongs. Event timing can reveal attendance. Local search can reveal behavior inside a room. Even if content is encrypted, the relay may see metadata. That does not make local relays bad. It means local operators should be honest about what they collect and users should understand which key they bring into the room.

Retention is a privacy choice. Keeping everything forever can feel useful until staff chats, old RSVP data or private group coordination become a liability. Deleting too quickly can destroy community memory. The answer is not one default. The answer is a retention policy that matches the room. Event schedules may be public archive. Staff coordination may be short-lived. Member badges may need current state and history. Wallet traffic may need minimal retention.

Backups also carry privacy. If a local relay is backed up to a cloud provider, the room is not only local anymore. If an operator exports data casually, members may not know where their events went. If a venue changes owner, who controls the relay archive? These are human questions wrapped in infrastructure.

Use different keys when context deserves it. Your global public identity may be fine for a club. A staff operations key may deserve separation. A test relay should not receive your main identity by accident. Clients and signers should make key choice visible before local auth.

Operators and moderation are easier to name locally

Local relays make responsibility visible. Someone knows the community. Someone understands what kinds of events belong. Someone can explain moderation. Someone can decide whether archival storage matters. That can be healthier than pretending a global public relay should serve every context equally.

The risk is capture. A local relay can become a gate if client design hides alternatives or if the operator treats the room as identity ownership. Good local Nostr design keeps public identity visible, lets people export or republish what matters and explains which events are local-only. The relay can govern the room without owning the person.

Moderation should match the room. A family archive may need almost no moderation and strong privacy. A conference room may need spam control, session rules and a visible staff key. A public venue relay may need legal compliance, harassment response and event-kind limits. A team relay may need admin roles and audit history. A NIP-29 group may need moderators, admins and group state. Different rooms need different rules.

Publish those rules in ordinary language. Who can write? Who can read? Who moderates? What is retained? What is mirrored publicly? What happens when someone leaves? What happens after the event ends? What happens if the relay shuts down? If the room has social consequences, the relay policy should not be hidden in code.

Local operators should also test failure. What happens when internet access drops? Can people still use a LAN or device-local relay? What happens when the operator laptop sleeps? What happens when the venue Wi-Fi changes? What happens when the relay database fills? Local failures are often physical and boring. That makes them easier to test if you do it before the room is full.

Clients have to show the local boundary

Local relays fail as products when clients make them invisible. If a note is local-only, the client should say so. If a relay is private, the client should say so. If auth is required, the client should explain which relay asks and why. If a group is NIP-29, the client should show group context, roles and moderation state. If a venue announcement is mirrored to public relays, the client should show that it left the room.

Users should not need to understand every NIP to avoid mistakes. A good client can translate: "This post goes only to the conference relay." "This staff note stays in the private venue room." "This announcement will also publish to your public write relays." "This relay rejected your key because you are not a member." "This local relay is offline; your public relays are still connected."

Discovery matters too. If a person arrives at a venue, how do they find the relay? QR code, NIP-65 list from the venue key, NFC tag, Wi-Fi landing page, website, event app, printed sign, calendar event or shared note? The relay URL should not be a secret pasted in a chat. A local room needs a doorway people can actually use.

Leaving matters as well. If someone leaves a group or event, can they remove the relay cleanly? Do old local notifications stop? Does the client update relay roles? Can they keep public posts elsewhere? Can they revoke auth? Can they rotate a key? Local UX should make exit feel normal, not hostile.

The best local client experience feels like entering and leaving rooms. You know where you are, who runs it, what stays inside and what travels with you.

Design one without overbuilding

Start with one sentence: this relay remembers X for Y people in Z context. For example: this relay remembers session questions for conference attendees during the event. This relay stores family notes for household members. This relay carries venue announcements and member RSVPs. This relay backs up my own notes on my phone. This relay handles group chat for a project team. The sentence will tell you what not to build.

Then choose access. Public read with restricted write? Private read and write? Member-only write with public announcements? Device-local only? LAN-only? Tor? Tailscale? Paid admission? NIP-42 auth? NIP-43 admission? NIP-29 group roles? Access is the room's social contract, not a technical afterthought.

Choose retention. Live only? One week? Event archive? Permanent family archive? Rolling operational log? Minimal wallet message retention? Write it down. Then choose backup. If losing the relay would hurt, backup matters. If retaining the data would hurt, deletion matters. Local systems need both memory and forgetting.

Choose clients. A relay nobody's client can use is not a room. Test with the actual clients your people have. Test mobile networks. Test bad Wi-Fi. Test authentication. Test read and write. Test leaving. Test a non-member. Test a restart. Test a second device. The boring tests are the ones that make the local room feel trustworthy.

Finally, publish metadata. NIP-11 should tell people what the relay is, who runs it, which NIPs it supports, what limits exist and how to contact the operator. If the relay is local, say local. If it is private, say private. If it is temporary, say temporary. The door sign is part of the experience.

Three local architectures cover most needs

The simplest architecture is personal local-first. A phone, laptop, home server or small node runs a relay mainly for one person or one household. It may sync with public relays, but its first job is keeping a nearby copy and making your own apps feel consistent. This is where Citrine, Relay Tray, Umbrel-style hosting or a small nostr-rs-relay setup can make sense. The operator and user are often the same person, so the biggest risks are backups, device loss, accidental exposure and stale relay lists.

The second architecture is community room. A club, meetup, class, family, team or project runs a relay with a known membership boundary. It may be readable by everyone and writable by members, or it may be private on both sides. NIP-42 auth, NIP-43 admission metadata and NIP-29 group semantics become useful here. The core questions are social: who enters, who moderates, what gets archived, what remains local and how members leave. The relay is a community tool, not just a server.

The third architecture is venue operations. A hotel, cafe, coworking space, resort, event space or conference uses a relay as part of the physical experience. Public announcements, local offers, schedules, staff channels, badge state, bookings, reputation and wallet-adjacent messages can all touch the relay layer. This is the most operational version. It needs uptime expectations, staff training, incident routines, monitoring, backups, privacy rules and a clear split between public, member-only and staff-only events.

You can mix these architectures, but you should not blur them. A phone-local relay does not need the same policy page as a venue relay. A venue relay should not be operated with the casual habits of a personal test endpoint. A community relay should not silently become a wallet transport. Once the architecture is named, the decisions become smaller and saner.

The architecture also tells you what "failure" means. If a personal relay is offline, you may lose convenience. If a community relay is offline, members may lose coordination. If a venue relay is offline during an event, staff may lose operations and guests may lose trust. Same protocol, different consequence.

A local operations routine keeps the room alive

If you operate a local relay for other people, create a tiny routine before the room depends on it. Check that the relay starts after reboot. Check that NIP-11 is reachable. Check that the advertised relay URL is the URL clients actually use. Check that TLS works if the relay is public. Check that DNS is stable. Check that backups run. Check that disk space is not quietly disappearing. Check that the operator key, contact field and policy text are current.

Then test the social flows. Can a member join? Can a non-member fail cleanly? Can a moderator remove or reject what they need to reject? Can a staff account publish an announcement? Can a normal attendee read it? Can a person leave? Can the relay survive a bad Wi-Fi moment? Can a second client read the same event? Can someone find the relay without asking you personally for the URL?

Monitoring should be local-aware. Public NIP-66 monitors may not see a private or LAN-only relay. That does not mean the relay is unhealthy. It means you need your own checks. For a venue, run a local heartbeat. For a team, test from the actual VPN or private network. For a phone-local relay, check app-level availability. For a public local relay, use external monitors too, because outsiders need to know whether they can connect.

Incident language matters. If the relay goes down during an event, what do people see? "Local room unavailable, public relays still connected" is useful. Silence is not. If a private relay rejects a key, say whether it is membership, auth, payment or policy. If retention is short, warn before deletion. If a temporary relay is about to shut down, announce the archive plan before the event ends.

Security boundaries should be explicit. Do not run staff operations, public announcements, wallet messages and attendee chat through one undifferentiated policy unless the consequences are genuinely the same. A public venue relay may be fine for announcements and bad for internal notes. A private relay may be fine for staff and bad for public discovery. A wallet-adjacent relay may deserve separate keys, shorter retention and stricter monitoring. The local label should never hide several risk levels inside one friendly word.

Physical access is another boundary. If the relay sits on a venue network, who can reach it from guest Wi-Fi? If it is LAN-only, can visiting clients still connect? If it uses a cloud endpoint, is it truly local or only place-branded? If it runs on a phone or laptop, what happens when that device leaves the room? Local infrastructure is always half social and half physical.

Hand the routine to a non-technical operator before launch. If only the builder can tell whether the relay is alive, the room is fragile. A venue manager, host, moderator or team lead should know where status lives, who to contact, which client screen proves the relay works and what fallback to announce when it does not. Local reliability is a staff habit, not only a server setting, and the habit has to survive weekends, shifts and tired event nights.

Finally, write down ownership. A local relay without a named operator becomes abandoned infrastructure. Who pays? Who updates? Who backs up? Who can restore? Who can change policy? Who can remove content? Who can hand over control when a venue manager, club lead or technical volunteer leaves? Local infrastructure feels friendly until nobody knows who owns the keys.

One more operational detail is easy to underestimate: teach the room what the relay is allowed to forget. Local does not automatically mean permanent. A retreat relay may only need memory for a weekend. A club relay may need a year of member records. A hotel relay may need public events to expire quickly while staff notes stay private and short-lived. If you explain retention in ordinary language before people publish, you reduce anxiety later. People can use a local room with more confidence when they know whether it behaves like a bulletin board, a logbook, a private staff desk or a temporary event wall.

The practical verdict

Local relays are where Nostr becomes intimate enough for real places. They let a global protocol support local memory without turning every club, home, team, venue or event into a closed app. Used well, they give rooms digital continuity while keeping identity portable.

They are also easy to misuse. A local relay can become a hidden silo if clients hide boundaries. It can become surveillance if retention is careless. It can become fragile if nobody operates it. It can become gatekeeping if membership rules are opaque. Local power needs local honesty.

The sane pattern is layered. Use public relays for public reach. Use local relays for local context. Use private relays for private rooms. Use paid relays when service accountability matters. Use home relays for personal custody. Use NIP-65 lists so clients know where to look. Use NIP-11 so humans know what the relay is. Use NIP-42 and NIP-43 when doors need proof and admission. Use NIP-29 when the room is a group.

If you design the room clearly, the local relay stops feeling like a mysterious server. It becomes what it should be: a place where Nostr events belong because the people, context and consequences are local, visible and easy to explain before anything breaks under real pressure.

Sources worth opening

Open these when you want standards, software and concrete local-relay patterns behind the page.

Useful next pages

Back to Relays