Why this shape
Most messaging vendors ask you to route your customer conversations through their cloud. CodeB flips the model. Your Meta app credentials, your Booking partner key, your Airbnb host token — they all live in the same per-tenant folder as your call recordings and your transcripts. If a channel provider changes terms, you rotate the credential and keep every past message. If you need to leave, the export is a folder copy.
BYO app credentials
You register with Meta / Booking / Airbnb yourself and drop the keys into the tenant folder. CodeB never sees anyone else's tokens.
Filesystem-only storage
Every thread and message is a JSON file under App_Data/<tenant>/xmpp-channels/. NTFS-atomic writes with .backup sidecars. Disaster recovery is a folder restore.
Per-tenant isolation
No cross-tenant reads. Sanitised slugs at the path resolver, defense-in-depth at every endpoint, superuser bypass logged loudly.
Standards-compliant core
The message schema is a strict subset of XEP-0227 semantics. Any past XMPP archive imports cleanly; any future XMPP export leaves cleanly.
What ships today
The plumbing is proven and running on real tenants. Channels arrive one at a time as we sign up for each provider's API.
Common foundation
Per-tenant path resolver, atomic JSON writer, canonical ChannelMessage schema, thread meta, HMAC verifier, metering + license hooks. Every real channel plugin sits on top.
Simulator channel
Walking-skeleton bridge that exercises the pipeline end-to-end without any external API. Useful for smoke tests, operator training, and integration testing before your real API keys arrive.
Email (next round)
SMTP + IMAP bridge that treats an email thread as one channel thread. Uses the pickup-dir SMTP pattern already in your bridge for outbound.
Admin console
Operator UI at /chat-channels.html. Config panel, thread list, message viewer, simulate-inbound + send forms, mark-read, and superuser-only GDPR erasure.
Channel roadmap
Every row that isn't marked "live today" needs credentials with the channel provider. When you have them, we ship the plugin.
| Channel | Status | Open protocol? | When |
|---|---|---|---|
| Simulator Walking skeleton, no external calls. | Live today | N/A | Today |
| Email (SMTP + IMAP) One IMAP mailbox per tenant, one SMTP send channel. | Next round | Yes | This round |
| SMPP / SMS Direct SMSC or aggregator. | Next | Yes | Next |
| Telegram Bot API, per-tenant bot token. | Next | Yes | Next |
| WhatsApp Business Meta Cloud API, HMAC X-Hub-Signature verification. | Q3 2026 | No | Q3 2026 |
| Booking.com Partner API messaging. | Q3 2026 | No | Q3 2026 |
| Airbnb Host API messaging. | Q4 2026 | No | Q4 2026 |
| Matrix Federated real-time messaging. | Q4 2026 | Yes | Q4 2026 |
| Instagram DM Meta. | Q4 2026 | No | Q4 2026 |
| Facebook Messenger Meta. | Q4 2026 | No | Q4 2026 |
| Slack Web API workspace bridge. | Q1 2027 | Partial | Q1 2027 |
| Microsoft Teams Graph API. | Q1 2027 | No | Q1 2027 |
| Google Business Messages Google conversational surface. | Q1 2027 | No | Q1 2027 |
| Apple Messages for Business Apple Business Register + MSP. | Q1 2027 | No | Q1 2027 |
| IRC One IRC channel = one thread. | On demand | Yes | On demand |
| Mattermost / Rocket.Chat / Zulip Self-hosted open messaging platforms. | On demand | Yes | On demand |
| WeChat / Line / KakaoTalk / Viber Regional dominants; ToS + local presence requirements. | On demand | No | On demand |
| RCS Carrier-controlled; access varies by country. | TBD | Partial | TBD |
| Signal Open protocol; commercial-use ToS review pending. | Deferred | Yes | Deferred |
How each new channel plugs in
A channel plugin is a small transport module. It subclasses the shared config, verifies the vendor's inbound signature, builds the canonical ChannelMessage, and hands it to the shared store. Outbound calls the vendor API only when dry-run is off. Every step is LOUD-logged so an operator can trace any conversation end-to-end.
1. Config subclass
Add the fields the channel needs (Meta app id, Booking API key, etc.) on top of the shared enabled / dry-run / rate-limit base.
2. Inbound handler
Parse the webhook or the IMAP fetch, verify HMAC, build a ChannelMessage, call the store.
3. Sender
Respect dry-run, call the external API, update Status. Store persists both dry-run and real sends.
4. REST + UI
Copy the Simulator .ashx + admin.html pair; every channel gets its own small operator page with the same shape.
Frequently asked
Do I need to give CodeB my Meta / Booking / Airbnb API key?
No. CodeB is deployed inside your infrastructure. You register your own app credentials with the channel provider and drop them into the per-tenant config folder. CodeB never sees API tokens for any account other than yours.
Where does CodeB store my messages?
On your IIS filesystem, under App_Data/<tenant>/xmpp-channels/<channel>/. Every write is NTFS-atomic (File.Replace) with a .backup sidecar. There is no database dependency, so disaster recovery is a folder restore.
What happens when I disable a channel?
Inbound webhooks stop being processed and outbound sends refuse. Existing threads and message history remain readable in the admin console. Nothing is deleted until an operator with erasure rights runs the GDPR delete-thread action.
Can I export my message history?
Yes. The on-disk JSON layout is a strict subset of XEP-0227 semantics, so a per-tenant XML dump is a small transform. You are never locked in to CodeB and never at risk of vendor lock-in from your channel providers either.
Built by the CodeB team at Aloaha Limited. Every messaging surface is designed with NIS2, DORA, the EU Cyber Resilience Act and GDPR in mind — the same posture that governs the rest of the CodeB stack. Nothing on this page implies certification; it describes the sovereign-by-design defaults you inherit when you deploy CodeB inside your own infrastructure.