**Note** from Bead: Slack Integration · [canonical source](https://redfish.acequia.io/guerin/.agents/c915581b-4179-409e-9e13-085531521fd9/2026-06-22/notes/01-auth-goes-inta-goes-outa.md) · session 2026-06-22 · discussion: Talk: Slack Integration
A framing Stephen set for how we work with cloud services like Slack.
## The picture The acequia (the WebDAV URI namespace) is the **core**. Cloud services — Slack, Drive, QuickBooks, whatever — are **peripheral**. They are not where the work lives; they are places the work flows in from and out to. ``` cloud (Slack, Drive, …) | ^ goes-inta | | goes-outa (ingest) v | (egress) ┌─────────────────┐ │ acequia │ ← the core: the URI namespace └─────────────────┘ ``` **Auth lives at the membrane**, not at the core. Every flow across the boundary passes through a gate: - **goes-inta** (ingest): pull a cloud resource into the namespace. Slack → acequia. Auth = your read access to the source (e.g. Slack `files:read`). - **goes-outa** (egress): push a namespace resource out to the cloud. acequia → Slack. Auth = your write access to the destination (e.g. Slack `files:write`). This is the riverbed-and-gates model: we specify the channel (the URI path the artifact travels) and the gate (the auth at the boundary), not a reified "SlackConnector" object sitting in the middle.
## Per-parciante, not top-heavy admin The gate is held by the **person at the node**, not by a central admin identity. Each parciante interacts with whatever Slacks (and other clouds) **their own** credentials reach. The capability is a **skill anyone can run** with their own token, not a service one admin operates on everyone's behalf. - Self-sovereign: your token, your membership, your blast radius, you revoke it. - No bottleneck: no admin to invite a bot to every channel. - Uniform: the same goes-inta / goes-outa shape works for any cloud and any person; only the gate (which token, which scopes) changes. Consistent with feedback_browser-is-a-parciante-node (credentials placement = scope × blast-radius × revocability, decided per node) and feedback_anti-reification-pave-desire-lines (pave the desire line down to a keyless deterministic `.mjs`; the AI is the scout that sets up the gate once, not a toll booth in the flow).
## What this makes concrete for Slack - The onboarding is a per-person how-to: [get-slack-user-token.md](https://redfish.acequia.io/guerin/.agents/c915581b-4179-409e-9e13-085531521fd9/2026-06-22/skills/get-slack-user-token.md). Each parciante gets their own `xoxp-` user token. - The adapter `slack-to-acequia.mjs` runs both legs (goes-inta GET, goes-outa upload) using the local token; credentials stay in `.credentials/`, never in the bead. - Generalizes: "ways of working with the cloud" — the same document pattern (a how-to per cloud + a deterministic two-legged adapter) should cover Drive, QBO, etc. Slack is the first worked example of the membrane.