Merge branch 'master' into beta

Author: isaac

.gitignore

@@ -83,3 +83,4 @@ xcode-files
 /buildbox/*
 **/node_modules/
 tools/sim-watcher/dist/
+.mcp.json

CLAUDE.md

@@ -69,7 +69,7 @@ The sim ignores code signing, so the unsigned `Telegram_archive-root` bundle run
 
 ## RichTextEditor editor & the `ChatInputContent` composer
 
-A from-scratch WYSIWYG rich-text editor (`submodules/TelegramUI/Components/RichTextEditor`) is the default chat composer (the `forceLegacyTextInput` experimental flag opts back out to the legacy input), and `ChatInputContent` (a TelegramCore-native value model) replaced `NSAttributedString` as the composer currency. The app-side integration — the model and its load-bearing invariants, composer ↔ editor wiring, the formatting-menu / custom-emoji-mention-date / code-block / inline-media round-trips, rich-message send / edit / pending-display, the long-press-Send send-options preview, and draft persistence (local, cross-device media sync, re-login restore) — lives in [`docs/richtext-composer.md`](docs/richtext-composer.md). Editor internals (the TextKit seam, layout) are the editor's own `submodules/TelegramUI/Components/RichTextEditor/CLAUDE.md`; message **rendering** is [`docs/instantpage-richtext.md`](docs/instantpage-richtext.md).
+A from-scratch WYSIWYG rich-text editor (`submodules/TelegramUI/Components/RichTextEditor`) is the native chat-composer backend — by default a **dual-field switch** (the composer uses the legacy input and latches to the native editor only when content becomes legacy-non-representable); the `forceNewTextInput` experimental flag (Debug Settings ▸ "Force Text Field v2") forces always-native. (This inverted the earlier default+`forceLegacyTextInput`-opt-out scheme.) `ChatInputContent` (a TelegramCore-native value model) replaced `NSAttributedString` as the composer currency. The app-side integration — the model and its load-bearing invariants, composer ↔ editor wiring, the formatting-menu / custom-emoji-mention-date / code-block / inline-media round-trips, rich-message send / edit / pending-display, the long-press-Send send-options preview, and draft persistence (local, cross-device media sync, re-login restore) — lives in [`docs/richtext-composer.md`](docs/richtext-composer.md). Editor internals (the TextKit seam, layout) are the editor's own `submodules/TelegramUI/Components/RichTextEditor/CLAUDE.md`; message **rendering** is [`docs/instantpage-richtext.md`](docs/instantpage-richtext.md).
 
 ## Embedded watch app (`Telegram/WatchApp`)
 

Telegram/Telegram-iOS/en.lproj/Localizable.strings

@@ -5303,6 +5303,8 @@ Sorry for the inconvenience.";
 
 "PeerInfo.BioExpand" = "more";
 "PeerInfo.HiddenCommunityStatus" = "Hidden • %@";
+"PeerInfo.Community_1" = "Community with %@ chat";
+"PeerInfo.Community_any" = "Community with %@ chats";
 "PeerInfo.Community.RemoveBot" = "Remove Bot from Community";
 "PeerInfo.Community.AddBot" = "Add Bot to a Community";
 "PeerInfo.Community.BotInfo" = "Make your bot part of a community with multiple related chats";
@@ -16430,6 +16432,7 @@ Error: %8$@";
 "Community.View.SectionVisible" = "CHATS YOU CAN VIEW";
 "Community.View.SectionRequestable" = "CHATS YOU CAN REQUEST TO JOIN";
 "Community.View.SectionHidden" = "HIDDEN CHATS";
+"Community.View.HiddenChatToast" = "You can't join or view this chat until an admin invites you.";
 "Community.View.PendingRequests" = "Pending Requests";
 "Community.View.PendingRequestHeader" = "PENDING REQUEST";
 "Community.View.ShowAsOneChat" = "Show as One Chat";
@@ -16440,6 +16443,8 @@ Error: %8$@";
 "Community.View.ChatsLimitReached" = "Sorry, this community has reached the maximum number of chats.";
 "Community.Request.UnknownRequester" = "Someone";
 "Community.Request.RequesterSuggestsGroup" = "%@ suggests this group:";
+"Community.Request.RequesterSuggestsChannel" = "%@ suggests this channel:";
+"Community.Request.RequesterSuggestsBot" = "%@ suggests this bot:";
 "Community.Request.PrivateStatus" = "visible only to its members";
 "Community.Request.Decline" = "Decline";
 "Community.Request.Add" = "Add";
@@ -16514,13 +16519,23 @@ Error: %8$@";
 "Community.Add.VisibilityHiddenInfo" = "Only invited members and community admins will see this chat.";
 "Community.Add.ActionAddToCommunity" = "Add to Community";
 
+"Community.Add.Confirm.TextGroup" = "If this group is approved by a community admin, its members will be able to join or request to join other chats in the community.";
+"Community.Add.Confirm.TextChannel" = "If this channel is approved by a community admin, its subscribers will be able to join or request to join other chats in the community.";
+"Community.Add.Confirm.TextBot" = "If this bot is approved by a community admin, community members will be able to see and use it.";
+"Community.Add.Confirm.Add" = "Add";
+
+"Community.AddChat.Title" = "Add a Chat";
+"Community.AddChat.Description" = "Select a chat to add to this community";
+
 "Community.Chat.JoinToView" = "You need to join this group to view its messages.";
 "Community.PrivateChat.Info" = "This group is invite-only.\nOnly its members can view it.";
 "Community.PrivateChat.MessageOwner" = "Message Group Owner";
+"Community.CommunityAdded.View" = "View";
 
 "Privacy.GroupsAndChannels.InviteToCommunityError" = "Sorry, you cannot add %@ to the community because of %@'s privacy settings.";
 
 "Notification.CommunityAddedGroup" = "%1$@ added this group to %2$@ community";
+"Notification.CommunityAddedGroupUnknown" = "This group was added to %1$@ community";
 "Notification.CommunityAddedGroupYou" = "You added this group to %1$@ community";
 "Notification.CommunityRemovedGroup" = "%1$@ removed this group from a community";
 "Notification.CommunityRemovedGroupYou" = "You removed this group from a community";
@@ -16543,6 +16558,15 @@ Error: %8$@";
 
 "Attachment.Article" = "Article";
 "RichText.AddMediaTitle" = "Add Media";
+"RichText.RemoveFormattingTitle" = "Remove Formatting?";
+"RichText.RemoveFormattingText" = "This message includes rich formatting, which requires Telegram Premium.";
+"RichText.SubscribeToPremium" = "Subscribe to Premium";
+"RichText.SendWithoutFormatting" = "Send Without Formatting";
+"RichText.LinkTitle" = "Link";
+"RichText.LinkText" = "Set a URL for the selected text";
+"RichText.LinkSet" = "Set";
+"RichText.LinkRemove" = "Remove";
+"RichText.PremiumToastText" = "Sending a message with this formatting will require [Telegram Premium]().";
 "RichText.TableMenu.Alignment" = "Alignment";
 "RichText.FormulaAdd" = "Add Formula";
 "RichText.FormulaEdit" = "Edit Formula";
@@ -16563,6 +16587,11 @@ Error: %8$@";
 "RichText.Menu.Table.Copy" = "Copy Table";
 "RichText.Menu.Table.ConvertToText" = "Convert to Text";
 "RichText.Menu.Table.Delete" = "Delete Table";
+"RichText.Menu.Table.HighlightOn" = "Highlight";
+"RichText.Menu.Table.HighlightOff" = "Remove Highlight";
+"RichText.PlaceholderBody" = "Type something...";
+"RichText.PlaceholderQuote" = "Type a quote here";
+"RichText.PlaceholderCode" = "Type code here";
 
 "TextProcessing.TitleAICompose" = "Create with AI";
 "TextProcessing.ActionAddToPage" = "Add to Page";

docs/instantpage-richtext.md

@@ -122,8 +122,17 @@ Specs: [`2026-06-02-instantpage-v2-audio-design.md`](docs/superpowers/specs/2026
 composer (`ChatInputContentInstantPage`) and the article editor (`RichTextEditorMessageConversion`'s
 `InstantPageBuilder`) converters — the first editor/rich-message path to produce a `.collage` block
 (needed zero codec work; it was already first-class through Postbox/FlatBuffers/upload). A container of
-exactly 1 item still sends the plain `.image`/`.video` block, byte-identical to before. `.slideshow`
-remains produced only by real web Instant View articles.
+exactly 1 item still sends the plain `.image`/`.video` block, byte-identical to before.
+
+**`.slideshow` is now editor-produced too (added 2026-07-17).** A multi-media container carries a
+`displayMode` (`.mosaic` default / `.slideshow`; mirrored `MediaBlock.displayMode` ↔
+`ChatInputMedia.displayMode`, Codable back-compat → `.mosaic`). Both forward converters branch on it:
+`.mosaic → .collage`, `.slideshow → .slideshow` (same inner `.image`/`.video` blocks); the reverse
+`chatInputBlocks(fromInstantPageBlocks:)` gained a `.slideshow` arm (sharing the collage arm's item
+helper) so the mode round-trips on edit. The mode is toggled in the **article editor** via a top-right
+button (mosaic↔slideshow); the composer stays mosaic-only. So `.slideshow` is now produced both by real
+web Instant View articles and by editor-authored slideshow albums. Design + plan:
+`docs/superpowers/{specs,plans}/2026-07-17-richtext-media-layout-toggle*`.
 
 ### Where things live
 
@@ -438,6 +447,29 @@ Spec: [`docs/superpowers/specs/2026-05-27-instantpage-list-checkbox-design.md`](
 - **Forward parser keeps `[ ]` detection but routes to `checked`.** `markdownApplyTaskListMarker`/`markdownStrippingTaskListMarker`/`markdownTaskListMarker` still strip the marker from the item text; the state flows into `checked` while ordered items keep their real `"\(ordinal)"` number. The reverse converter emits lowercase `[x]` / `[ ]`, which the forward `hasPrefix` guards re-parse — that is the round-trip contract.
 - **The enum-arity change is compile-enforced.** Adding the third associated value broke every `.text`/`.blocks` construction/destructure; the full build is the completeness gate. Read-only consumers outside the core set exist (`BrowserInstantPageContent.swift`, `CachedFaqInstantPage.swift`) — grep `\.(text|blocks)\(` repo-wide when touching the enum again.
 
+### Tap-to-toggle (editable rich messages)
+
+Task-list checkboxes in a rendered rich message are **interactive when the message is editable**: tapping one flips it and persists the change by editing the message.
+
+Where things live:
+
+| File | Responsibility |
+|---|---|
+| `submodules/TelegramCore/Sources/InstantPageCheckboxToggle.swift` | Pure transform `InstantPage.togglingCheckbox(at: [Int], to: Bool) -> InstantPage` — rebuilds the block tree following a structural path and flips the target list item's `checked` (no-op on an unresolvable/non-checkbox path). |
+| `submodules/InstantPageUI/Sources/InstantPageV2Layout.swift` | `InstantPageV2ListMarkerItem.checkboxPath: [Int]?`; a `pathPrefix: [Int]` threaded through `layoutBlockSequence`/`layoutBlock`/`layoutList`/`layoutDetails`/`layoutBlockQuote` stamps each `.checklist` marker with its path. |
+| `submodules/InstantPageUI/Sources/InstantPageRenderer.swift` | `InstantPageV2ListMarkerView` installs a tap gesture when `interactive`, flips its own `CheckNode` optimistically, and fires `onCheckboxTapped(path, newValue)`; `InstantPageV2View.checkboxTapped` routes it up (mirrors `detailsTapped`). |
+| `submodules/TelegramUI/Components/ChatControllerInteraction/Sources/ChatControllerInteraction.swift` | `canEditMessageRichText: (EngineRawMessage) -> Bool` (sync gate, mirrors `canSetupReply`) + `toggleMessageRichTextCheckbox: (EngineMessage.Id, [Int], Bool) -> Void` (the edit action). Both have no-op defaults so only the real chat wires them. |
+| `submodules/TelegramUI/Sources/ChatController.swift` | Implements both closures. The toggle looks up the message, re-checks `canEditMessage`, applies `togglingCheckbox`, and submits via `pendingUpdateMessageManager.add(text: "", richText:)` — the composer's rich-edit path (mirrors the native-todo `requestToggleTodoMessageItem`). |
+| `submodules/TelegramUI/Components/Chat/.../ChatMessageRichDataBubbleContentNode.swift` | `checkboxesInteractive(item:resolved:)` gate + sets `pageView.checkboxTapped` per apply. |
+
+Non-obvious invariants:
+
+- **Checkbox identity is a structural `[Int]` path**, not an ordinal: each element indexes the current container's children — block-array index at page/`.details`/`.blockQuote`/list-item-`.blocks` levels; item index at `.list` level. The layout stamping (`InstantPageV2Layout`) and the toggle walker (`InstantPageCheckboxToggle`) MUST keep identical semantics — they were built and reviewed as a matched pair. Decoupled from `<details>` expand/collapse state.
+- **The path is absolute-from-root only because every `layoutBlockSequence` that can reach a list is entered with a correct prefix.** The two secondary `layoutBlockSequence` call sites (table cells, hard-coded `[.paragraph]`; and the details title) contain no lists, so no checkbox is produced there; a `kind != .cell` guard in `layoutList` is belt-and-suspenders against future misrouting.
+- **The toggle applies to `attribute.instantPage`, so taps must only ever fire against that page.** The bubble's `checkboxesInteractive` gate enforces this: interactive only when `resolved.key` is `.original` AND `resolved.instantPage === attribute.instantPage` (class identity — excludes the show-more `fullInstantPage` rendering, which shares the `.original` key but is a different `InstantPage` object) AND `canEditMessageRichText(item.message)`. Translations (`.translated`) and in-flight pending edits (`.pendingEdit`) are inert. Non-editable messages (incoming, past the edit window) are inert — and AI-streamed rich messages are incoming, hence never tappable.
+- **Optimistic flip, model supersedes.** The marker view flips its own `CheckNode` on tap; the pending/edited attribute re-render then supersedes (or, on failure, reverts, since the model was unchanged). Known minor edges of this state-free optimism: (1) an unrelated `update()` before the pending edit lands rebuilds the marker from the old `checked`, briefly reverting the visual; (2) a rapid double-tap re-reads the still-stale `checked` and re-sends the same value rather than toggling back — the pending-edit manager coalesces, so the net state is consistent, just not a double-toggle. Both are acceptable given the edit lands promptly.
+- **Gating uses closures because `canEditMessage` is `internal` to the `TelegramUI` module** and the rich-data bubble lives in a separate component module that cannot call it. The two closures bridge the boundary; **their init-parameter order must match the `ChatController` call-site order** (Swift requirement) — they sit between `displayTodoToggleUnavailable` and `openStarsPurchase`.
+
 ## InstantPageBlock.blockQuote nested blocks
 
 `InstantPageBlock.blockQuote` carries `(blocks: [InstantPageBlock], caption: RichText)` — a sequence of nested page blocks (paragraphs, headings, lists, code, even nested quotes), not the legacy text-only payload. `.pullQuote` is unchanged (still `(text: RichText, caption: RichText)`; the TL API has no `pullQuoteBlocks` constructor).

docs/richtext-composer.md

@@ -115,6 +115,18 @@ send-options preview and the attachment-menu rich-editor send — see §5).
   precedent — one value seen by undo/drafts/send/observers). Thin converters:
   `ChatRichTextEditorComposer/Sources/ComposerExpandedEditorBridge.swift`. Custom-emoji **files** (`[Int64:
   TelegramMediaFile]`) and media are threaded both ways (a fileId-only emoji ref renders blank).
+- **OUT back-fills emoji files the composer content only holds by fileId.** A `ChatInputContent` custom-emoji
+  run may carry the fileId **without** the `TelegramMediaFile` attached; the plain `documentMediaAndEmoji(...)`
+  then returns an `emojiFiles` map missing those ids, seeding the editor's emoji store (and, on the initial
+  `.edit`/`.standalone` seed, the keyboard's file set) empty — so the emoji renders blank and its file is dropped
+  on collapse-back / send. The OUT path therefore uses the **async** `documentMediaAndEmojiAsync(engine:…)`
+  (awaited inside `openExpandedInput`'s `Task { @MainActor }`), which resolves any fileId with no inline file from
+  the **local** sticker cache (`engine.stickers.resolveInlineStickersLocal`, a postbox `getMedia` over
+  `Namespaces.Media.CloudFile`). Local-only is deliberate — composer emoji are always already cached, so no
+  network round-trip stalls the expand; a fileId absent even locally simply stays unresolved (renders blank, as
+  before). Persisted **drafts** need no resolution (their `emojiFiles` are stored/decoded whole in
+  `RichTextDraft`); the in-editor AI-insert paths still use the sync `documentMediaAndEmoji` (their
+  completion closures are synchronous, and AI-generated content rarely carries custom emoji).
 
 > **Invariant — the cycle constraint.** `InstantPageUI` transitively deps `ChatTextInputPanelNode`, so the
 > panel/node **cannot** dep `InstantPageUI` / `RichTextEditorMediaView`. `TelegramUI` (above the cycle) builds
@@ -194,10 +206,17 @@ All inline / structural features round-trip losslessly through the native compos
   same one grouped album messages use), with per-cell view reuse keyed by media identity so surviving
   cells aren't rebuilt/re-fetched on an add/remove. A container of `items.count >= 2` sends as an
   InstantPage **`.collage`** rich message (see `instantpage-richtext.md`); `count == 1` still sends the
-  byte-identical `.image`/`.video` block. **Authoring is split:** per-cell delete-one is wired in both
-  hosts; "Add another photo/video" is wired in the **article editor**'s more-menu only — the composer's
-  in-place Add is a deferred follow-up (the composer already renders/edits multi-media from sent albums
-  and drafts). Design + plan: `docs/superpowers/{specs,plans}/2026-07-08-richtext-multi-media-container*`.
+  byte-identical `.image`/`.video` block. **Layout mode (added 2026-07-17).** A `MediaBlock`/`ChatInputMedia`
+  now carries a `displayMode` (`.mosaic` default / `.slideshow`, Codable back-compat → `.mosaic`); a
+  `count >= 2` container in `.slideshow` mode renders in-editor as a swipeable carousel + paging dots and
+  **sends as InstantPage `.slideshow`** instead of `.collage` (both forward converters branch on it; the
+  reverse recovers it on edit). The toggle button that flips the mode is **article-editor only** (left of
+  "+"); the composer stays mosaic-only. Design + plan:
+  `docs/superpowers/{specs,plans}/2026-07-17-richtext-media-layout-toggle*`. **Authoring is split:** per-cell
+  delete-one is wired in both hosts; "Add another photo/video" and the layout toggle are wired in the
+  **article editor**'s chrome only — the composer's in-place Add is a deferred follow-up (the composer
+  already renders/edits multi-media from sent albums and drafts). Design + plan:
+  `docs/superpowers/{specs,plans}/2026-07-08-richtext-multi-media-container*`.
   **Media spoilers (added 2026-07-08).** A photo/video can be marked a Telegram-style spoiler (dust-covered
   until tapped), per **item**: `MediaItem.isSpoiler` (editor Core) ↔ `ChatInputMediaItem.isSpoiler`
   (both additive, optional-Codable, absent ⇒ `false`, so all existing docs/drafts/messages decode