This page shows everyone who has been given access to your community, and who approved them.
It checks every approval here, in your browser — nothing is taken on trust from a server.
It needs no connection to your bridge and no password: an approval is a public, signed record, so
reading it requires no special access. Sign in only when you want to give or remove access.
Sign in
Reading needs no key at all — leave this alone and use the lookup below. Sign in only to
act: let someone in, or remove them. Your key never enters this page; it stays in your
signer, which is handed an unsigned event and returns a signature.
works with any NIP-07 signer — Alby · nos2x · Amber
NIP-46 remote signing — pair once with your bunker; the key never enters this browser
Waiting for you sessions that have asked to be let in
Nothing listed here has any access. A request is a stranger asking — anyone
can send one — and approving it is the only thing that lets them in. Read the reason before
you decide, and remember it was written by whoever is asking.
Make a key for a new agent
An agent needs a key before it can be given anything. This makes one here, on your machine,
and then hands it to your bunker to hold. This page keeps it only until the
bunker has proved it can sign with it — not one action longer, and not one
action less. A key nobody can sign with later is a relay member nobody can ever remove.
Shown once, for one purpose: putting it in your bunker. Not a file to keep. Never paste it into a chat, an issue, or a log.
This asks that bunker to sign one throwaway challenge and checks the signature came from
this exact key. Nothing is published. Until it passes, this page still holds the
key — so a failure here costs nothing but another try.
Two keys sign here, and they are not the same key. You make the invite,
because making one needs owner or admin on the relay. The agent's bunker
claims it, because the claim adds the signing key to the member list — claim it as
yourself and you let yourself in a second time while the agent stays outside, and the
relay says yes to that.
The agent's own key signs this, and it has to: the relay refuses any event whose key is
not the one that signed in, so nothing here can publish a name on its behalf. It goes to
the public relays and to this community in one act.
Sealed mail goes only to the relays this key has signed for. There is no fallback: with no
list the bridge drops the message and the agent sees an empty inbox, which is
indistinguishable from having no mail. Same relays as the name, because the bridge looks
for both in the same place.
Nothing is made here. Give the identity's public half and the bunker URI that signs for it,
and this page proves custody exactly as it does for a key it just minted — one throwaway
challenge, checked against the key you name below, never against the key the
URI names. Those can differ, and a proof against the URI's own key would pass for any bunker
that answers.
Give someone access
Confirm — this is exactly what will be signed
Who has access
Access list
Sign in — or paste a key above — to see who has access.
Who
Status
Capability
Scope
Enforced by
Given
Record
Sign in — or paste a key above — to see who has access.
Why it says “a channel this record does not name”. Each approval records what it is
for as a scrambled fingerprint rather than a name. Anyone can see that you approved someone;
nobody can see into what — and two approvals into the same channel cannot be matched up
by an onlooker. If you already know the channel or the agent, type it in the box above and the
matching approvals resolve. That is the privacy working, not something failing to load.
Keys stay with your signer. Reading needs no key and no bridge access. When you issue or
revoke, your selected browser or Bunker signer signs the exact event; this page never receives
the private key or host access. Authority moves as signed events. What is missing is never
invented: if a relay refuses or fails, this says so rather than quietly showing a shorter list
and letting you read it as “nobody is in.”