↗Carrier Chat
Open-source proof of concept

Make the message ordinary. Make the mechanism visible.

Carrier Chat is an inspectable research demo exploring how context-aware text can carry a second, encoded message while still reading like an everyday conversation.

Built for learning. Local phrase banks, server-side breakdowns, and a deliberately honest view of the trade-offs.

carrier-flow / inspectable
visible conversation
I can send the notes over after lunch if that still works for you.
→
Context, role, and topic stay in view.
server-side inspection

A teaching interface for observing selection, payload packing, and decoding—not a claim of perfect invisibility or production-grade security.

A small system with the important parts left on the table.

The dashboard is designed to make the pipeline easy to inspect, test, and improve rather than hide it behind a black box.

01 / CONTEXT

Conversation-aware carriers

Topics, roles, locations, and phrase choices give each visible turn a conversational setting instead of producing isolated text.

02 / PAYLOAD

Optional embedded data

A turn can remain an ordinary message, or carry a small payload for the demo to pack, embed, and inspect.

03 / EVIDENCE

Breakdowns you can follow

Send and decode views expose the selected role, slots, payload state, and carrier segments so behaviour can be examined directly.

From a broad idea to an inspectable experiment.

The direction changed as each failure became useful evidence: reliability, naturalness, efficiency, and privacy all had to be visible in the same demo.

The starting point
Create a communication system that uses AI to hide an encrypted message inside an ordinary-looking text message.

The original idea combined a normal conversation, a hidden payload, context-aware language, and recipient-only recovery.

Reliability became a feature
If its not possible to encode the secret message into the carrier, throw an error, dont just append repeated text.

That moved the project away from pretending every carrier was successful and toward explicit capacity checks, validation, and visible failure.

The model question
What about using a super lightweight offline LLM that can be configured to do this, then all that's needed is a shared secret such as the seed.

The experiment explored local inference, deterministic generation, probability-based selection, and the practical limits of laptop hardware.

The phrase-bank turn
fully implement the phrase bank with openai, I dont want to use the statistical method anymore as its too unreliable

The design then shifted toward structured, inspectable language banks with topic and role control instead of relying on fragile model replay.

The current direction
Make the messages better by not making it lots of short sentences but instead one legit looking long message?

Recent work focuses on coherent conversation, varied roles, local place choices, server-side state, key handling, and language quality that can be evaluated rather than assumed.

A deliberate boundary
No dont use the API. I want you to generate it and upload it to the server for me.

The phrase-bank path is now designed to be locally reproducible, with the source data and generation process kept available for inspection.

What this project is

  • An open-source proof of concept.
  • A practical playground for language, encoding, and interface ideas.
  • A place to compare capacity, readability, and reliability.
  • A deliberately inspectable demo for discussion and experimentation.

What it is not

  • A guarantee of undetectability.
  • A replacement for established secure messaging.
  • Protection against rewriting, paraphrasing, or hostile analysis.
  • A production security review or a promise of operational safety.

See the mechanism.

Register a local account, choose a conversation, and inspect a complete turn from carrier to decoded payload.

Enter the dashboard