[nissa-seru]

Problem

A channel server's metadata is spread into the metadata its message is stored with, and the host writes its own fields over it, such as channelId, messageId, author and the inbound source envelope. Some keys on a stored message are the host's alone, and a reader takes each one on its own as what the message is. The host writes some of them only when it has something to say, and others only on its own notices, so where it wrote nothing, a server's copy was stored, and a server's message could pass for one the host wrote. @slimepriestess found this in review of #598, and @Anarchid's review of #598 found it too (R1-3). It's #611. The same already holds on main for the failed-reply notice. This fixes it on main, ahead of #598.

Closes #611.

Changes

• One strip at both ingresses. withoutHostKeys drops the keys in HOST_METADATA_KEYS from a channels/incoming message's metadata and from a push event's origin, at the one place each lane builds the metadata it stores. The host writes its own marks after it, as before. Every other key a server sends is stored as before, beside the fields the host writes.
• A log line. The first time a server sends one of these keys, the host logs the server and the key, without the value, once for each server and key until it restarts. A server may use one of these names for something of its own, so the drop shouldn't be silent.
• The tool boundary. A message that arrives while an agent's tools run now reaches membrane there as its participant and content alone. A stored message's metadata is the host's record, not input for membrane.

The set, and the rule

A key is in the set when only the host writes it and some reader takes it on its own as what the message is:

• system and kind: the host's own notices and their kind (isConversationalInjection, shedNewestTurn, and the failed-reply readers releaseWindow, unreadFailedReplies, flushDeferredWrites and failedReplyNoticeForPrimary).
• draftOwner and draftIds: a notice naming a resident's drafts (draftsNamedInHistory, and the catch-up notice's read of the queue).
• tuneOut: a message a tune-out holds from the residents (the residents' viewFilter, and the readers that treat a row as held).
• coalescingSubject: the delivery of a coalesced occurrence, beside its eventId, which the host writes too (wasPublished).
• firstView: the coalescer's first-view mark. It was already dropped, and its two drops are now this one.
• deferredWriteId: the landed copy of a queued write (boot's dedup, landedCopiesById). addMessage drops it from the writes it stores, but a channel message for a conversation fork goes straight to the fork's store.
• external: a module's own row for an outside message (the Discord module's storedRows and storedByDiscordId, matchesMessageQuery, findMessageByExternalId).
• openaiResponsesItems: membrane's mark of an imported Responses history, which only a host's import writes.

What stays:

• Keys a server writes by protocol, such as tags, mentioned, guildName and a push's raw channelId, since they're the server's claims to make.
• Keys a reader takes only beside one of the set. A failed reply's reason and detail are read only on a message whose kind is discord-send-failed, and fix(channels): a channel notice reaches whoever can close the channel, and a released agent's unread ones reach the primary #598's passOn only on a channel-notice, so with kind dropped nothing reads a server's copy of them. The Discord module reads discordTextFirst only on a row it found by external.
• Keys nothing reads where a server could set them. Nothing reads speaker. promptedBy and silentHeartbeat are read only on the agent's own rows, and an incoming message is stored as user.

So speaker and passOn, which #611 suggests, stay out by the same rule.

Both lanes build each content block afresh from the fields convertBlock knows (push-handler.ts, channel-registry.ts), so a server can't set a block's other fields either.

Messages stored or queued before this change keep what they were stored or queued with.

What servers were told

Nothing in 0.23.1 says the host keeps a server's metadata as sent:

• The framework's event types, McplChannelIncomingEvent.metadata and McplPushEvent.origin (src/types/events.ts), carry no doc comment.
• The wire types describe ChannelIncomingMessage.metadata as "Platform-specific metadata" and PushEventParams.origin as "Provenance metadata (server-defined)" (src/mcpl/types.ts).
• The README mentions message metadata only for the recovery outbox, stores from before metadata.serverId, and the deprecated router's mentioned rule.

mcpl's SPEC §16.6 says tags are "untrusted claims authored by the producer, exactly like origin and metadata. A host MAY disbelieve them."

We read where discord-mcpl, slack-mcpl, telegram-mcpL and heartbeat-mcpl build their messages' metadata and push origins, at each one's main, and none of them carries a key in the set. None of those, and none of portal, spend-mcpl, terminal-sessions-mcp, anima-docs or eidoverse-worlds, sends external.

A context/beforeInference injection's metadata stays out of this. context-manager builds an injected message from its namespace and content alone, and no injection is stored, so nothing reads it.

What each part is for

• HOST_METADATA_KEYS, one constant with the rule for joining it. Both lanes read one list, so a key the host starts to trust on its own is added in one place. Two inline lists, one per lane, would have to be kept in step.
• withoutHostKeys. One copy-and-drop serves both lanes. It's a method rather than a module function only because the log line keeps per-framework state.
• The log line and its Set. A server outside the house may use kind or system for something of its own, and would otherwise lose it without a word. The line names the server and the key, once each, so the log shows the drop and keeps the server's data out.
• The tool boundary's hand-off. It's the one place stored rows reach membrane without a compile. Handing over participant and content only keeps the host's record the host's, whatever membrane reads later, and whoever wrote the row. The host's own readers of an injection's metadata run on the array before the hand-off.
• Folding in firstView removes two else delete metadata.firstView lines.
• The tests.
  • The table pins each key in both lanes.
  • The release test pins the reported case in a fork.
  • The log test pins the line for two servers and both lanes.
  • The boundary test pins the hand-off.
  • The table and log tests use inbound-source.test.ts's harness over the same fixture server.
  • The five coalescing assertions read the first-view mark from the stored row, storedFirstView, since membrane is no longer handed it, and the stored row is where the host reads it.
• Not done: keeping the host's marks under a field of their own, apart from the server's metadata. That would change every reader and writer of a notice and every stored message, for the same guarantee this gives at the two places a server's metadata comes in.

Tests

• test/ingress-host-keys.test.ts, over a real MCPL child:
  • a channel message whose metadata carries every key in the set is stored without them, and its own keys stay;
  • a push whose origin carries every key is stored the same way;
  • the log line comes once for each server and key, for two servers and in both lanes, and names no value.
• test/route-failure-targeting.test.ts: a DM whose metadata carries every key and claims to be a failed-reply notice reaches the fork's window without them, and tells the primary nothing when the fork is released.
• test/present-while-acting.test.ts: a message injected at a tool boundary reaches membrane as its participant and content alone, whatever its row carries.
• test/mcpl-coalescing.test.ts: five assertions that read the coalescer's firstView from what membrane was handed now read it from the stored row.

Runs at this head, with main 06445063 merged in, on Node v24.22.0:

• the full suite passes: 5,803 tests, 5,759 passing, 44 skipped, none failing;
• with any one key left out of HOST_METADATA_KEYS, the release test fails, and so do the table tests for every key but deferredWriteId, which addMessage already drops from the trunk's writes;
• with the log line silenced, or its once-only set keyed by the key alone, the log test fails;
• with the tool boundary handing membrane each message whole, the boundary test fails.

At the branch's head before that merge, with main's src/framework.ts in place, the five new tests fail and the four files' other 298 tests pass.

Not verified

• Live servers. The tests use the fixture MCPL server and in-process events. That discord-mcpl, slack-mcpl, telegram-mcpL and heartbeat-mcpl send none of the set's keys rests on reading their source.

Review

Reviewed at the Rookery: two runs of our review workflow, on the change and on its second round, with every finding judged; reads of the code, and of the merge with main, by two colleagues who didn't build it; and runs of the new tests against main's src/framework.ts.

---

• Changelog fragment added: changelog.d/ingress-host-keys.fixed.md.

🤖 Written by Petra-1012 (Claude Opus 5.5) through the Rookery's tooling, contributing through nissa-seru. Ada-1017 (Claude Opus 5.5) made the design calls.

Description checked and posted by Fiona-2757 (Claude Opus 5.5).

[nissa-seru]

@antra-tess Flagging for your awareness this PR, which made the following change (in brief):

• A channel server's message whose metadata (or a push's origin) carried a key only the host writes, such as system, kind or tuneOut, was stored with it, so it could pass for the host's own: one with kind: "discord-send-failed", left unread in a fork's window, made the host tell the primary that the fork's reply had failed → those keys are dropped, and the host writes its own.

— Lottie-2661