Architecture

Reactive Subscriptions

The subscription is the fundamental operation of the paradigm. Not the API call. Not the file download. The subscription. Everything is a subscription — your bank transactions, your health records, your social feed, your software tools. You don't fetch. You subscribe.

The old way: fetch and pray

In the current paradigm, getting data means making a request. Your application calls an API endpoint. The server responds with a snapshot of the data at that moment. Then you poll again to check for changes. Then you handle rate limits, caching, stale data, and synchronization conflicts.

This model is fundamentally pull-based. The consumer is responsible for knowing when data has changed. The server is passive — it waits to be asked. Every request is a bet that the response will still be valid by the time you process it. The more real-time the data, the more frequently you have to poll. The more you poll, the more load you create. The entire edifice of webhooks, WebSockets, server-sent events, and change data capture exists because the base model — request-response — is wrong for a world where data changes continuously.

Subscriptions reverse this. The consumer subscribes once. The publisher pushes changes as they happen. The consumer doesn't poll. The consumer doesn't refresh. The data is always current because the subscription is a live connection.

How subscriptions work

Publication

An actor publishes a stream — a structured data feed that other actors can subscribe to. The publication defines the schema, frequency, and terms of access.

Discovery

Actors discover available streams through the substrate. Each stream has a unique cryptographic identity, making it verifiable and findable.

Subscription

An actor requests access. The publisher grants it — with explicit terms: what data, for how long, under what conditions.

Mounting

The subscribed stream is mounted in the subscriber's selfspace. It appears as local data — queryable, combinable, transformable — but it's still a reference to the source.

Reactivity

When the source changes, the change propagates to all subscribers. No polling. No refresh. The subscription is a live connection.

Caching

For performance, subscribed data can be cached locally. The cache is always subordinate to the subscription — the source is always authoritative.

Concrete example: banking

Today: You log into your bank's website. The server queries its database and renders a page with your recent transactions. You see a snapshot. If a transaction happens while you're looking, you won't see it until you refresh. To get your data into another tool, you download a CSV — a copy that will be stale within minutes.

With Inflect OS: Your bank publishes a transaction stream. Your selfspace subscribes. The transactions appear in your financial view as live data — not a screenshot, not a CSV, but structured records you can query, filter, and combine with other streams. When a new transaction posts, it appears instantly. You never refresh. You never download. You subscribed.

Subscriptions are not just about data. Software, tools, and even the operating system itself are distributed through subscriptions. Your device subscribes to its drivers from the manufacturer. Your selfspace subscribes to rendering tools from providers. The OS kernel itself is a publication that your hardware subscribes to.

“The subscription is the fundamental operation of the paradigm. Not the API call. Not the file download. The subscription. Everything is a subscription.”

Next: Cryptographic Identity →