Per-bridge review checklist

Research notes. Engineering's reading of the Signal and Telegram terms. Not legal advice and not a policy.

RESEARCH NOTES, NOT LEGAL ADVICE. Engineering's reading of public terms and documentation on 30 September 2026, to give counsel a head start. Quotes and paraphrases are from the linked pages as fetched that day; terms change, so re-read the source before relying on any line. Nothing here is a conclusion that a bridge may lawfully or contractually be offered.

Our bridge policy: before launch, each bridge gets a current terms-of-service review, account-registration analysis, abuse controls, credential and session security review, and commercial-hosting review. Our roadmap puts "Bridge terms review and validation" in January-February 2027, before Gate 2.

Checklist (one copy per bridge, per review)

#	Item	Owner	Status
1	Terms of service review: current consumer terms and developer/API terms of the remote service read in full; clauses on third-party clients, automation, commercial use, resale, data use listed with quotes; counsel's opinion recorded	Counsel + eng	Research notes below; counsel not started
2	Account-registration analysis: do we create, register or verify remote accounts? Can the bridge register accounts? What makes a remote service treat an account as suspicious?	Eng	Notes below
3	Abuse controls: how we prevent our service being used for spam or automation against the remote network, and how we respond to a report	Eng + ops	Implemented in config, runbook drafted
4	Credential and session security: what the bridge stores, where, encrypted how, who can reach it, how the subscriber sees and revokes it	Eng	Notes below; disk encryption open
5	Commercial-hosting review: software licences (AGPL) and obligations when offering the bridge as a paid network service; precedent; trademark use in product naming	Counsel + eng	Notes below
6	User-facing disclosure: onboarding and privacy policy say plainly that bridged chats are not end-to-end encrypted through our server	Product	Draft in `privacy-policy-DRAFT.md`
7	Kill switch: we can disable one bridge for everyone within an hour (stop the container, notify subscribers) if a remote service objects	Ops	`docker compose stop mautrix-<bridge>`; runbook entry needed
8	Re-review trigger: re-run items 1, 2 and 5 on any remote terms change, any mautrix major release, and yearly	Owner of bridge policy	Not scheduled

Signal (mautrix-signal)

Software: mautrix-signal v26.09 (dock.mau.dev/mautrix/signal:v0.2609.0), Go bridgev2, AGPL-3.0, uses libsignal (AGPL-3.0). Docs: https://docs.mau.fi/bridges/go/signal/ ; source: https://github.com/mautrix/signal

1. Terms (https://signal.org/legal/, "Terms of Service", effective date shown on the page: 25 May 2018)

"You agree to use our Services only for legal, authorized, and acceptable purposes." Prohibits "bulk messaging, auto-messaging, and auto-dialing".
Under harm to Signal, users must not "gain or try to gain unauthorized access to our Services or systems", "create accounts for our Services through unauthorized or automated means", or "sell, rent, or charge for our Services".
Third-party services: the terms say third parties' own terms govern use of third-party services; they do not, as fetched, address third-party client software explicitly.
Issues for counsel: (a) whether a paid hosted bridge is "charging for our Services" when what is sold is the Matrix service and the subscriber uses their own Signal account; (b) whether acting as a linked device from a server is "authorized" access; (c) whether our server, rather than the user, is the party bound by or in breach of the terms. Public precedent: Beeper and several free public instances run mautrix-signal (mautrix docs list beeper.com and tchncs.de); precedent is not permission.

2. Account registration

We never create Signal accounts. The bridge only links as a secondary device ("Registering as the primary device is no longer supported directly in the bridge", mautrix-signal authentication docs, https://docs.mau.fi/bridges/go/signal/authentication.html). The subscriber scans a QR code with their existing Signal phone app.
Signal support documentation (via search results, the support site returned 403 to our fetcher): the primary phone must come online at least every 30 days or linked devices are unlinked, and a linked device unlinks after 45 days of its own inactivity (https://support.signal.org/hc/en-us/articles/360007320551). The app should warn subscribers when the bridge reports a logged-out state.

3. Abuse controls (implemented)

Only licensed accounts on our homeserver can use the bridge (bridge.permissions: our server user, everyone else block); registration is closed.
Relay mode off: one subscriber's account never speaks for other Matrix users.
No bulk features exposed; Synapse message rate limits apply to what the subscriber sends into the bridge. Open: add a per-subscriber daily cap on new Signal conversations started via the bridge, if the provisioning API is exposed to the app.
Abuse runbook: internal, drafted.

4. Credentials and sessions

Stored: linked-device identity keys, sessions, pre-keys, profile keys, group state, recipient records (Signal ids and phone numbers of contacts), in the mautrix_signal PostgreSQL database (tables signalmeow_*, seen in our local test). Not encrypted at the application level; database reachable only on the cell's internal network; included in encrypted backups.
Anyone holding these can read the subscriber's future Signal messages and send as them until the device is unlinked. Controls: separate database role, no public ports, backups encrypted to an offline key, deprovisioning unlinks. Open: VPS disk encryption.
Visible to the subscriber as "Shoal Messages (hosted bridge)" in Signal's linked devices list (network.device_name), where they can unlink it.

5. Commercial hosting

mautrix-signal is AGPL-3.0. Offering it over a network to subscribers means that if we modify it we must offer those users the corresponding source (AGPL section 13). We run unmodified upstream images; we will still publish the exact image references and a source link. LICENSE.exceptions grants extra rights only to Beeper and Element; we rely on the AGPL itself.
Its README-level note: "mautrix-signal depends on libsignal, which is also licensed under the AGPL. A license exception for libsignal must be acquired separately from Signal." (from LICENSE.exceptions in the repository). Relevant only if we ever distributed it under other terms; we do not.
Naming: do not use Signal's name or logo in product names; describe compatibility nominatively ("connects to your Signal account").

Telegram (mautrix-telegram)

Software: mautrix-telegram v26.09 (dock.mau.dev/mautrix/telegram:v0.2609.0), now a Go bridgev2 bridge (the Python bridge is legacy), AGPL-3.0. Docs: https://docs.mau.fi/bridges/go/telegram/ ; source: https://github.com/mautrix/telegram

1. Terms

Telegram has separate API terms (for developers) and user terms.

API terms (https://core.telegram.org/api/terms), as fetched:

Privacy and security: "All client apps must, therefore, guard their users' privacy with utmost care and comply with our Security Guidelines."
"It is forbidden to interfere with the basic functionality of Telegram. This includes but is not limited to: making actions on behalf of the user without the user's knowledge and consent, preventing self-destructing content from disappearing, preventing last seen and online statuses from being displayed correctly, tampering with the 'read' statuses of messages (e.g. implementing a 'ghost mode'), preventing typing statuses from being sent/displayed, etc."
Data may not be used "to train, fine-tune or otherwise engage in the development, enhancement or deployment of artificial intelligence, machine learning models and similar technologies".
Transparency: developers must obtain their own API ID; users must be told prominently (store listing and in-app) that the app uses the Telegram API; app titles may include "Telegram" only preceded by "Unofficial"; the Telegram logo may not be used.
Enforcement described as a notice period to fix issues before API access is discontinued.

User terms (https://telegram.org/tos): prohibit spam and scams; breaches can lead to temporary or permanent bans. Separate bot terms exist.

How our configuration responds (for counsel to assess):

API-terms point	Our setting or plan
Own API ID	`TELEGRAM_API_ID`/`TELEGRAM_API_HASH` from our own my.telegram.org application; one application for the service
Actions only with the user's knowledge	The subscriber logs in themselves; no automated sending; relay off
Self-destructing content	Disappearing messages: bridgev2 tracks timers (`disappearing_message` table) and removes them on Matrix end to end; view-once media not bridged (`disable_view_once: true`); retention further limits server copies
Read and typing statuses	Bridged both ways by default in bridgev2; never suppress them
No AI training	We do not; add to our terms
Transparency and naming	Onboarding must say "uses the Telegram API"; never "Telegram" in the product name; device shown as "Shoal Messages (hosted bridge)"

2. Account registration

mautrix docs: "Telegram officially discontinued registration from 3rd party clients as of 2023-02-18, so support for it was removed in v0.13.0 of the bridge." Subscribers must already have an account from an official app.
mautrix docs warn: "Telegram is known to ban suspicious users, and a brand new account using a 3rd party client is considered suspicious", and that Telegram "usually reverts incorrect bans fairly quickly after emailing recover@telegram.org" (https://docs.mau.fi/bridges/go/telegram/authentication.html). Onboarding should advise against linking brand-new accounts, and support should know the appeal route.
Login methods: phone number plus code delivered to an existing Telegram client, or QR code from Settings, Devices; two-step verification password if set.

3. Abuse controls

As for Signal (permissions, relay off, closed registration), plus: network.sync.create_limit and lazy member sync keep the bridge from mass-fetching data; member_list.max_initial_sync: 0. Open: consider rate limits on bridge-initiated new chats.

4. Credentials and sessions

Stored: the authorised session (auth key) per login and cached access hashes, usernames and phone numbers (telegram_* tables in the mautrix_telegram database). Same protections and open item as Signal.
Visible in Telegram Settings, Devices, as "Shoal Messages (hosted bridge)" (network.device_info.device_model); the subscriber can terminate it there.
A single API ID is shared by all our subscribers' sessions, as with any Telegram client app. If Telegram revokes it, every Telegram bridge on every cell fails at once: treat the API ID as a critical secret and single point of failure.

5. Commercial hosting

AGPL-3.0, same analysis as mautrix-signal.
API terms permit monetisation "through advertising or other legitimate means", disclosed in store descriptions (as summarised by our fetch of the API terms page) exact wording before relying on it.
Precedent: mautrix docs list beeper.com (puppeting) and public instances (t2bot.io, tchncs.de) running Telegram bridges.

Shared components

Component	Licence	Note for commercial hosting
Synapse	AGPL-3.0 (Element relicensed Synapse from Apache-2.0 in 2023) current terms	Network use: publish source of any modifications
mautrix-go (bridgev2)	MPL-2.0 (LICENSE in mautrix/go, checked 2026-09-30)	Linked into both bridges
ntfy	Apache-2.0 and GPLv2 dual licence (LICENSE, LICENSE.GPLv2 in binwiederhier/ntfy)
Caddy	Apache-2.0
PostgreSQL	PostgreSQL licence

Decisions needed before launch

Counsel's opinion on Signal's "sell, rent, or charge for our Services" clause as applied to a paid hosted bridge. If negative, options are: offer the Signal bridge only for self-hosting, make it a free add-on outside the subscription [LEGAL], or drop it.
Counsel's opinion on Telegram API terms compliance of a server-side client shared by many users, and on disappearing-message handling.
Whether to publish the AGPL source links in-app, on the website, or both.
VPS disk encryption decision.
Who owns re-review (checklist item 8), and the calendar for it.

Source: services/privacy/bridge-review.md in the Shipwright repository; paths and ADR numbers in the text refer to it.