Member-managed contacts: multi-channel digest and participation-opportunity delivery (email, SMS, browser, Telegram)

[zhiganov]

Note (original, Russian)

позволить членам сообщества добавлять свои контакты чтобы не привязывать к одному каналу для оповещений — participation opportunities и дайджесты должны рассылаться не только через вкладку браузера, но и через почту и смс

Translation

Let community members add their own contact details so notifications aren't tied to a single channel. Participation opportunities and digests should be delivered not only via the browser tab, but also via email and SMS.

Why

Today, the ecosystem distributes through narrow per-channel pipes:

• scenius-digest posts to Telegram channels (one-way, per-community).
• my-community / dear-neighbors show participation opportunities inside their browser apps (pull-only, requires the user to open the tab).

A community member who isn't on Telegram, isn't checking the browser tab, or just prefers email is invisible to both pipes. This is especially bad for time-sensitive participation opportunities (avails polls closing soon, scheduled events about to start, harmonica sessions inviting input).

The fix: hold contact details per member on the community-admin side, and let each pipe (digest, participation opportunity, event reminder) fan out across the contact methods the member opted into.

Rough shape (to refine in brainstorming)

A "Notification preferences" surface where each member can:

• Add and verify multiple contacts: email, SMS phone, Telegram handle/chat, (future) push, RSS.
• Per-channel toggles: "send digests to email + Telegram, but participation opportunities to SMS only."
• Per-community toggles where they're a member of multiple (mute one community's digest without disconnecting).

Server side:

• Member contact records keyed to ATProto DID (so the same identity ties a Telegram handle, email, and phone).
• Per-channel verification (email link, SMS code, Telegram pairing — see Citizen-Infra/community-admin#10 for Telegram onboarding pattern).
• Distribution layer: when a digest or participation opportunity is published, look up subscribed members + their preferences, send through each channel they opted into.

Open design questions

• Identity model. Is contact info stored on the member's PDS via a new lexicon, or in community-admin's own Postgres? PDS is more ATProto-pure but cross-community delivery wants a central index. Hybrid is plausible.
• SMS provider. Twilio is the obvious default; Vonage, Plivo, MessageBird are alternatives. SMS has real per-message cost and country/regulatory variability — pick a provider that handles the markets community-admin actually serves and figure out who pays (community? platform? per-member cap?).
• Email provider. Resend is already in the ecosystem (avails, navidrome-jam) — natural fit.
• Verification UX. Email link + SMS one-time-code is standard. Telegram pairing exists in the ecosystem already (Telegram bot onboarding for self-service community registration #10). Browser/push is a separate beast.
• Frequency / batching. Per-channel rate limits matter — SMS once per day vs. Telegram real-time. Probably need a batching layer.
• Opt-in defaults. Conservative default: every channel off; member explicitly opts in. (GDPR/CASL/TCPA-friendly; SMS especially.)

Scope discipline

This is community-admin's job, not avails's, not scenius-digest's, not my-community's. Each of those tools should call into community-admin's distribution API rather than maintain their own contact lists. That's the whole point of community-admin being the shared layer.

Related

• Citizen-Infra/community-admin#9 — the GET /api/config endpoint that consumers already pull from. Could grow a sibling "resolve member contacts" endpoint.
• Citizen-Infra/community-admin#10 — Telegram bot onboarding for self-service community registration. Member-side pairing pattern is similar.
• Citizen-Infra/community-admin#11 — OpenMeet evaluation. If OpenMeet groups become the shared community/membership layer, member contact preferences may live there instead of community-admin proper. Resolve Consider OpenMeet groups as shared community layer instead of building our own #11 first.

Definition of done (high level — refine in brainstorming)

• Members can register and verify ≥2 contact methods (email + Telegram at minimum).
• Distribution API: "publish opportunity X to community Y" → routed to each subscribed member's chosen channels.
• scenius-digest, avails, my-community, dear-neighbors call the same distribution API instead of maintaining their own pipes.
• Per-member opt-out / per-community mute works.