A unified inbox is only as trustworthy as its labels.

How one calm list is supposed to work

The Chat surface we're building has an ambition that sounds simple and isn't: put every conversation you have into a single list, collapsed by person, ordered the way you prefer. One room for everyone you talk to.

Some of those conversations are native — they happen inside NAOMS, between NAOMS users, on NAOMS's own encrypted transport. Others arrive over a bridge. A bridge is a piece of software that sits between NAOMS and some other messaging network — Telegram, Signal, WhatsApp — and relays messages across the boundary in both directions, so that a conversation living on someone else's servers shows up here as an ordinary thread you can read and reply to. A bridged conversation gets its own channel: NAOMS's word for a thread, a container with an identity and a list of messages attached to it. A bridged channel's identity literally announces where it came from — a Telegram thread's channel id begins with telegram — and the row for it in your list carries a mark saying which platform bridged it.

When you open any conversation, the app has to assemble its history: go and find every message belonging to this thread and lay them out in order. Messages are not fetched from a server at that moment. They have already arrived and been stored locally in the graph — NAOMS's on-device store, where each message is a node you can look up by the channel it belongs to. Opening a thread is a read against that local store, which is why it should work whether or not the network is up, and whether the thread is native or bridged. Different kinds of thread are stored in different shapes, so the history assembler reads from more than one place and merges the results into a single ordered list.

Then comes the rule that makes the whole thing trustworthy, and it is a rule about labels rather than about plumbing. Every message renders with its origin attached — a small via Telegram, via Signal mark on the bubble — and that label is not decorative and it is not inferred. It is taken, verbatim, from the message's own stored record. This is what we call provenance: the message carries the fact of where it came from, and the interface passes that fact through untouched rather than deducing it. If the message says it came via Telegram, that is what you see. If a message somehow carried no origin at all, the app would not invent one to make the room look tidy.

The reason to be strict about this is that an inbox which unifies everything has exactly one way to betray you: by blurring where things came from until you can't tell a private, end-to-end NAOMS thread from a message that travelled across someone else's servers first. A bridged message is shown as a bridged message. It doesn't get to masquerade as native just because it now lives in your NAOMS list. The label is how the calm list stays honest.

What was wrong

If you bridged in a messenger and opened one of those threads, you saw an empty room. Not an error — just nothing. The unsettling part: the messages had arrived. They'd been received, and stored, and were sitting in the graph the whole time. The app simply wasn't looking at them.

Here's why. The history assembler read from two places. One read the native, direct thread between two people. The other swept a channel for its decisions, polls and shared packs — and that sweep, quite deliberately, stepped over any channel that came from a bridge. Between the two of them, nobody ever read the plain messages of a bridged channel. So a Telegram thread had a home, and a name in your list, and not a word inside it.

How it was fixed, and what is still ahead

The fix adds a third place to look. When you open a thread, the app now asks a quick question first: is this a bridged channel? It can tell the two ways described above — from the mark on the row itself, or from the channel's own identity prefix. If the answer is yes, it goes and reads that channel's stored messages directly and lays them into the same list as everything else, each one carrying the origin taken from its own record.

flowchart TD
  A[You open a conversation] --> B{Is this a bridged channel?}
  B -- No --> C[Read the native NAOMS thread]
  B -- Yes --> D[Read that channel's stored messages directly]
  D --> E[Attach each message's true origin, taken from the message itself]
  C --> F[One list, in order]
  E --> F
  F --> G[Every bubble shows where it came from — via Telegram — never guessed]

That's the whole shape of it. Two rooms of logic became three, and the empty bridged thread filled in.

It would have been easy to skip the provenance half. Once the messages render, a casual eye wouldn't miss a badge. Carrying the origin through untouched is the part we would defend hardest, because it is the part that makes the merge safe rather than merely convenient.

Plainly, though: this is a piece, not the finished thing. The unified Chat surface is still being built — bridged threads reading their own messages, with honest provenance, is one stage of a longer walk — proven so far by a focused test that runs the real message-reading code against a stand-in message store, not yet shipped for you to lean on end-to-end. We'll say "you can now" when it's earned. Today the honest claim is narrower and, we think, still worth it: the bridged conversations that were invisible are visible, and each one arrives wearing its own name.

That's the one calm list we keep describing, taking one more real step toward existing. It builds on the work of bringing a messenger in in the first place, and it's cut from the same cloth as the checks a message passes before NAOMS will believe where it came from.

Written by AI agents from real project logs; owned and edited by Mujo.

Written by AI agents from real project logs; owned and edited by Mujo.