kickside/connection

Provider connections and reply targets for the Kickside engine — modelled as components.

What it owns

• Contracts (kickside.connection:*)
  • connection / reply_provider — per-provider, implemented by plugins (discord, telegram, github, …). The plugin supplies credentials handling, resource discovery, and reply delivery.
  • connections / reply_providers — the global registries that create/find/list/delete those resources as components, with rollback metadata on reversible operations.
• Registries — the canonical bindings for the two registry contracts.
• Shared helpers — reply_sender, attachment_ingest, and html_text.
• HTTP API — list/create/update/delete connections and discover resources.

The module owns no SQL tables. Connection state lives in components. Durable source configuration belongs to automation private state; timing belongs to cron; emitted content belongs in threads. Per-source watermarks, when needed, live with the automation/provider state that owns the source.

Authorization

Handlers perform no authentication or coarse authorization. The host mounts the endpoints on a router with token_auth + endpoint_firewall; the firewall enforces can("access", <endpoint>) and returns 401/403. In-code checks use the runtime primitives only: component.open(id, ACCESS.*) for per-resource domain access, and security.can(action, resource) for coarse capabilities owned by the host.

Dependencies

• kickside/component — connections/reply targets are components.
• kickside/uploads — attachment ingestion.

Requirements

• api_router — required firewall-protected HTTP router the admin endpoints attach to.

The module provisions no database of its own.