Add gated entry flow for new group chat members

[BreadrichEngels]

Summary

Right now anyone who joins the group chat gets full access immediately. This adds a pending/gated state for new members so the bot can hold them back until they clear some kind of check.

Proposed behavior

• When a new member joins, the bot puts them in a restricted state (can't post, or can only see a limited channel/thread) instead of granting full access right away.
• The bot prompts them with a configurable challenge, starting with: answer a question correctly.
• On a correct answer, the bot promotes them to full member status.
• On a wrong answer, configurable behavior: retry, timeout, or kick.
• If they don't respond within a set time window, configurable behavior: kick, mute, or ping a mod.

Extensibility (worth designing up front)

Frame this as a general "onboarding gate" system rather than a single question-check feature, so future checks can plug in without reworking the flow. Other checks that could live in the same system:

• CAPTCHA-style button click ("I'm not a bot")
• Agree to rules / code of conduct
• Verify a wallet or signature (given the bot's name, a natural fit)
• Manual mod approval
• Invite-link-specific rules (different gate depending on which link was used to join)

Suggested implementation shape

• A PendingMember state tracked per user per group.
• A pluggable GateCheck interface so each check type (question, captcha, wallet verify, mod approval) is its own module.
• Config per group for which check(s) are required and what happens on pass / fail / timeout.

Open questions

• Should multiple checks be chainable (e.g. answer a question AND agree to rules)?
• Should the question/challenge be configurable per group or hardcoded to start?

---

Feature request from Josh. Filed via Breadbrich Engels.

[daopunk]

@BreadrichEngels thanks — we looked at this against what Signal actually supports vs Telegram (and Discord-style) group bots.

Signal is not a bot platform. There is no official Bot API: no command registry, no inline/reply keyboards, no callback queries, no CAPTCHA buttons, no Mini Apps. Bread Bot is a normal Signal account talking through signal-cli. Telegram’s gated-entry bots are built on primitives Signal does not have.

Roles. Signal groups have two roles: member and admin. That is the whole model.

• Send permission is group-wide: everyone can post, or announcement-only (only admins can post). There is no per-user mute, no “pending member who can see the chat but not speak,” and no hold channel / limited thread.
• Language Threads in this project are separate translation groups, not a waiting room.
• Admins can kick (and, in the app, remove-and-ban). They cannot promote someone from a restricted role, because that role does not exist.

So the core #40 flow — join → restricted state → challenge → promote — cannot be implemented as specified. A PendingMember record in prefs can remember that someone is “pending.” The protocol cannot enforce it. They can read and post the moment they are members.

Request-by-request

Ask	Telegram / Discord	Signal	Here
Restricted state / limited channel	Per-user mute, roles, hold chat	Two roles; send is all-or-admins	Not possible
Question, then promote	Yes, while muted	Text Q&A only; they already have full access	Soft check at best
Wrong answer / timeout → kick	Yes	Kick if the bot is an admin	Possible
Timeout → mute	Yes	No per-member mute	Not possible
Timeout → ping a mod	Yes	Bot can mention an admin	Possible
CAPTCHA button	Inline keyboard	No buttons	Not possible
Agree to rules	Button or command	Typed “I agree”	Honor system
Wallet / signature verify	Common on crypto Telegram bots	DM/URL possible; wrong product	Out of scope
Manual mod approval	Bot plugin	Native: group link → Require admin approval	Use Signal settings; no bot needed
Different rules per invite link	Multi-links	One group link	Not possible
Pluggable GateCheck framework	Fits those platforms	Most plugins have no Signal primitive	Do not design up front

What to do instead of a Telegram-parity gate

1. Ops now (strongest, no code): Group link + Require admin approval, and only admins can add members so people cannot skip the queue. Requesters are not in the chat until a human approves. That is manual mod approval.
2. Possible later, as a bouncer not a role system: DM handshake → store the Signal UUID on the CVM → optional group mode that kicks unverified new joiners. Open invite link stays open; they never get a restricted-in-group state. Full caveats and design defaults: User verification with kick for open groups #44.

We will keep #40 as the broader “gated entry” request and the platform limit, and treat #44 as the only slice that is actually buildable on Signal.

[BreadrichEngels]

@daopunk this is the right call — thank you for doing the platform homework the original issue skipped. You're correct on essentially every row. #40 as I filed it (on Josh's behalf) imported Telegram/Discord primitives — per-user mute, restricted-in-group roles, inline-keyboard CAPTCHAs, per-invite rules, a pluggable GateCheck framework — that Signal simply doesn't have. "join → restricted state → challenge → promote" presumes a restricted role that doesn't exist, so it can't be built as specified. No argument.

Agreed on the split: keep #40 as the record of the broad ask + the platform limit, build the Signal-shaped slice in #44. I read #44 — it's a genuinely good spec. Two things I want to make sure land with Josh, because they change what "gated entry" means here:

1. These are two different products, and the choice is Josh's, not an engineering one.

• True gate = native group link + Require admin approval (+ admins-only add). Strangers never see the chat; it's the strongest option and needs no code — it is the "manual mod approval" row. Cost: the link isn't self-serve, a human approves each join.
• Bouncer (User verification with kick for open groups #44) = keep the open link, DM handshake, kick unverified new joiners. Self-serve, but by design there is no keep-them-out state — the poll/diff race means a few seconds of full access before the kick. Fine for "bounce strangers," not for "nobody unvetted ever posts."

They're not substitutes; it's a link-open-vs-closed decision. I'll take that back to Josh, since which one he wants is what determines whether #44 gets built at all or the native setting already satisfies the request.

2. The message-request limitation makes #44's "DM-first" copy load-bearing, not cosmetic. If a joiner has never messaged the bot, the kick-time DM arrives as a message request with non-tappable links, and enough "report spam" can rate-limit or burn the bot number. So the happy path (DM before join, group description pointing at it) is what keeps the bot phone healthy — worth treating the copy and the cold-join fallback as first-class, which #44 already does.

Everything else in #44 reads right: grandfathering existing members, UUID-keyed storage on the existing prefs volume, poll+diff detection, DM-before-kick ordering, not overloading !verify, and explicitly not building a CAPTCHA/GateCheck framework. The caveats section being upfront about the race and the "not anti-bot" reality is exactly what I'd want on the record.

Net: no objection to closing the Telegram-parity framing of #40 as not-possible-on-Signal. I'll relay the closed-link-vs-open-link-bouncer decision to Josh and let his answer drive #44.

[BreadrichEngels]

Done. Handled the sigstack-bot#40 thread and closed the loop.

On the issue: daopunk correctly showed that the gated-entry flow I'd filed for Josh was written against Telegram/Discord primitives (per-user mute, restricted roles, CAPTCHA buttons, per-invite rules, a pluggable gate framework) that Signal simply doesn't have — its group model is only member/admin with group-wide send. I conceded the framing gap, endorsed the #40/#44 split, and engaged substantively with the two things that actually matter in the buildable #44 spec:

• It's two different products, and the choice is Josh's: a true gate (closed link + native "require admin approval", zero code) vs. an open-link bouncer (User verification with kick for open groups #44) that DM-verifies and kicks, with an unavoidable few-seconds exposure window from Signal's poll/diff join detection.
• The message-request limitation makes User verification with kick for open groups #44's "DM-before-join" copy load-bearing (otherwise the bot's kick-time DMs risk spam-reports burning the bot number).

Follow-through: I DM'd Josh (the original requester) the decision he needs to make — closed-link admin approval vs. building the #44 bouncer — since it's a product call, not an engineering one, and offered to route whichever he picks.

No objection to closing the Telegram-parity framing of #40 as not-possible-on-Signal; #44 is the only Signal-shaped slice and it's a solid spec.