Summary. vector-core implements private channels, but vector_sdk exposes
none of it, so a bot added to a private channel silently stops responding with no
error and no diagnosable signal. Verified against vector_sdk 0.5.0 and 0.6.0.
What happened. Our bot lives in an encrypted community and answers every
message in its home channel, resolved by name. The community owner converted that
channel to a private one and added the bot as a member. The bot has not responded
since. It is running, connected, and polling normally.
What we found.
vector-core 0.4.0 already has full private-channel support, including
create_private_channel, and two behaviours that exactly describe our symptom:
follow_control_records_a_new_private_channel_keyless_and_unreadable
a_private_channel_subscribes_to_its_own_chat_plane
So a follower records the new private channel with no key and cannot read it, and
private channels use a separate chat plane. Both are presumably deliberate.
vector_sdk 0.5.0 and 0.6.0 contain ZERO private-channel references. grep -c
for "private" across src returns 10 in both, and every hit is about private
bots (invite whitelisting) or prose describing Vector as a private messenger.
The whole channel API surface is a single pub fn channel. The only public API
added between 0.5.0 and 0.6.0 is download_attachment_from.
In our bot's local cache the consequence is visible: community_edition_heads
holds 13 channels while community_channels holds 7, so six channels have edition
heads and no resolvable metadata. Every row in community_channels has
private = 0, including the channel literally named "private". Our home-channel
resolution reads list_communities() and matches on channels[].name, so a
keyless channel with no name can never be matched, and the bot keeps listening on
the now-unused public channel.
Why this is worth an SDK change rather than a doc note. The failure is silent
and indistinguishable from "nobody has talked to the bot yet". There is no error,
no warning, and no API that would let a bot detect it. From the operator's side
the bot is simply mute.
What would fix it, roughly in order of usefulness:
- A way for a bot to receive and store a private-channel key, so membership
granted by an admin actually takes effect.
- A way to enumerate private channels the bot is a member of, including ones it
cannot yet decrypt, so tooling can tell "not a member" from "member without a
key".
- Failing both, a surfaced signal when a control event records a channel the bot
cannot read, so the condition is at least diagnosable rather than silent.
Environment. vector_sdk 0.5.0 and 0.6.0, vector-core 0.4.0 and 0.5.0,
Rust, Linux. Reproducible by adding a bot to a private channel and sending a
message it would otherwise answer.
Summary.
vector-coreimplements private channels, butvector_sdkexposesnone of it, so a bot added to a private channel silently stops responding with no
error and no diagnosable signal. Verified against
vector_sdk0.5.0 and 0.6.0.What happened. Our bot lives in an encrypted community and answers every
message in its home channel, resolved by name. The community owner converted that
channel to a private one and added the bot as a member. The bot has not responded
since. It is running, connected, and polling normally.
What we found.
vector-core0.4.0 already has full private-channel support, includingcreate_private_channel, and two behaviours that exactly describe our symptom:follow_control_records_a_new_private_channel_keyless_and_unreadablea_private_channel_subscribes_to_its_own_chat_planeSo a follower records the new private channel with no key and cannot read it, and
private channels use a separate chat plane. Both are presumably deliberate.
vector_sdk0.5.0 and 0.6.0 contain ZERO private-channel references.grep -cfor "private" across
srcreturns 10 in both, and every hit is about privatebots (invite whitelisting) or prose describing Vector as a private messenger.
The whole channel API surface is a single
pub fn channel. The only public APIadded between 0.5.0 and 0.6.0 is
download_attachment_from.In our bot's local cache the consequence is visible:
community_edition_headsholds 13 channels while
community_channelsholds 7, so six channels have editionheads and no resolvable metadata. Every row in
community_channelshasprivate = 0, including the channel literally named "private". Our home-channelresolution reads
list_communities()and matches onchannels[].name, so akeyless channel with no name can never be matched, and the bot keeps listening on
the now-unused public channel.
Why this is worth an SDK change rather than a doc note. The failure is silent
and indistinguishable from "nobody has talked to the bot yet". There is no error,
no warning, and no API that would let a bot detect it. From the operator's side
the bot is simply mute.
What would fix it, roughly in order of usefulness:
granted by an admin actually takes effect.
cannot yet decrypt, so tooling can tell "not a member" from "member without a
key".
cannot read, so the condition is at least diagnosable rather than silent.
Environment.
vector_sdk0.5.0 and 0.6.0,vector-core0.4.0 and 0.5.0,Rust, Linux. Reproducible by adding a bot to a private channel and sending a
message it would otherwise answer.