#[non_exhaustive]pub struct ChatCapability {
pub max_body_bytes: u64,
pub max_attachment_bytes: u64,
pub max_attachments_per_message: u64,
pub supports_threads: bool,
pub supported_body_types: Vec<BodyType>,
pub extra: Map<String, Value>,
}Expand description
Account-level capability object for "urn:ietf:params:jmap:chat".
Found at accounts[id].accountCapabilities["urn:ietf:params:jmap:chat"].
Spec: draft-atwood-jmap-chat-00 §3
§Strictness
The struct-level #[serde(default)] is deliberately NOT present:
max_body_bytes, max_attachment_bytes, max_attachments_per_message,
and supports_threads are spec-required fields (draft-atwood-jmap-chat-00
§3 lines 171-184). A server returning {} for this capability is
non-compliant, and consumers surface that via a deserialize error rather
than silently defaulting every field to 0 / false (which would cause
callers to refuse to send any message because max_body_bytes == 0).
supported_body_types carries field-level #[serde(default)] only —
see its rustdoc for the forward-compat tolerance rationale.
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.max_body_bytes: u64Maximum UTF-8 byte length of a Message body.
max_attachment_bytes: u64Maximum single attachment blob size in bytes.
max_attachments_per_message: u64Maximum number of attachments per message.
supports_threads: boolWhether the server supports the optional thread model.
supported_body_types: Vec<BodyType>The set of Message bodyType values this server understands
(draft-atwood-jmap-chat-00 §3).
Spec requirements for compliant servers:
- MUST include
BodyType::Plain("text/plain"). - SHOULD include
BodyType::Markdown("text/markdown", RFC 7763 CommonMark). - SHOULD include
BodyType::Rich("application/jmap-chat-rich"). - SHOULD include
BodyType::Other("application/mls-ciphertext".into())for E2EE deployments. - MAY include
BodyType::Other("application/mimi-content".into()).
An empty Vec is non-compliant per spec (BodyType::Plain is
mandatory) but consumers tolerate it via Default — the consumer is
responsible for enforcing the MUST and acting accordingly (e.g.
refusing to send rich messages to a server that does not advertise
the matching variant).
Element type is BodyType rather than String so callers can
match on the typed variants directly; canonical MIME-type wire
strings deserialize to their typed variant and any unknown wire
string lands in BodyType::Other per the impl_string_enum!
round-trip contract.
extra: Map<String, Value>Catch-all for vendor / site / private extension fields not covered by the typed fields above. Preserves unknown fields across deserialize/serialize round-trip per workspace extras-preservation policy (see workspace AGENTS.md).
The five aggregate-count caps maxGroupMembers,
maxSpaceMembers, maxRolesPerSpace, maxChannelsPerSpace, and
maxCategoriesPerSpace are not advertised on this capability
in the current draft-atwood-jmap-chat-00 §3 — they are
implementation-defined and enforced via standard overQuota
SetError (RFC 8620 §5.3) at Chat/set and Space/set time.
Servers that still emit them will round-trip the values
harmlessly through extra.
Trait Implementations§
Source§impl Clone for ChatCapability
impl Clone for ChatCapability
Source§fn clone(&self) -> ChatCapability
fn clone(&self) -> ChatCapability
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more