Invites, friends and sharing

This deployment is invite-only: the first user to log in automatically becomes the administrator, and everyone after that has to be invited.

Inviting a new user (administrator)

The Invites page in the navigation bar, which only administrators see, lets you:

generate a one-time invite code — shown once, at the moment you generate it, to pass to your friend;
or pre-register their GitHub username — they sign in to the portal with GitHub and are straight in, no code;
revoke an invite nobody has used yet.

The invited person signs in to the portal with a GitHub account; anyone holding a code redeems it on the page that greets them.

Requesting access

There is a path for people who hold no code: sign in with GitHub, land on the waiting page, and press Request access, optionally with one line of at most 200 characters saying who you are.

one account can have one application waiting at a time; after a decline it waits seven days before asking again, and an approved account never sees the form again;
applications are visible only to administrators, and an applicant sees only their own;
administrators find the queue on the Invites page, and Approve writes an invite for that GitHub username — the same road as pre-registering one by hand, so the applicant is in the next time they open the portal;
an administrator with a notification webhook configured gets an access.requested event.

Adding a friend

Devices and shares are visible only under your own account by default. Working across accounts starts with becoming friends:

on the portal's Friends page, look someone up by exact GitHub username (no fuzzy search, so strangers cannot enumerate users) and send a request;
they accept it on their own Friends page, and you become visible to each other.

Once you are friends, the Shared devices page shares one of your devices with them. A share is not a reduced account: they use the device the way you do. They drive it with wanctl exec --target your-namespace/your-device …, and every request still goes through that device's own mode, rules and approvals — the ones you set. Leave the device on per-request approval and you answer for their commands too; put it in bypass and they are bypassed with you. Elevated commands are never covered by bypass, for them or for you.

One switch separates using the device from running it. Management is off by default: without it a share can work on the device but not touch its approvals, rules or mode, and the device console stays yours. Turn it on when you want someone to answer approvals and change rules themselves — when sharing, or afterwards, without revoking:

wanctl share grant --device DEV --to NS --manage
wanctl share manage --device DEV --to NS on|off

Unbinding the device, renaming it, revoking the share, and your notification settings are never shared, whichever way that switch is set.

Removing a friend cascades into revoking every share in both directions, and they lose access immediately.

邀请、好友与共享

这套部署是邀请制的：第一个登录的用户自动成为管理员，之后的人要被邀请才能进来。

邀请新用户（管理员）

导航栏的「邀请」页（只有管理员能看到）可以：

生成一次性邀请码——只在生成那一刻显示一次，发给朋友；
或者预录对方的 GitHub 用户名——对方用 GitHub 登录门户就直接进来，不用码；
撤销还没用掉的邀请。

被邀请的人用 GitHub 账号登录门户，有码的在提示页里兑换即可。

申请访问

没有邀请码的人也有一条路：用 GitHub 登录，落在等待邀请页上，点「申请访问」，可以附一行不超过 200 字的说明。

一个账号同时只能有一份申请在等；被拒之后要等 7 天才能再提，已获准的不再看到这张表单；
申请只有管理员看得见，申请人只看得见自己那一条；
管理员在「邀请」页看到队列，「通过」就是给这个 GitHub 用户名建一条邀请 —— 跟手动预录是同一条路，对方下次打开门户就进来了；
配了通知 webhook 的管理员会收到一条 access.requested。

加好友

设备和授权默认只在自己名下可见。要跨账号协作，先加好友：

门户「好友」页按 GitHub 用户名精确查找（不能模糊搜索，防止陌生人枚举用户）并发请求；
对方在自己的「好友」页接受后，互相可见。

共享设备

好友关系建立后，在「共享授权」页把某台设备共享给对方。共享不是一个降级的账号：对方使用这台设备的方式和你一样。对方用 wanctl exec --target 你的namespace/设备 … 控制它，每一次请求仍然要过这台设备自己的模式、规则和审批——也就是你设的那一套。设备留在逐条确认，对方的命令也由你来批；设备开了 bypass，对方跟着一起放行。提权命令无论对谁都不在 bypass 覆盖范围内。

「用这台设备」和「管这台设备」之间只隔一个开关。管理权默认关闭：不开的话，对方能在设备上干活，但碰不到审批、规则和模式，设备控制台仍然只属于你。想让对方自己批审批、自己改规则时再打开——共享时就带上，或者事后单独改，不用撤销重来：

wanctl share grant --device DEV --to NS --manage
wanctl share manage --device DEV --to NS on|off

无论这个开关怎么设，解绑设备、给设备改名、撤销共享，以及你的通知设置，都不在共享范围内。

删除好友会级联撤销双向的全部共享授权，对方立刻失去访问。