zara-comms: unified messaging and email domain plugin #11

New issue

Closed

opened 2026-08-31 18:43:26 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-31 18:43:26 +00:00

(Migrated from github.com)

Plugin

zara-comms

Goal

Provide Zara with one structured communications domain over email/chat providers so it can search, summarize, draft and reply without each provider defining incompatible semantics.

Initial provider targets

Design adapters for Gmail, Matrix, Discord and Slack-style messaging. Provider support can land incrementally behind one normalized model.

Domain model

Normalize:

account/provider
conversation/thread/channel
message
sender/recipients
timestamps
attachments
read/unread state
reply/thread references

Tool surface

search/list conversations/messages
get thread/message
draft reply/new message
send explicit draft/message
mark/archive/label where provider supports it
attachment metadata/download through bounded destinations

Integrate with zara-contacts for person resolution rather than duplicating identity logic.

Safety

drafting and sending are separate operations;
do not infer recipients when identity resolution is ambiguous;
preserve provider/thread IDs;
bound message/attachment retrieval;
credentials/tokens never appear in logs/tool output;
mutations return provider acknowledgement/evidence.

Acceptance criteria

provider-neutral message/thread model exists
at least two fake provider adapters exercise the same public API
search/read/draft/send are cleanly separated
ambiguous recipient resolution fails explicitly
attachments are bounded and metadata-first
tests require no live accounts/network
README documents provider adapter/auth model
registry validation, plugin tests and nix flake check pass

## Plugin `zara-comms` ## Goal Provide Zara with one structured communications domain over email/chat providers so it can search, summarize, draft and reply without each provider defining incompatible semantics. ## Initial provider targets Design adapters for Gmail, Matrix, Discord and Slack-style messaging. Provider support can land incrementally behind one normalized model. ## Domain model Normalize: - account/provider - conversation/thread/channel - message - sender/recipients - timestamps - attachments - read/unread state - reply/thread references ## Tool surface - search/list conversations/messages - get thread/message - draft reply/new message - send explicit draft/message - mark/archive/label where provider supports it - attachment metadata/download through bounded destinations Integrate with `zara-contacts` for person resolution rather than duplicating identity logic. ## Safety - drafting and sending are separate operations; - do not infer recipients when identity resolution is ambiguous; - preserve provider/thread IDs; - bound message/attachment retrieval; - credentials/tokens never appear in logs/tool output; - mutations return provider acknowledgement/evidence. ## Acceptance criteria - [ ] provider-neutral message/thread model exists - [ ] at least two fake provider adapters exercise the same public API - [ ] search/read/draft/send are cleanly separated - [ ] ambiguous recipient resolution fails explicitly - [ ] attachments are bounded and metadata-first - [ ] tests require no live accounts/network - [ ] README documents provider adapter/auth model - [ ] registry validation, plugin tests and `nix flake check` pass