| 1 | diff --git a/README.md b/README.md |
| 2 | index 6bf3ebc..a2d31b8 100644 |
| 3 | --- a/README.md |
| 4 | +++ b/README.md |
| 5 | @@ -50,6 +50,8 @@ See [Files and private repositories](docs/files-and-private-repositories.md) for |
| 6 | |
| 7 | See [Git collaboration](docs/git-collaboration.md) for issues, pull requests, conversation synchronization and participant outboxes. |
| 8 | |
| 9 | +See [Membership](docs/membership.md) for invites, joining with NIP-43 and reviewing access requests. |
| 10 | + |
| 11 | See [Rooms](docs/rooms.md) for chat rooms inside a relay, open and members-only access, room administration, connecting Buzz-compatible clients and agents, and the live room stream. |
| 12 | |
| 13 | See [Installed app](docs/app.md) for installing the relay as an app, sharing files to it, opening Nostr links and device notifications. |
| 14 | diff --git a/docs/mcp.md b/docs/mcp.md |
| 15 | index 2349c0b..0d0ee8f 100644 |
| 16 | --- a/docs/mcp.md |
| 17 | +++ b/docs/mcp.md |
| 18 | @@ -70,6 +70,7 @@ Read tools, which need a key that may read the relay: |
| 19 | | `list_jobs` | List long task requests visible to the key with each one's newest feedback status and result. `state` narrows the list to `open`, `done` or `all`; `mine` lists only the key's own requests. | |
| 20 | | `read_job` | Read one long task request by `id` with its feedback timeline and results. | |
| 21 | | `list_callbacks` | List event callbacks with their host, filter, state and last delivery. Members and agents see their own; the owner and moderators see all. | |
| 22 | +| `list_join_requests` | List access requests from people who asked to join without an invite, pending first, with each one's key, reason, time, state and decision, as an owner or moderator. See [Access requests](membership.md#access-requests). | |
| 23 | |
| 24 | Management tools, which follow the relay's roles: |
| 25 | |
| 26 | @@ -88,6 +89,8 @@ Management tools, which follow the relay's roles: |
| 27 | | `revoke_agent` | End an agent's grant and remove its role. | |
| 28 | | `pause_all_agents` | Pause every active agent. | |
| 29 | | `resume_all_agents` | Resume every paused agent. | |
| 30 | +| `approve_join` | Approve an access request by `pubkey`: the key becomes a member and the request is marked approved. | |
| 31 | +| `deny_join` | Deny an access request by `pubkey`. The key stays outside the relay and may ask again. | |
| 32 | | `add_callback` | Register an https URL that receives each new event matching a filter, signed with a secret returned once. See [Callbacks](agents.md#callbacks). | |
| 33 | | `remove_callback` | Delete a callback by id. | |
| 34 | | `pause_callback` | Stop deliveries to a callback until it is resumed. | |
| 35 | diff --git a/docs/membership.md b/docs/membership.md |
| 36 | new file mode 100644 |
| 37 | index 0000000..b4a7b0a |
| 38 | --- /dev/null |
| 39 | +++ b/docs/membership.md |
| 40 | @@ -0,0 +1,33 @@ |
| 41 | +# Membership |
| 42 | + |
| 43 | +A relay's members are the keys the owner admits. The owner and moderators add members on **Manage > People**, members bring in others with invites, and clients that speak [NIP-43](https://github.com/nostr-protocol/nips/blob/master/43.md) join and leave with signed requests. Every change is recorded in the audit log and published as the relay's signed member list. |
| 44 | + |
| 45 | +## Invites |
| 46 | + |
| 47 | +An invite is a code with a lifetime and a use limit. The owner and moderators create one on **Manage > People** or with the `createinvite` management method, which takes the lifetime in seconds, the maximum number of uses and a note. Members may create invites too, within the depth and quota set on **Manage > Rules**; removing a member with `removesubtree` also removes the people they invited. |
| 48 | + |
| 49 | +Share the code as a link: `/invite/<code>` on the relay shows the join terms, if any, and joins the visitor with one signature from their Nostr signer. A claim is a named code created with `createclaim` for the same purpose. `listinvites`, `listclaims`, `revokeinvite` and `deleteclaim` manage them. |
| 50 | + |
| 51 | +## Joining with NIP-43 |
| 52 | + |
| 53 | +A NIP-43 client asks a member's relay for an invite by requesting kind 28935 over an authenticated connection; the relay answers with a signed event that carries a `claim` tag. The invitee publishes a kind 28934 join carrying that claim and becomes a member. A kind 28936 leave removes the key. |
| 54 | + |
| 55 | +The relay publishes its member list as kind 13534 and each admission as a kind 8000 add-user record, both signed by the relay's own key, so clients learn who belongs without a management call. |
| 56 | + |
| 57 | +## Access requests |
| 58 | + |
| 59 | +A kind 28934 join without a `claim` tag is an access request. Clients such as Flotilla send one when a person presses **Request Access**, with the reason in the event's content. The relay accepts it with `OK` and the reason `info: access request received, the relay owner will review it`, keeps the key, the reason and the time, and stores no event. The reason is kept up to 500 characters. A second request from the same key updates the reason and time; it does not add a second entry. A member who asks again is told `duplicate: already a member`, and a banned key is refused with a `restricted:` reason. A join that carries a claim is checked against the invite as before. |
| 60 | + |
| 61 | +Review requests on **Manage > People** under **Access requests**. Each pending request shows the person, the reason and when they asked, with **Approve** and **Deny**. Approving adds the key as a member the same way **Save member** does, so the member list and add-user record follow; denying leaves the key outside the relay, and it may ask again. The last decided requests are listed below the pending ones with their state, and the panel counts the pending ones. |
| 62 | + |
| 63 | +A new request wakes the owner and moderators on their devices in the **approvals** category, once per request, with the asker's short key and reason. Enable device notifications under **Inbox**. See [Installed app](app.md). |
| 64 | + |
| 65 | +The same review is available to agents: |
| 66 | + |
| 67 | +| Method | Tool | Browser tool | |
| 68 | +| --- | --- | --- | |
| 69 | +| `listjoinrequests` | `list_join_requests` | `tiny.list_join_requests` | |
| 70 | +| `approvejoin <pubkey>` | `approve_join` | `tiny.approve_join` | |
| 71 | +| `denyjoin <pubkey>` | `deny_join` | `tiny.deny_join` | |
| 72 | + |
| 73 | +The management methods and tools follow the relay's roles: the owner and moderators may list and decide, and each decision is recorded in the audit log. See [MCP](mcp.md) and [Browser tools](webmcp.md). |
| 74 | diff --git a/docs/webmcp.md b/docs/webmcp.md |
| 75 | index b4deb61..afb164b 100644 |
| 76 | --- a/docs/webmcp.md |
| 77 | +++ b/docs/webmcp.md |
| 78 | @@ -1,6 +1,6 @@ |
| 79 | # Browser tools |
| 80 | |
| 81 | -Every page registers tools for your browser agent; **Manage > Health** reports whether they are ready, and Chrome's Application panel lists them with their calls. The agent can browse repositories, files, issues and pull requests, read chat rooms and threads, list and read wiki pages and merge requests, list the requests that wait for your decision, follow long tasks, inspect service status, manage background jobs, create backups, update relay settings, open Nostr links, the Files page, rooms, wiki pages and the Approvals page, read this device's notification state and, as the owner, send a test notification. Turning notifications on stays a manual step, since the browser asks the person for permission. |
| 82 | +Every page registers tools for your browser agent; **Manage > Health** reports whether they are ready, and Chrome's Application panel lists them with their calls. The agent can browse repositories, files, issues and pull requests, read chat rooms and threads, list and read wiki pages and merge requests, list the requests that wait for your decision, review access requests, follow long tasks, inspect service status, manage background jobs, create backups, update relay settings, open Nostr links, the Files page, rooms, wiki pages and the Approvals page, read this device's notification state and, as the owner, send a test notification. Turning notifications on stays a manual step, since the browser asks the person for permission. |
| 83 | |
| 84 | ## Rooms |
| 85 | |
| 86 | @@ -42,6 +42,18 @@ The owner and moderators can also manage [agent grants](agents.md) through the b |
| 87 | |
| 88 | Each control takes the agent's public key and requests a signature. Signing a new grant stays on the **Manage > Agents** page, since the secret key of a generated agent is shown to the person once. |
| 89 | |
| 90 | +## Access requests |
| 91 | + |
| 92 | +The owner and moderators review [access requests](membership.md#access-requests), the join requests from people who asked without an invite: |
| 93 | + |
| 94 | +| Tool | What it does | |
| 95 | +| --- | --- | |
| 96 | +| `tiny.list_join_requests` | Lists access requests, pending first, with each one's key, reason, time asked, state and decision. Read-only; uses the connected signer. | |
| 97 | +| `tiny.approve_join` | Approves a request by public key. The key becomes a member and the relay's member list follows. | |
| 98 | +| `tiny.deny_join` | Denies a request by public key. The key may ask again. | |
| 99 | + |
| 100 | +Each decision requests a signature and is recorded in the audit log. |
| 101 | + |
| 102 | Four more tools manage [callbacks](agents.md#callbacks), the URLs an agent registers to be woken by new events: |
| 103 | |
| 104 | | Tool | What it does | |