XF/GIA
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
438e561da02e094806bfaa8a897a7de53b77dd96
GIA/artifacts/plans/02-transport-capability-matrix.md
Mark Veidemanis 438e561da0 Harden security
2026-03-05 05:42:19 +00:00

2.0 KiB
Raw Blame History

Feature Plan: Transport Capability Matrix

Goal

Define transport feature capabilities centrally so router/policy/UI can make deterministic decisions.

Why This Fits GIA

  • GIA currently spans Signal/WhatsApp/Instagram/XMPP with uneven feature support.
  • Prevents silent failures (for example reaction exists internally but cannot be sent outward).

How It Follows Plan 1

  • Plan 1 established canonical event flow as the shared source language for transport actions.
  • Plan 2 uses that event flow to gate what may be attempted per transport before adapter calls.
  • Interlink:
    • Canonical events define what happened (reaction_added, message_edited, etc.).
    • Capability matrix defines what is allowed on each service at execution time.
    • Together they prevent drift:
      • no silent no-op on unsupported features,
      • no adapter-specific policy branching,
      • deterministic user-visible failure reasons.

Required Inputs From Plan 1

  • Canonical event types and normalized action shapes are stable.
  • Event write path exists for ingress/outbound actions.
  • Traceability exists for diagnostics (trace_id, source transport metadata).

Scope

  • Add capability registry per transport.
  • Features: reactions, edits, deletes, threaded replies, typing, media classes, read receipts, participant events.
  • Runtime helper APIs used by router and compose UI.

Implementation

  1. Add core/transports/capabilities.py with static matrix + version field.
  2. Expose query helpers: supports(service, feature) and unsupported_reason(...).
  3. Integrate checks into core/clients/transport.py send/reaction/edit paths.
  4. Compose UI: disable unsupported actions with clear hints.
  5. Add tests per service for expected behavior.

Acceptance Criteria

  • Unsupported action never calls transport adapter.
  • User receives explicit, actionable error.
  • Service capabilities are test-covered and easy to update.
  • Capability decisions are traceable against canonical event/action context.

Out of Scope

  • Dynamic remote capability negotiation.