Telegram scopes: researched behavior, code gap, and live test

Date: 2026-08-16

Code inspected: /home/liamw/discord-privacy-client, integration/full at 4d13b8a04f48767eb9c72c2432ae9ef01caf814a.

Headline

Telegram protected messaging does not work in any requested scope today: the shipping UI disables Telegram, the native code can place text but deliberately cannot send it, the strip and eye are unconnected helpers, and the checked lifecycle test uses an in-memory fake instead of Telegram Desktop. [integration/full:apps/osl-hub-ui/src/main.ts:1507-1514; integration/full:apps/osl-hub/src/native_telegram_adapter.rs:1-19,496-505; integration/full:apps/osl-hub/tests/task_7762_telegram_protected_carrier.rs:28-65,291-347; 01-FULL-SPEC.md:110-116; TASK 7762]

The first product target should be protected text that really sends, is read back from Telegram, arrives in a second owner-controlled profile where required, decrypts from the persisted carrier row, and can be hidden and shown over that row. Timer, view-once, burn, attachments, forwarding UX, edit UX, provider-entity inspection, classifier stealth, and pixel-perfect carrier imitation should not block that target. They do not prevent harm or a false working-product claim; exact destination binding, exact stored text, independent receive/decrypt, and honest evidence do. [RULING 20(a); RULING D33; RULING D38; 01-FULL-SPEC.md:63-82,110-116,368; TASKS 4093, 7241, 7762]

The common Telegram contract

OSL should encrypt the private text for the exact app/account/conversation scope, put a short pointer into a single-line cover, place that complete cover into Telegram, perform the send trigger chosen in onboarding, and read the stored Telegram row back before saying Sent. The default cover is correctly spelled ASCII words whose choices carry the bits, with single spaces, no URLs, no Markdown punctuation, and no newline. [RULING 20(a); RULING D33; 01-FULL-SPEC.md:63-82,110-114]

The Telegram row remains an ordinary Telegram message. With the eye off, Telegram and every person who can see that chat see the cover text, not the private text. The cover is not promised to look natural: the owner explicitly ruled that a human may recognize every wordbank cover, and the recorded classifier separated current cover from ordinary text 100% of the time. Base encrypted messaging should ship without a stealth claim rather than wait on the classifier; claiming moderation or classifier evasion with the current result would be a lie. [RULING D37; 01-FULL-SPEC.md:9,79-82; Telegram message/entity model: https://core.telegram.org/api/entities]

The strip may sit above Telegram only after OSL has bound the exact Telegram process, workdir, signed-in account, conversation, composer, and row. The eye may replace only OSL-owned pixels over an authenticated row and must restore the cover when closed; it must never edit the Telegram message. This is the intended contract, not a capability proved by the current code or design. [01-FULL-SPEC.md:63-82,110-116; integration/full:apps/osl-hub/src/native_telegram_adapter.rs:700-720; TASK 7762]

Breakage shared by all five scopes

• Length. Telegram publishes the maximum as the runtime message_length_max, counted in UTF-8 codepoints; Telegram's official issue tracker says the ordinary limit is currently 4,096 Latin characters and official apps split longer pasted text. Canonical OSL instead caps the carrier at 4,096 UTF-8 bytes, so multibyte text gets a smaller limit and an overlong value may become multiple rows. The default short ASCII word-choice cover is far below either ceiling. Do not advertise a Telegram limit until the installed client has been measured at N and N+1; do not block the first default-cover send/decrypt on the full boundary matrix. [Telegram config: https://core.telegram.org/constructor/config; Telegram issue 1423: https://bugs.telegram.org/c/1423; integration/full:apps/osl-hub/src/native_telegram_adapter.rs:47,832-838; RULING D33; TASK 7232]

• Formatting. Telegram carries message text separately from formatting entities and automatically creates entities for URLs, mentions, hashtags, email addresses, bot commands, and similar strings. D33's default alphabet emits none of those and no Markdown punctuation, so rich carrier formatting is unnecessary for protected cover. Exact stored text and receiver decrypt are the base gate. TASK 7241's provider-entity inventory is useful follow-up evidence, but it should not block the first working path when the cover contains no entity-triggering text and no preview appears. [Telegram entities: https://core.telegram.org/api/entities; RULING D33; TASK 7241]

• Link previews. Telegram can attach webpage-preview media to URL text. Default OSL cover contains no URL or domain, so a preview should never appear. Canonical code has no preview suppression or detection; if a default cover produces a preview, the send must fail readback instead of being called successful. [Telegram preview API: https://core.telegram.org/method/messages.getWebPagePreview; RULING D33; integration/full:apps/osl-hub/src/native_telegram_adapter.rs:163-176; TASK 7241]

• Forwarding. Telegram permits forwarding unless chat content protection is enabled. A carrier-native forward moves the old cover into a new conversation and therefore must not decrypt under the old scope; an OSL Forward should decrypt locally and create a fresh destination-bound transaction. TASK 3954's requirement that a native-forwarded old cover open as the private words conflicts with the higher-authority scope-binding spec and should be cut. Forwarding support should not block base send/decrypt. [Telegram content protection: https://core.telegram.org/api/content-protection; 01-FULL-SPEC.md:63-82; TASK 3954]

• Edits and edit history. Telegram marks edited messages and uses a runtime edit-time limit. Any one-character cover edit must invalidate the OSL row and clear any stale plaintext overlay. Telegram stores original versions of edited supergroup messages for 48 hours for admins' Recent Actions; the channel/supergroup admin-log schema contains both old and new messages. Public Telegram material inspected here does not establish prior-version visibility for private chats, basic groups, channels, or Saved Messages, so that is unknown until tested. Edit UX can wait; invalidating changed cover cannot. [Telegram edit announcement: https://telegram.org/blog/edit; Telegram config and edit API: https://core.telegram.org/constructor/config and https://core.telegram.org/method/messages.editMessage; Telegram privacy section 10.2: https://telegram.org/privacy; admin-log edit schema: https://core.telegram.org/constructor/channelAdminLogEventActionEditMessage; TASK 3953]

• Newlines. Private plaintext may contain newlines because it is encrypted before cover generation, but the Telegram cover may not contain CR or LF. The universal selected trigger applies to Telegram, and a newline can commit a partial carrier before placement finishes. This guard prevents a real cleartext/partial-send failure and stays. [RULING 20(a); integration/full:apps/osl-hub/src/telegram_protected_carrier.rs:213-220; TASK 7762]

Scope by scope

1. Private chat

Sending. A protects text for the exact A-account/B-account private-chat scope. OSL generates one single-line cover, places it in A's active B composer, performs the selected send trigger, then reads the exact stored row and its Telegram ID before success. B's isolated OSL copy must decrypt from B's received row, not from A's local send state. [01-FULL-SPEC.md:63-82,110-114; RULING 20(a); TASKS 1012, 4093]

What an onlooker sees. A and B see an ordinary Telegram bubble containing the word-choice cover, plus ordinary Telegram sender/time/edit/forward context. A person without OSL sees only that cover, but may notice that it reads synthetically; OSL must not claim the conversation is hidden or natural-looking. [RULING D37; 01-FULL-SPEC.md:9,79-82; Telegram entities: https://core.telegram.org/api/entities]

Strip and eye. A strip and eye are technically plausible because the native selector can find a composer and exact message-body rectangle. They are not supported today: there is no production Telegram send, receive job, paint backend, or UI wiring. [integration/full:apps/osl-hub/src/native_telegram_adapter.rs:148-177,700-720; integration/full:apps/osl-hub-ui/src/services.ts:558,586; TASK 7762]

What breaks. The shared length, entity, preview, forwarding, edit, and newline rules above apply. A native forward to another chat must show cover only; an edited cover must stop decrypting. Prior private-chat edit-history retention is not established. [RULING D33; TASKS 3953, 3954, 7232, 7241]

2. Basic group

Sending. Protect for the exact Telegram group ID and exact member set, then use the same one-cover placement, selected send, stored-row readback, and independent receive/decrypt path. A direct-chat scope or a generic group label is not enough because membership changes who has the carrier row and which OSL keys should open it. [01-FULL-SPEC.md:63-82; TASKS 0169, 1026, 7762]

What an onlooker sees. Every group member with access to the history sees the cover under the Telegram sender identity. A member with OSL and the right group key may reveal the private text locally; an unapproved member sees the cover. The live safety test should use only owner identities A and B rather than adding an outsider to prove the negative. [TASK 0169; RULING D38; Telegram group model: https://core.telegram.org/api/channel]

Strip and eye. The same geometry could work if OSL proves the group, sender row, and member scope. Current concrete code collapses Telegram places to DirectChat, Group, or Channel for reading and has no participant-set/group-key route; its protected abstraction models only one sender and one receiver. Overlay support is therefore unproved and not implemented. [integration/full:apps/osl-hub/src/services.rs:356-375,1802-1823; integration/full:apps/osl-hub/src/telegram_protected_carrier.rs:31-49; TASK 1026]

What breaks. Member changes, sender attribution, replies, edits, forwarding, split rows, and entity/preview geometry all need live observation. Basic-group prior edit-history exposure is not established. Prove basic group separately from supergroup; Telegram represents them differently and can migrate one into the other. [Telegram group/supergroup model: https://core.telegram.org/api/channel; TASKS 1026, 1027, 3953, 7241]

3. Supergroup

Sending. Use a distinct supergroup scope with the exact supergroup ID, member set, and actual send_as identity. Telegram models supergroups as channel objects, supports up to 200,000 members, and may send as the user, an owned channel, or the group depending on rights. A basic-group pass does not prove this path. [Telegram channel/supergroup model: https://core.telegram.org/api/channel; TASKS 0147, 1027]

What an onlooker sees. Members with history access see the cover. The visible author may be A, a channel, or the group; admins may also see the original and edited cover in Recent Actions for 48 hours. No private plaintext should ever enter Telegram or its admin log. [Telegram channel/supergroup model: https://core.telegram.org/api/channel; Telegram privacy section 10.2: https://telegram.org/privacy; RULING D38]

Strip and eye. The generic row rectangle is a useful base, but OSL must bind the supergroup and send_as identity rather than trusting the text or window title. Current backend place reading has no Supergroup variant, the UI's ordinary kind union omits it, and no live strip/eye path exists. [integration/full:apps/osl-hub/src/services.rs:356-375; integration/full:apps/osl-hub-ui/src/telegram-whitelist-controls.ts:12-19; integration/full:apps/osl-hub/src/native_telegram_adapter.rs:700-720; TASK 1027]

What breaks. Posting rights, slow mode, send_as, migration from a basic group, edits in Recent Actions, forwarding, previews, and split messages can all change the row or attribution. Base support should cover the ordinary A-as-A case first; other sender modes can be added after one real supergroup send/decrypt works. [Telegram channel/supergroup and rights docs: https://core.telegram.org/api/channel and https://core.telegram.org/api/rights; TASKS 1027, 3953, 7241]

4. Channel

Sending. A must be the channel owner or an admin with post permission. OSL protects for the exact channel and posting identity, places and sends one cover, reads the stored channel post, then B reads as a subscriber. A channel comment belongs to its linked discussion group and is not a channel-post test. [Telegram channel and rights docs: https://core.telegram.org/api/channel and https://core.telegram.org/api/rights; TASKS 0147, 1027]

What an onlooker sees. Subscribers see a channel-branded cover by default, with time and view count; optional signatures or profile mode can expose the posting admin identity. Tests must use a private channel containing only owner identities A and B. A real public post is forbidden. [Telegram channel docs: https://core.telegram.org/api/channel; Telegram channel FAQ: https://telegram.org/faq_channels; RULING D38]

Strip and eye. A's strip needs a writable channel composer and a proved posting identity; B's eye needs the exact persisted subscriber-side row. The composer matcher was widened for channel variants and the generic backend knows a Channel read shape, but there is no role check, send, receive, or overlay wiring. [integration/full:apps/osl-hub/src/native_telegram_adapter.rs:148-177; integration/full:apps/osl-hub/src/services.rs:356-375; TASK 1027]

What breaks. Anonymous versus signed/profile posting changes attribution; edits enter the channel admin log schema; previews and forwarding change geometry/context; subscribers cannot perform the reverse send. Prove one-way A-admin to B-subscriber first. Public-post coverage is not needed and must not be attempted on the owner's accounts. [Telegram channel and admin-log docs: https://core.telegram.org/api/channel and https://core.telegram.org/api/recent-actions; RULING D38; TASK 1027]

5. Saved Messages

Sending. Saved Messages is Telegram's private chat with inputPeerSelf and acts as personal cloud storage. OSL needs a self-scope: A protects, sends the cover to A's Saved Messages, discards transient plaintext state, then decrypts again from the persisted self-chat row. This is the one-party case, not a fake two-party transaction. [Telegram Saved Messages: https://core.telegram.org/api/saved-messages; TASKS 0147, 1028]

What an onlooker sees. The cover syncs to A's Telegram sessions. There is no B recipient, but anyone looking at A's screen or another signed-in A session sees the cover. Forwarding an existing message into Saved Messages also retains source metadata and receives a new message ID, so direct self-send and forwarded-save are different cases. [Telegram Saved Messages: https://core.telegram.org/api/saved-messages; TASK 1028]

Strip and eye. The same composer/row overlay is plausible in principle, but canonical code cannot do it: the backend place enum has no Saved Messages variant, the only Saved Messages UI is an unimported markup helper, and TelegramProtectedCarrier rejects equal account IDs and equal workdirs. A specific self-scope must be built. [integration/full:apps/osl-hub/src/services.rs:356-375; integration/full:apps/osl-hub-ui/src/telegram-whitelist-controls.ts:127-167; integration/full:apps/osl-hub/src/telegram_protected_carrier.rs:335-365; TASK 1028]

What breaks. Sender-side plaintext cache is the main false pass. The decrypt must still work after OSL's transient state is gone. Length, entities, preview, edits, and forwarding metadata also apply; prior Saved Messages edit-history retention is not established. [TASKS 1028, 3953, 7232, 7241]

What canonical code supports today

Shipping result

The shipping UI allows only Discord as a native carrier. Telegram may appear as installed, but its catalog row says protectedMode: "unavailable", supportsOverlay: false, and delivery was never proved live. The Home tile is unavailable for the same reason. [integration/full:apps/osl-hub-ui/src/main.ts:1507-1514; integration/full:apps/osl-hub-ui/src/services.ts:547-565,584-590]

The native host can launch an isolated Telegram instance with -many -workdir, resolve the Qt accessibility tree, find one composer, put a one-line value into it, and read the composer value back. That is useful groundwork, but the file explicitly has no send verb and no path that can commit a Telegram message. [integration/full:apps/osl-hub/src/native_window_host.rs:2798-2847,7317-7338; integration/full:apps/osl-hub/src/native_telegram_adapter.rs:1-19,413-505]

The abstract TelegramProtectedCarrier describes send, exact row, receive/reveal, timer, view-once, and burn, but there is no production TelegramProtectedDriver. Its only implementation is the in-memory Host inside TASK 7762's test. The test stores fake composers and rows in Rust memory, so its checked status cannot prove one Telegram Desktop send or receive. [integration/full:apps/osl-hub/src/telegram_protected_carrier.rs:74-89,203-333; integration/full:apps/osl-hub/tests/task_7762_telegram_protected_carrier.rs:28-65,291-347; 01-FULL-SPEC.md:116; TASK 7762]

The concrete TelegramSurfaceAdapter defines locate, place, commit, and paint interfaces, but has no production TelegramBackend; the only backend implementation is a test fake. The Telegram private-box, eye, and whitelist TypeScript files are not imported by production UI, while the shipping overlay imports and drives Discord paths. [integration/full:apps/osl-hub/src/adapters/telegram.rs:32-44,70-227,240-319; integration/full:apps/osl-hub-ui/src/telegram-private-box.ts:62-116,178-186; integration/full:apps/osl-hub-ui/src/telegram-eye-controls.ts:22-25,62-96; integration/full:apps/osl-hub-ui/src/overlay.ts:1-50]

Scope inventory gap

The kind registries disagree with each other: the auto-whitelist enum has six kinds, allowed_places.rs has five and omits Saved Messages, and the UI ordinary union has four and omits both Supergroup and Saved Messages while special-casing Saved Messages later. That is not five working scopes; it is three disconnected vocabularies. [integration/full:crates/ipc/src/auto_whitelist_rules.rs:200-237; integration/full:crates/ipc/src/allowed_places.rs:483-513; integration/full:apps/osl-hub-ui/src/telegram-whitelist-controls.ts:12-19,127-167; TASK 0147]

The plan and design overclaim

TASKS 1026, 1027, and 1028 only prove fixture/rule/control inspection. TASK 4207 explicitly records that its real Windows supergroup and Saved Messages send/read proof was not measured. TASK 4093 is marked checked even though its evidence says Telegram process count was zero and neither live direction ran. TASK 0148 is also marked checked while its own task note and evidence say the required real Telegram Windows run did not occur. These checked boxes must not be treated as product proof. [evidence/1026.md; evidence/1027.md; evidence/1028.md; evidence/4207.md; evidence/4093.md; evidence/0148.md; TASKS 0148, 1026-1028, 4093, 4207]

The rendered Strip.dc.html is a synthetic carrier mock. Selecting Telegram changes only name, colors, and icon; Telegram reuses the same Discord-like #general, #announcements, avatars, messages, and in-memory eye swap. One proof receipt even hardcodes Discord. It demonstrates the desired strip composition, not Telegram mechanics or overlay feasibility. [design/UI-FINAL-INSTRUCTIONS/Strip.dc.html:107,410,517-573,613-617,828-836; 01-FULL-SPEC.md:116]

The design's “Hold the eye” coach text is void because the owner chose a click toggle. More importantly for working-product-first, exact carrier-style pixels, five-capture color floors, seam rings, and one-pixel mutants should be deferred. Keep structural zero/multiple-composer refusal and exact row anchoring; those prevent a wrong-chat disclosure. Pixel imitation does not prove send/decrypt. [RULING D11; TASKS 5110-5147; design/UI-FINAL-INSTRUCTIONS/Strip.dc.html:421,828-836]

Exact testing workflow

No Telegram action was performed for this report. The workflows below are the proof still required. [RULING D38; 01-FULL-SPEC.md:116; TASK 7762]

Preflight for every run

1. Use only the owner's already signed-in A and B identities. Launch C:\Users\Public\osl-telegram.cmd A and C:\Users\Public\osl-telegram.cmd B. A uses %APPDATA%\Telegram Desktop; B uses %APPDATA%\TelegramB. Do not use C, log in another account, enter credentials/2FA, message another person, or post publicly. [OSL-AUDITS/reference/LOCAL-CARRIER-IDENTITIES.md:20-37; RULING D38; RULING D59]

2. Bind each Telegram.exe by PID resolved from its command-line workdir, never by process name or title. Run two copies of the exact packaged OSL artifact with different OSL data directories, one paired to A and one to B. Record artifact hash, Telegram PID/workdir, OSL data directory, displayed Telegram account identity, and target title before any send. [OSL-AUDITS/reference/LOCAL-CARRIER-IDENTITIES.md:20-37; TASKS 1012, 4093, 7762]

3. Visually confirm the target and membership. A private chat must be A-to-B; a group or channel must contain only A and B; Saved Messages must show A's self chat. Abort on an extra member, ambiguous account, wrong title, or more than one composer. [RULING D38; universal self-healing ruling at RULINGS.txt:129-146; TASK 7762]

4. Before sending, record a fresh run ID and exact private plaintext, its UTF-8 byte length and SHA-256, the expected scope/direction, and zero matching provider rows on the receiving side. Use private text with spaces, punctuation, a newline, and a non-ASCII character to prove plaintext fidelity; the generated carrier must remain short, ASCII, single-line, and URL/Markdown-free. [RULING 20(a); RULING D33; TASKS 4093, 7241]

5. For every sent row record the Telegram provider row ID, exact stored text, whether a preview appeared, author/posting identity, conversation ID, and receiving-side before/after count. Record provider entities when the live reader exposes them, but do not block the base text pass on building a second Telegram API reader solely for that metadata. Reset or restart the receiving OSL copy before reveal so a sender cache cannot supply the answer. [TASKS 3953, 4093, 7241, 7762]

1-party decrypt: Saved Messages

1. On A, open Saved Messages and confirm it is A's self chat. Record zero rows for the fresh run ID. [TASK 1028; Telegram Saved Messages: https://core.telegram.org/api/saved-messages]

2. In A's actual OSL strip, enter the recorded private plaintext, protect it, and use the selected send trigger. [RULING 20(a); 01-FULL-SPEC.md:110-114]

3. Read the persisted Telegram row: exactly one short single-line cover, exact provider ID, no preview, and no private plaintext. Record an empty entity list when available. [RULING D33; TASK 7241]

4. Close and restart OSL A, leaving Telegram history in place. Reopen Saved Messages, select the persisted row, open the eye, and compare revealed UTF-8 bytes and SHA-256 with the precommitted plaintext. Close the eye and confirm the cover returns without editing Telegram. [01-FULL-SPEC.md:79-82; TASKS 1014, 1015]

Proof: the restarted A copy derives the exact private bytes from the persisted self-chat row and the eye toggles that row cover/private/cover. [TASKS 1014, 1015, 1028]

False pass: A reveals from its draft/send cache; a success toast appears without exact plaintext; the cover merely reaches the composer; the row is never sent; the eye swaps fixture DOM text; or the tester manually pastes plaintext into a decrypt box. [TASKS 1012, 4093, 7762]

2-party private chat

1. Confirm A is in the private chat with B in both Telegram profiles. Precommit different A-to-B and B-to-A plaintext markers and zero receiver counts. [TASK 4093]

2. A protects and sends to B through packaged OSL. Record A's stored cover and provider ID. On B, independently read the arrived carrier row, restart B-side OSL, open the eye, and compare exact plaintext bytes/hash. Close the eye and confirm only the cover remains. [TASKS 1012, 4093]

3. Repeat B-to-A with a new marker and provider ID. The two directions must use different Telegram workdirs, OSL data directories, markers, and provider IDs. [TASK 4093]

4. Change one cover character in a test row using only an owner-controlled message. The receiving eye must remove/refuse plaintext, not keep the prior decrypted text. Restore by sending a newly protected message, not by accepting the edit. [TASK 3953]

Proof: both receiver profiles go from zero to exactly one matching private plaintext, after receiver restart, with distinct live provider IDs; each eye shows exact plaintext when open and the exact live cover when closed. [TASK 4093]

False pass: only A's sender copy decrypts; B reads A's workdir or OSL store; both directions use one account; plaintext crosses through clipboard/shared cache; only composer carry or cover arrival is shown; a fixture/action script invents provider IDs; or a green self-test is reported as Telegram proof. [evidence/4093.md; TASKS 4093, 7762]

Group: basic group and supergroup are separate runs

1. Create or select a private owner-only Telegram group containing exactly A and B. Record the provider type before the send; do not call a supergroup a basic group or vice versa. [RULING D38; Telegram group model: https://core.telegram.org/api/channel; TASKS 1026, 1027]

2. Run A-to-B and B-to-A as above with two new markers. Bind each result to the exact group ID, exact member set, sender identity, row ID, stored cover/entities, and receiver restart/decrypt. [TASKS 0169, 4093, 7241]

3. Repeat in a distinct private supergroup with only A and B. Start with ordinary A-as-A and B-as-B posting. If the UI offers send_as, record it and refuse unsupported modes rather than treating the ordinary case as proof of all modes. [Telegram supergroup model: https://core.telegram.org/api/channel; TASK 1027]

4. After the base group pass, edit one cover character and require decryption refusal/stale-overlay removal; native-forward the cover only to A or B's owner-controlled Saved Messages/private chat and require that the old scope does not decrypt there. These are negative follow-ups, not blockers for the first base pass. [TASKS 3953, 3954; 01-FULL-SPEC.md:63-82]

Proof: the opposite owner identity decrypts the exact persisted row in the named group type after restart, in both directions, with the recorded member set and sender identity. A separate pass exists for basic group and supergroup. [TASKS 0169, 1026, 1027, 4093]

False pass: a private A-to-B row is used; group type is guessed from its title; only one direction runs; the group contains another person; sender cache supplies plaintext; an edited row keeps stale plaintext; or a basic-group pass is copied into the supergroup cell. [RULING D38; TASKS 1026, 1027, 3953]

Channel

1. Create or select a private test channel containing only A and B. A is owner/admin with post permission; B is a subscriber with no post permission. Record channel ID, privacy state, administrator/subscriber roster, posting identity mode, and zero B-side marker count. Never use a public channel or add a third account. [RULING D38; Telegram channel/rights docs: https://core.telegram.org/api/channel and https://core.telegram.org/api/rights]

2. A posts one fresh protected marker through the actual strip. Record the stored channel post ID, exact cover/entities, author/signature mode, preview state, and B's received row. A comment in a discussion group does not count. [TASKS 1027, 7241]

3. Restart B-side OSL, open the eye on the persisted subscriber-side channel post, compare exact private bytes/hash, then close the eye and confirm exact cover. [TASK 7762]

4. After the base channel pass, edit one cover character as A and require B's plaintext overlay to disappear/refuse. Replace it with a newly generated protected post and require a fresh successful decrypt. Test signatures/profile posting only after the default channel-branded path works. These are follow-ups, not blockers for the default channel-branded pass. [TASK 3953; Telegram channel model: https://core.telegram.org/api/channel]

Proof: read-only B independently decrypts the exact persisted post from the exact private channel after restart; the provider row, posting identity, subscriber receipt, and eye cover/private/cover states are all recorded. [TASKS 1027, 7241, 7762]

False pass: only A/admin-side decrypts; B is made admin and a group-like path is tested; a channel comment/direct message stands in for a post; only ciphertext visibility or a Sent badge is shown; a stale pre-edit plaintext remains; or any public/third-party post occurs. [RULING D38; TASKS 3953, 7762]

Cut or defer now

1. Cut public_post from the first Telegram shipping and test gate. The requested product scopes are private chat, group, supergroup, channel, and Saved Messages; owner-account testing may never post publicly. Keeping an all-six-kinds gate makes a forbidden test block private working product. [RULING D38; TASKS 0147, 3740, 4207]

2. Split TASK 7762's base text path from lifecycle extras. First ship real send, stored text/entities readback, independent decrypt, and row overlay per scope. Defer timer, view-once, burn, and attachments, and hide those controls until proved. The current monolithic fake makes a larger claim without one live send. [01-FULL-SPEC.md:110-116; evidence/7762.md; TASK 7762]

3. Do not gate Telegram on TASK 7791's whole-product 61-area matrix. A real private text loop is useful and testable before unrelated mail, community, billing, or lifecycle work is complete. Honest per-scope unavailable states prevent a shipping lie. [01-FULL-SPEC.md:368,384; TASK 7791]

4. Defer pixel imitation and stealth classification. Keep exact process/account/chat/composer/row anchoring, zero-or-multiple-composer refusal, stored-row equality, and plaintext invalidation on edit. Drop five-capture color floors, seam rings, one-pixel mutants, and the classifier bar from the base Telegram text milestone. Do not claim pixel identity or stealth. [RULING D37; TASKS 5110-5147]

5. Defer rich formatting, provider-entity inspection, preview controls, native forwarding UX, and edit UX. The default cover avoids Markdown and URLs. First verify that Telegram stored exactly that text, produced no visible preview, and decrypted from the receiver row. Later features may not reuse an old cover across scopes or reveal a changed row. [RULING D33; TASKS 3953, 3954, 7241]

The two lines that do not move are unchanged: never send or post to anyone except the owner's A/B identities, and never record a Telegram scope as proved until the exact live carrier send, stored row, receiver decrypt, and eye result actually happened. [RULING D38; 01-FULL-SPEC.md:368; TASKS 4093, 7762]