Build our own Discord Activities, since a bot cannot invoke another bot's #837

New issue

Open

opened 2026-08-15 20:17:22 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-15 20:17:22 +00:00

Member

Filed by Delphi (design seat) at Kai's direction, 2026-08-15. Successor to #485, which closed on the platform question.

Why this exists

#485 asked whether Echo could invoke Discord's existing media apps rather than Coilyco maintaining an MCP per service. The check came back no - a bot cannot invoke another bot's application commands. Kai's conclusion:

we'll have to make our own activities

So the shared-media capability the community would benefit from has exactly one route left, and it is building it.

What is unresolved, and all of it is

This issue carries a direction, not a design. Nothing below is decided.

What the first Activity is. Media playback was the motivating example and it is not obviously the right first one. An Activity that suits an Eco community may be something else entirely.
Whether Echo starts it or a member does. The whole point of #485 was Echo reaching a capability on the channel's behalf. If a member launches the Activity directly, Echo is not involved and most of the risk below evaporates.
Build and hosting shape. A Discord Activity is an embedded application with its own hosting, lifecycle, and release path. That is a materially different kind of artifact from anything this repo ships today.

Constraints that bind whatever gets built

Carried from #485, where they were written for a mechanism that turned out not to exist. They apply unchanged to one we build.

An Activity is an action in a shared space. It affects everyone in the channel, not the member who asked. Tier 3 under #179 - reversible, and it lands on people who did not ask for it.
If Echo can start one, that is a capability gate and it needs its own decision. #230 was reaffirmed on 2026-08-15: Discord roles adjust content posture and grant no tool access. Gating an Activity on a role would be a new kind of authority.
It appears in the tool disclosure footer (#385). An invocation is an action-claim and needs a receipt.
Permissions. An Activity needs its own Discord scopes, and this estate has already shipped install links missing bits it needed (EMBED_LINKS, ADD_REACTIONS, USE_EXTERNAL_EMOJIS, all corrected in coilyco-bridge/deploy 3330c8d). Establish the required scopes before building, not after.

Not blocked by this

Spotify and YouTube are back to being MCP questions, per #485's close. Do not hold the roster work behind this issue - it was blocking them only while the platform path was still possible.

Done when

A decision exists on what the first Activity is, who may start it, and where it is hosted. Then it becomes a build ticket rather than this one.

Related - #485 (closed, carries the platform answer), #179 (blast radius), #230 (roles grant no capability), #385 (disclosure footer), coilyco-bridge/deploy#418 (media roster).

Filed by Delphi (design seat) at Kai's direction, 2026-08-15. Successor to #485, which closed on the platform question. ## Why this exists #485 asked whether Echo could invoke Discord's existing media apps rather than Coilyco maintaining an MCP per service. **The check came back no - a bot cannot invoke another bot's application commands.** Kai's conclusion: > we'll have to make our own activities So the shared-media capability the community would benefit from has exactly one route left, and it is building it. ## What is unresolved, and all of it is This issue carries a direction, not a design. Nothing below is decided. * **What the first Activity is.** Media playback was the motivating example and it is not obviously the right first one. An Activity that suits an Eco community may be something else entirely. * **Whether Echo starts it or a member does.** The whole point of #485 was Echo reaching a capability on the channel's behalf. If a member launches the Activity directly, Echo is not involved and most of the risk below evaporates. * **Build and hosting shape.** A Discord Activity is an embedded application with its own hosting, lifecycle, and release path. That is a materially different kind of artifact from anything this repo ships today. ## Constraints that bind whatever gets built Carried from #485, where they were written for a mechanism that turned out not to exist. They apply unchanged to one we build. * **An Activity is an action in a shared space.** It affects everyone in the channel, not the member who asked. Tier 3 under #179 - reversible, and it lands on people who did not ask for it. * **If Echo can start one, that is a capability gate and it needs its own decision.** #230 was reaffirmed on 2026-08-15: Discord roles adjust content posture and grant no tool access. Gating an Activity on a role would be a new kind of authority. * **It appears in the tool disclosure footer** (#385). An invocation is an action-claim and needs a receipt. * **Permissions.** An Activity needs its own Discord scopes, and this estate has already shipped install links missing bits it needed (`EMBED_LINKS`, `ADD_REACTIONS`, `USE_EXTERNAL_EMOJIS`, all corrected in coilyco-bridge/deploy `3330c8d`). Establish the required scopes before building, not after. ## Not blocked by this Spotify and YouTube are back to being MCP questions, per #485's close. Do not hold the roster work behind this issue - it was blocking them only while the platform path was still possible. ## Done when A decision exists on what the first Activity is, who may start it, and where it is hosted. Then it becomes a build ticket rather than this one. **Related** - #485 (closed, carries the platform answer), #179 (blast radius), #230 (roles grant no capability), #385 (disclosure footer), coilyco-bridge/deploy#418 (media roster).

coilyco-ops added the

labels

2026-08-15 21:11:39 +00:00