User verification with kick for open groups

[daopunk]

Summary

Optional group mode: new joiners must complete a DM handshake with Bread Bot before they may stay in the group. Unverified joiners are kicked. Verification is stored on the live CVM (encrypted prefs volume), so it survives in-place upgrades and applies across groups that enable the mode.

This is the only Signal-shaped slice of the broader gated-entry request in #40. It is a bouncer, not a restricted role and not proof-of-humanity.

Why this shape

Signal groups have two roles: member and admin. There is no mute, no pending-in-group role, and no hold channel. Send permission is group-wide (everyone, or announcement-only). So we cannot “let them in but block posting” until they pass a check.

What Signal can do, if the bot is a group admin:

• Kick (remove_members — already used for Language Thread !leave)
• DM a challenge and accept a text reply
• Persist a verified-identity set on group-prefs-translation

Native group link + require admin approval is still the stronger gate (they never see the chat). This issue is for groups that want to keep the invite link open and bounce strangers automatically.

Proposed behavior

Happy path (preferred):

1. User DMs the bot and completes the handshake before joining.
2. Group description / kick copy points at that: “DM Bread Bot, then join.”
3. They join an !only-registered group; the bot sees a known UUID and does nothing.

Cold join:

1. A group admin enables the mode (command name TBD; must not collide with TEE !verify).
2. Current members are grandfathered. Only identities that appear after the flag flips are gated.
3. Bot detects a new member (poll GET /v1/groups and diff members; signal-cli has no reliable join event).
4. If unverified: DM them while they are still in the group (shared group helps the message request), then kick.
5. Post one short group line, rate-limited per identity (e.g. once per hour): <name> is unregistered — DM the bot, then rejoin.
6. Do not paste phone numbers into the group. Prefer profile name; fall back to a generic “A new member”.
7. On a correct DM reply, persist the Signal UUID (phone as a secondary alias only).
8. They rejoin via the same open link, or the bot add_members them back after unban if we used ban.

Sidecars: do not run the bouncer on Language Thread groups. The bot adds those people from main.

Design decisions (defaults)

Decision	Default	Why
Who can enable/disable	Signal group admins only	Anyone with the command could lock or empty the group
Existing members when enabled	Grandfather	Mass-kick would empty the chat
Identity key	UUID, plus phone alias via existing identities_match	Many envelopes have no E.164
Storage	Global verified set in existing encrypted prefs (group_preferences_store)	Same CVM volume we must not wipe; not a new disk
Join detection	Poll + member diff (invite acceptor already polls every 5s)	signal-cli does not emit a clean “member joined” event
DM vs kick order	DM first, then kick	After kick there is no shared group; the DM looks like spam
Challenge	Rotating text prompt in DM	Signal has no buttons / CAPTCHA UI
Fail / ignore	Stay kicked; they can retry the DM	No per-member mute, no timeout-mute
Kick/rejoin spam	Rate-limit the group announcement; consider ban-until-pass then unban + re-add	Open link means they can rejoin immediately
Command names	Not !verify	!verify is TEE attestation
Product claim	“Completed a DM handshake with Bread Bot”	A scripted signal-cli client can pass a text question

Open (decide in plan, not here):

• Exact command names (!register / !only-registered vs something else).
• Ban-until-pass vs kick-only (ban/unban is not wrapped in the client today).
• Whether a passed handshake auto-re-adds them, or they must tap the invite link again.
• Whether the prompt is global or configurable per group.

Caveats (do not paper over)

• Race: poll/diff means a few seconds of full access. They can post before the kick.
• Bot must be a group admin. On the main Breadchain group it may only be a member; the command should refuse unless Group.admins includes the bot. Sidecars the bot created are fine.
• Message requests: if they have never chatted with the bot, Signal shows a message request. Links are not tappable until they accept. Enough “report as spam” hits can rate-limit or burn the bot phone.
• Not anti-bot. Text (or even an image-captcha attachment) only proves they can complete a 1:1. Do not design a pluggable GateCheck framework for CAPTCHA buttons, wallet signatures, or per-invite-link rules — Signal cannot host those.
• Scope: this is moderation, not translation/transcription. Treat it as an explicit product expansion.
• CVM: in-place deploy only. Do not wipe group-prefs-translation / signal-config-translation.

Out of scope

• Restricted-in-group state, mute, hold channel / “limited thread”
• Telegram-style CAPTCHA buttons, inline keyboards, / command picker
• Per-invite-link rules (Signal has one group link)
• Wallet / signature verification
• Pluggable onboarding-gate framework
• Running the bouncer on Language Thread sidecars
• Reusing or overloading !verify

Origin

Split from #40 (Josh / @BreadrichEngels). #40 remains the place for the broader “gated entry like Telegram” request and the platform limits.

[BreadrichEngels]

This is a design/feedback request on an issue I have standing on (it's split from #40, which Josh and I raised). daopunk wants my input on the scoped-down Signal design. I'll give a substantive design review directly — this reply posts as the single GitHub comment on #44.

---

Thanks for splitting this out — this is the right Signal-shaped slice of #40, and the platform-limits framing is accurate. With only member/admin roles and group-wide send permissions, "admit but restrict" is genuinely impossible, so a DM-challenge + kick bouncer is the only lever Signal gives you. The scope discipline is exactly right too: please keep the "no pluggable GateCheck / CAPTCHA / PoH framework" line — Signal can't host any of it, and "completed a DM handshake with Bread Bot" is the honest ceiling for the product claim. Happy to have #40 stay the home for the broader Telegram-style ask.

Where I'd push on the open decisions:

1. The message-request trap makes cold-join the weak path — design around it, don't lead with it. A stranger who's never messaged the bot receives the challenge as a message request: links aren't tappable until they accept, and DMing-then-kicking means that request arrives with no shared group — maximally spam-shaped, and enough "report spam" hits can rate-limit or burn the bot phone (your highest-cost failure). So make the happy path (DM before join) the primary documented flow, treat cold-join as explicitly degraded/best-effort, and make the cold-join DM one-shot (no retries) to cap spam-report exposure.

2. Reorder cold-join to give a short in-group grace window before the kick. Instead of DM→kick immediately: on detecting an unverified joiner, post the rate-limited in-group line (which they can see, no message-request gate) + send the one-shot DM, then kick only if still unverified after a couple of minutes. It costs a bit more of the "seconds of access" race you already accept, but it uses the channel they can actually see, avoids the kick-then-DM "who is this?" spam shape, and gives an honest user a path that doesn't depend on the DM ever landing.

3. Close the loop with add_members on a passed handshake, rather than "kick and hope they re-tap the link." With an open link, kick-only has an inherent rejoin race and leaves the honest-but-bounced user stuck behind a message request. If a passed handshake triggers add_members back, then the handshake admits them, not link timing. Given ban/unban isn't wrapped today, I'd ship kick-only + re-add-on-pass for v1 and defer ban-until-pass to a follow-up.

4. Command naming: agreed on avoiding !verify (TEE). I'd also keep the handshake verb away from anything attestation-adjacent (!register reads a little that way); gate-flavored names (!gate on/off for the mode) make the bouncer intent obvious. Bikeshed — decide in the plan.

5. Confirm the verified set is bot-global on purpose. As written, passing once trusts you across every group that enables the mode. That's the right simplification (the handshake proves a group-independent "can complete a 1:1 with the bot"), just state it explicitly so nobody expects per-group verification.

Non-blocking: the pre-kick race (seconds of full access) is inherent — fine to accept as documented; it's moot for announcement-only groups but don't rely on that generally. +1 on grandfathering existing members and UUID-primary identity with the phone alias.

Net: right slice, right scope, honest about the limits. My one substantive ask is to make the happy path primary and restructure cold-join around the message-request reality (in-group announce + one-shot DM + grace + re-add-on-pass) instead of DM-then-kick.

[BreadrichEngels]

Privacy / UX note on the open-link + kick approach

Capturing a concern from a discussion with Josh. This isn't a rejection of #44 — it's to make the trade-off explicit so we choose deliberately. Josh will follow up with @daopunk directly; he leans toward the approval-queue variant on UX grounds.

The exposure in the "let them in, then kick" model

Because verification happens after the join (poll + member diff, then DM, then kick), an unverified joiner is a real group member for the length of the race window. During that window they can:

• See the full member list (roster). This is the sharpest issue. Signal group membership is otherwise private — a non-member, even someone holding the invite link, cannot see who is in the group (they only see name/avatar/description and a member count). This approach momentarily hands the entire roster to anyone with the link who chooses to join.
• See and post live messages during the window (the issue already flags this race).

Mitigating detail: Signal does not give new joiners the message backlog, so past conversations are not exposed — the leak is specifically the current roster + any live traffic during the window.

Visible churn

Existing members also see this happen: Signal's "X joined" / "X was removed" system messages, plus the bot's rate-limited announcement line. So the flow is noticeable in-chat, not silent.

The quieter alternative: automate the native approval queue

Instead of leaving the link open and bouncing strangers, turn on Signal's native group link → require admin approval, and have the bot (as admin) auto-approve pending join requests after the DM handshake:

• The requester is never a member until they pass — so they never see the roster, never see live messages, and there is no join/kick churn for existing members.
• Closes the privacy gap above entirely.

Trade-offs to weigh:

• The link is no longer instant-join (requires "require admin approval" on).
• The pending-request queue is readable via signal-cli (listGroups -g <group> -d → pending_requests; approve with updateGroup -m, deny with -r), but there's a known, intermittent visibility bug where requests don't show until a receive runs first (AsamK/signal-cli#1802), and the bot account needs a profile set (updateProfile) or approvals can fail. Worth a hands-on test.
• Note this side-steps the "no reliable member joined event" problem User verification with kick for open groups #44 calls out — the pending-request queue is a separate list, so no member-diff polling is needed for this path.

Both approaches still require the bot to be a group admin (and on the main Breadchain group it may only be a member today, as #44 notes).

Filed via Breadbrich Engels on behalf of Josh.