A single default Mini App opened from the bot's menu button — shows the group's transactions with an Android-style FAB to create an expense. Effectively History + Expense behind one entry point.
Status: nice-to-have, deferred. Ship #125 (History) and #305 (Expense) first. Captured here so the design constraints aren't lost.
The core constraint — group context
The menu button / Main Mini App always launches in the private chat with the bot; there is no group at that surface (initData gives the user, never a group). Inline/reply web_app buttons are private-chat-only, so you can't launch with group context from a group either — the only in-group path is a direct link (t.me/<bot>/<app>?startapp=…), i.e. the existing token mechanism.
So a context-free default app must resolve the group itself. Two options:
- (a) Group picker — validate
initData → list the user's groups → pick → load. The bot can build that list: it can't enumerate Telegram chats, but it already knows where the user participates via its own GroupConfig.members registry (cheap DB query). Needs an initData-only bootstrap endpoint (e.g. GET /app/api/groups) that runs before any token exists, plus token issuance after selection.
- (b) Group-scoped launch — keep the direct-link/token flow, triggered by a posted button instead of
/history. Group known, no picker — but then it isn't really a menu-button "default".
Decision: the group picker (a) is deferred for now — the two deep-linked apps come first.
Scope / token implications
- The default app needs both
HISTORY (list) and EXPENSE (FAB) capability for the chosen group → either mint two tokens or revisit the scope model.
- Token TTL for an always-available main app is unresolved. Short 30-min tokens would make an always-open app
401 constantly. Decide later — likely a longer / refreshable token or a re-auth-on-focus path, distinct from the deep-linked apps' short tokens.
Composition
- Bot: register the menu button (
setChatMenuButton / BotFather main app).
- UI: transactions list (reuse History) + FAB → expense form (reuse Expense).
Digested from #294
Dependencies
A single default Mini App opened from the bot's menu button — shows the group's transactions with an Android-style FAB to create an expense. Effectively History + Expense behind one entry point.
The core constraint — group context
The menu button / Main Mini App always launches in the private chat with the bot; there is no group at that surface (
initDatagives the user, never a group). Inline/replyweb_appbuttons are private-chat-only, so you can't launch with group context from a group either — the only in-group path is a direct link (t.me/<bot>/<app>?startapp=…), i.e. the existing token mechanism.So a context-free default app must resolve the group itself. Two options:
initData→ list the user's groups → pick → load. The bot can build that list: it can't enumerate Telegram chats, but it already knows where the user participates via its ownGroupConfig.membersregistry (cheap DB query). Needs an initData-only bootstrap endpoint (e.g.GET /app/api/groups) that runs before any token exists, plus token issuance after selection./history. Group known, no picker — but then it isn't really a menu-button "default".Decision: the group picker (a) is deferred for now — the two deep-linked apps come first.
Scope / token implications
HISTORY(list) andEXPENSE(FAB) capability for the chosen group → either mint two tokens or revisit the scope model.401constantly. Decide later — likely a longer / refreshable token or a re-auth-on-focus path, distinct from the deep-linked apps' short tokens.Composition
setChatMenuButton/ BotFather main app).Digested from #294
MiniApp.ktserves an MPA viasinglePageApplication { react(...) }(SPA-fallback semantics for a multi-page app). Adding a third app is a good moment to revisit the bundling / entry-point story.Dependencies