osFoundry / Platform
Real-time data channels
Pub/sub channels with at-least-once delivery, history replay and per-subscriber cursors.
What it is
Real-time data channels are osFoundry's messaging backbone for moving events between the moving parts of your workspace. Any producer — an agent, a running app, a code process, or a chat — publishes messages to a named channel, and every subscriber on that channel receives them. It is a classic publish/subscribe model: producers and consumers are decoupled, so you can add or remove subscribers without touching the code that publishes, and one event can fan out to many readers at once.
Delivery is at-least-once. A message that has been published will reach each subscriber even across reconnects and restarts, with the tradeoff that a subscriber can occasionally see the same message twice, so consumers should treat handlers as idempotent (key work by a message id or dedupe on a natural key). Channels keep history rather than dropping a message the instant it is read, which unlocks two things: replay, where a subscriber can re-read past messages from the channel instead of only seeing what arrives live, and per-subscriber cursors, where each subscriber tracks its own position independently. A cursor means a subscriber that falls behind, disconnects, or starts up later resumes exactly where it left off, and two subscribers on the same channel can sit at completely different points in the stream without interfering with each other.
Because osFoundry is a bring-your-own-key, local-first desktop workspace, this data plane runs alongside your work rather than through a third-party message broker you have to provision and pay per-seat for. Channels are the plumbing under features that need to react to change as it happens — an agent that watches for new items to process, an app that updates the moment upstream data lands, or a pipeline where one stage hands off to the next — and they let those pieces communicate without polling or tight coupling, while your data can stay on your device.
Key capabilities
- Publish/subscribe channels decouple producers from consumers, so one published event fans out to every subscriber without changing publisher code
- At-least-once delivery means messages survive reconnects and restarts; design consumers to be idempotent since a message can occasionally repeat
- History replay lets a subscriber re-read past messages instead of only catching live traffic — useful for late joiners and reprocessing
- Per-subscriber cursors track each reader's position independently, so a slow, restarted, or late subscriber resumes exactly where it left off
- Connects agents, apps, code, and chats over a shared local-first data plane — no external broker to provision and no per-seat fees
Use cases
- Agent builder: an agent subscribes to a channel of incoming tasks and processes each one, resuming from its cursor after a restart without missing or reprocessing work
- App developer: a workspace app subscribes to a channel and updates its view the instant upstream data is published, instead of polling on a timer
- Pipeline author: stage one publishes results to a channel that stage two consumes, with replay available to reprocess history after a logic change
Frequently asked questions
What does at-least-once delivery mean for my code?
It guarantees a published message reaches each subscriber even across disconnects and restarts, but a subscriber may occasionally receive the same message more than once. Make your handlers idempotent — dedupe on a message id or a natural key — so a repeat is harmless rather than double-counted.
Can a new or restarted subscriber catch up on messages it missed?
Yes. Channels retain history and each subscriber has its own cursor, so a subscriber that joins late or comes back after a restart can replay past messages and resume from its last recorded position instead of only seeing traffic that arrives while it is connected.
Do two subscribers on the same channel share a position in the stream?
No. Cursors are per-subscriber, so each reader advances independently. One subscriber can be caught up to the newest message while another is still working through older history on the same channel, and neither affects the other.