palOMine surfaces
Chat gateways.
palOMine plug-in chat adapters let one appliance talk to the platforms you already use, but on terms you control. Each gateway is a delivery bridge — outbound to a chat surface, inbound back to the local agent — running under the appliance’s own account and rules. No gateway ever reaches back to a third-party inference API.
Per-platform
Telegram · Discord · Signal.
One bridge per surface. Each gateway runs as a bounded-authority agent tied to a single platform account. Configuration is per-bridge; messages stay local; the platform never gets a key that can call back.
Telegram Bot API bridge
Available today
Telegram
One Bot API token linked to one bot identity, reachable via a webhook dialled from the appliance over outbound-only HTTPS.
Capability: 1:1 DMs · group chats · inline replies · command dispatch · voice notes transcribed end-to-end on-box
Privacy: Bot token lives on the appliance; messages persist only there; nothing about the conversation flows to Telegram beyond the round-trip itself.
Notes: Per-chat rate limits are surfaced to the agent; out-of-policy requests are dequeued rather than dropped.
Discord gateway bridge
Available today
Discord
Ties palOMine to a single Discord bot application. Same outbound-only pattern: the gateway initiates traffic, never the platform.
Capability: DMs · server channels (per-server allow-list) · slash-command dispatch · reaction-as-tool acknowledgements
Privacy: Bot credentials never leave the appliance; conversation history stays in the local store.
Notes: Per-server permissions are managed via an allow-list policy file the agent reads — no global server access.
Signal bridge
Preview
Signal
A Signal-compatible adapter for environments where the device is the only thing that should see the thread.
Capability: 1:1 and small-group messaging · voice note transcription · received-message routing to the local agent
Privacy: Messages persist on the appliance; no relay via Signal's servers beyond what the Signal protocol inherently requires.
Notes: Signal's official integration story is awkward — this bridge uses a maintained third-party binding. Marked Preview until a stable, official adapter exists.
How a chat gateway behaves
One core, three outlets.
Every gateway spans the same five surfaces.
Bounded authority
The gateway has only what its bot identity has — one platform account, the credentials it was provisioned with, nothing else. Tool calls that exceed the bridge’s scope are refused before they leave the appliance.
Message routing
Inbound messages route into the same agent pipeline as the on-device web UI. Tone, tool-use, and the appliance’s allow/deny rules apply uniformly, regardless of which surface delivered the turn.
Replies
Outbound replies take the same path the agent always uses — the gateway delivers; delivery state is recorded locally; failed deliveries are surfaced as a normal input, not as a silent drop.
Rate handling
Both per-chat and platform-wide rate limits are surfaced to the agent as ordinary inputs so sustained pressure is paced instead of dropping turns. Burst pressure is dequeued, not abandoned.
Auth flow
Auth uses platform-native mechanisms — Bot tokens for Telegram and Discord, device-linked binding for Signal — and never reuses credentials the appliance does not own. Tokens are rotated through the appliance’s local keystore; nothing is shared in plaintext.
Privacy
Messages stay local.
Gateways are delivery-only. They move bytes — in and out — between the appliance’s local conversation store and the platform’s transport. They do not request any inference from third-party APIs. They do not host a model. They do not lift message content off-device.
Conversation archives live on the appliance; a platform never sees palOMine’s prompts or tool calls, only what the bot emits the way every bot emits. If a gateway is removed, all traces it created locally are removed with it.
Composition
Composes with the rest of the platform.
A chat message is just another input to the same agent as a prompt in the web UI. A single turn can call tools over MCP, read from the local retriever, cite memory, and reply with a transcribed and routed voice note — all on-box, no third-party inference call.
The underlying models doing that work — Whisper for speech-to-text, Kokoro for text-to-speech, the embedding and rerank pair for retrieval — are listed on /models.
Wiring the bridges on your box.
The gateways are part of the first production run. Get on the waitlist and we’ll let you know when units are ready to be reserved.