docs: add SLIMRPC collaborative channel spec (initial draft) by Tehsmash · Pull Request #5 · a2aproject/experimental-cpb-slimrpc

Tehsmash · 2026-06-10T15:59:53Z

Summary

Adds spec/slimrpc-collaborative-channel.md, a new specification that extends the SLIMRPC Multicast RPC model from one-to-many (1→N) to many-to-many (N→N) using SLIM group channels.

The spec introduces a dedicated Collaborate bidirectional streaming RPC operation:

rpc Collaborate(stream Message) returns (stream Message);

Key design points:

Reuses the existing A2A Message type in both directions — no new proto types
Sessions are scoped by the SLIM header RPC ID; agents discard messages from sessions they are not participating in
Message attribution uses the SLIM transport src field — no additional metadata required
All channel members are equal; any member (client or agent) may initiate or participate in a session
SLIM's native MLS addressed messaging is used for unicast-within-group targeting
Agents declare support via the A2A extensions mechanism with URI https://a2a-protocol.org/bindings/experimental-slimrpc/extensions/collaborate/v1

Also updates README.md to link to the new document.

Status: Initial draft — open for review and feedback.

micpapal · 2026-06-11T12:53:08Z

+| :---------------------- | :------------- | :-------------- |
+| Bidirectional streaming | `Message`      | `Message`       |
+
+The SLIM header metadata carries an **RPC ID** that is assigned when the RPC is initiated. This RPC ID identifies the specific **Collaborate session** and allows recipients to accept or discard messages from sessions they are not participating in.


Not sure to understand this part. Is this used as an additional filter on the members of the group?

In SLIMRPC we multiplex RPC over one SLIM session/channel so multiple RPCs can be happening concurrently, this is done through the RPC ID in the SLIM message metadata.

If you have Agents A, B, D, C participants in an MLS group this allows A and B to concurrently send RPCs to the channel, and the responses can be demultiplexed to the right RPC session/stream.

In this proposal the RPC ID allows A to start a "Collaborate" RPC session with the group for one context, and B to start a "Collaborate" RPC session with the group for a different parallel context, and the RPC ID will keep the responses going to the correct RPC stream inside the Agent.

Best analogy I could come up with is its like a slack/discord "thread", like a sub-chat within a channel, the channel determines who can participate in the sub-chat, the "Collaborate" RPC starts the thread, and each Agent can decide if they want to participate and can close their end of the stream if they aren't interested.

I forgot about this. We have it to avoid the overhead of creating a new session for each RPC. Then yes we can reuse the ID in the same way and allow for parallel RCPs between participants in the same group

micpapal · 2026-06-11T12:55:21Z

+
+- Any channel member **MAY** initiate a new session by invoking `Collaborate` on the channel; the RPC is delivered to all channel members via the SLIM Group Channel broadcast
+- Any member that receives a `Collaborate` invocation **MAY** choose to participate by sending `Message` objects on its response stream
+- Members **MUST** discard inbound `Collaborate` messages whose RPC ID does not correspond to a session they wish to handle


how do you know if you are interested or not to join the session upfront on the reception of the first message?

You wouldn't necessarily be able to know up front, but one receipt of the first message the Agent can decide if it is interested in the Collaborate stream, and if its not then it may decide to close the stream and not participate. At this point the RPC layer will discard the messages as this Agent is no longer tracking that RPC ID.

At group level how is it handled? It is equivalent to send a leave on the SLIM channel (and so it will prevent to participate in other RPCs within the same group) or it is just a drop of this particular set of messages?

Its just a drop of these particular RPC streams in that particular Agent. It can send EOS to let the rest of the group know its closed its stream, and we can decide if the other participating Agents should see this as an event or not.

Yes I guess this does not influence the lifetime of the MLS group itself.

micpapal · 2026-06-11T12:56:09Z

+- Any channel member **MAY** initiate a new session by invoking `Collaborate` on the channel; the RPC is delivered to all channel members via the SLIM Group Channel broadcast
+- Any member that receives a `Collaborate` invocation **MAY** choose to participate by sending `Message` objects on its response stream
+- Members **MUST** discard inbound `Collaborate` messages whose RPC ID does not correspond to a session they wish to handle
+- Multiple concurrent sessions **MAY** exist on the same channel, each distinguished by its RPC ID


isn't it simpler to create a new SLIM channel in this case?

I was thinking about the case where you have an external moderator who creates a group to bring Agents together. Sometimes these agents will be working alone, sometimes they may want to ask one specific other agent a question, and sometimes they might want to collaborate many to many.

The Agents when put into a group don't yet know how they want to work together and may also need to have parallel working sessions within the same group. With the RPC ID we can demultiplex the channel like we do for other RPC requests.

this is related to the comment on the previous session and it makes sense to use the possibility to have many RPCs with different context on the same channel. Also, this does not prevent an agent/client to participate to multiple channels at the same time.

micpapal · 2026-06-12T08:53:11Z

We need to add also the sender of the message. This requires an extension of the current definition of the message in the protocol

msardara

LGTM, but for this to work we'll need to extend the current channel/server model coming from grpc to something that allows any participant to initiate and receive an rpc.

msardara · 2026-06-15T10:02:19Z

+  "extensions": [
+    {
+      "uri": "https://a2a-protocol.org/bindings/experimental-slimrpc/extensions/collaborate/v1"
+    }
+  ]


This should go under capabilities I think.

msardara · 2026-06-15T10:09:26Z

+### 8.3. Teardown
+
+When the group channel is closed, all open `Collaborate` streams **MUST** be terminated. Agents **SHOULD** release any task state associated with active collaborative sessions on the channel.
+


A member of a collaborate session should also be able to close its own bidirectional stream, and in the same way a collaboration session should end if there is only one member left (agent or client)

msardara · 2026-06-15T11:02:18Z

+
+A **Collaborate session** is a single `Collaborate` RPC invocation, identified by its RPC ID in the SLIM header metadata.
+
+- Any channel member **MAY** initiate a new session by invoking `Collaborate` on the channel; the RPC is delivered to all channel members via the SLIM Group Channel broadcast


How will it work when collaborate() is invoked by a server? Probably we'll need to also extend the "channel/server" mode of slimrpc (the same of grpc) to a model where each member can at the same time invoke an rpc and receive an rpc via an handler.

msardara · 2026-06-15T11:08:01Z

+A **Collaborate session** is a single `Collaborate` RPC invocation, identified by its RPC ID in the SLIM header metadata.
+
+- Any channel member **MAY** initiate a new session by invoking `Collaborate` on the channel; the RPC is delivered to all channel members via the SLIM Group Channel broadcast
+- Any member that receives a `Collaborate` invocation **MAY** choose to participate by sending `Message` objects on its response stream


This can work as of now, just return an EOS if the agent does not want to collaborate. We probably need to add an additional error (status?) code for this

msardara · 2026-06-15T11:09:08Z

+
+- Any channel member **MAY** initiate a new session by invoking `Collaborate` on the channel; the RPC is delivered to all channel members via the SLIM Group Channel broadcast
+- Any member that receives a `Collaborate` invocation **MAY** choose to participate by sending `Message` objects on its response stream
+- Members **MUST** discard inbound `Collaborate` messages whose RPC ID does not correspond to a session they wish to handle


Yes I guess this does not influence the lifetime of the MLS group itself.

Introduces spec/slimrpc-collaborative-channel.md, extending the existing SLIM group channel multicast model from 1→many to many→many. The spec defines a new `Collaborate` bidirectional streaming RPC operation — rpc Collaborate(stream Message) returns (stream Message) — that allows any channel member (client or agent) to originate and receive messages simultaneously on a shared SLIM group channel. Sessions are identified by the SLIM header RPC ID; attribution uses the existing SLIM transport src field. Agents declare support via the A2A extension mechanism. Also updates README.md to link to the new document. Signed-off-by: Sam Betts <1769706+Tehsmash@users.noreply.github.com>

- Move spec from spec/ to spec/v1/ to align with versioning convention established in #4 - Fix Agent Card example: move extensions into capabilities.extensions as AgentExtension objects; remove v0.3.x top-level url field; add required v1.0 fields (description, version, defaultInputModes, defaultOutputModes, protocolVersion); fix protocolBinding to /v1 URI - Replace "MUST discard" with "SHOULD send EOS" for non-participating members (§ 4.2), making non-participation visible to other members - Clarify session lifecycle (§ 4.5): session SHOULD end when only one member remains; member MAY close its own stream via EOS without affecting group channel membership - Update README link to new spec/v1/ path Signed-off-by: Sam Betts <1769706+Tehsmash@users.noreply.github.com>

SLIM's transport-level src field is not visible to A2A application code, so agents in a Collaborate session could not identify the sender of a Message without inspecting the transport layer directly. Defines a new slim-src key in Message.metadata that the SLIMRPC layer MUST populate on every outbound Collaborate Message from the transport src field. Recipients MUST use this field for sender attribution at the A2A layer. - Add § 4.6 Message Attribution defining the slim-src metadata key, its type, population rules, and a JSON example - Update § 3 attribution bullet to reference the metadata approach - Update § 4.3 to require the SLIMRPC layer to set slim-src on send - Update § 4.4 to require recipients to use slim-src for attribution - Update sequence diagram annotations from transport src= to slim-src= Signed-off-by: Sam Betts <1769706+Tehsmash@users.noreply.github.com>

Introduces proto/v1/slimrpc_collaborative_channel.proto, defining the CollaborativeChannelService with a single bidirectional streaming RPC: rpc Collaborate(stream lf.a2a.v1.Message) returns (stream lf.a2a.v1.Message); The service imports the A2A proto for the Message type and documents the full session lifecycle and slim-src metadata attribution rules inline. Agents implementing this service must declare the collaborate extension URI in their Agent Card capabilities.extensions. Signed-off-by: Sam Betts <1769706+Tehsmash@users.noreply.github.com>

herczyn · 2026-06-24T11:31:04Z

i'm wondering if this is a special case of a2aproject/A2A#1975. how to achieve this:

one "multiplexer" (could be an agent or not) calls multiple agents with SendLiveMessage, initiating the connections.
MediaFrames are symmetrical bidi, so can easily be transported and multiplexed - any response get's sent to all agents as a request by the "multiplexer".
could easily be extended to be a tree structure rather than hub-and-spoke

question is: what is MediaFrame from the above PR missing that Message has?
message_id, context_id, task_id should stay stable across one connection, right? that leaves extensions/metadata which doesn't seem like something that we would need in this scenario, but if we want we can add it to MediaFrame (+rename to make it more clear that text is fine as well)

micpapal reviewed Jun 11, 2026

View reviewed changes

msardara reviewed Jun 15, 2026

View reviewed changes

Tehsmash added 2 commits June 15, 2026 14:05

Tehsmash force-pushed the feat/slimrpc-collaborative-channel branch from 3f32547 to bad394a Compare June 15, 2026 13:05

Tehsmash added 2 commits June 15, 2026 14:43

		### 8.3. Teardown

		When the group channel is closed, all open `Collaborate` streams MUST be terminated. Agents SHOULD release any task state associated with active collaborative sessions on the channel.


		A Collaborate session is a single `Collaborate` RPC invocation, identified by its RPC ID in the SLIM header metadata.

		- Any channel member MAY initiate a new session by invoking `Collaborate` on the channel; the RPC is delivered to all channel members via the SLIM Group Channel broadcast

Uh oh!

Conversation

Tehsmash commented Jun 10, 2026

Summary

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Tehsmash Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

micpapal commented Jun 12, 2026

Uh oh!

msardara left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

herczyn commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Tehsmash Jun 11, 2026 •

edited

Loading

herczyn commented Jun 24, 2026 •

edited

Loading