Rethinking the Internet: What If We Stopped Asking and Started Sharing?

Every app you've ever used works the same way. Your phone asks a server for data. The server responds. You see the result. This request-response pattern is so fundamental that we've built the entire internet on top of it.

But what if there's a better way?

The Problem Nobody Talks About

Think about how Google Docs works. You type something, and it appears on your colleague's screen almost instantly. Under the hood, there's a constant back-and-forth happening. Your browser asks the server for updates. The server sends back changes. It works, but it's exhausting.

Now imagine you're building something more complex. A fleet management system where trucks, warehouses, and dispatchers all need to see the same data at the same time. Traditional APIs start to crack under this pressure. Every update means a new request. Every request means waiting. Every wait means someone might be looking at stale information.

The request-response model wasn't designed for this kind of real-time, multi-party collaboration. It was designed for a simpler time, when browsers fetched documents and servers delivered them.

A Different Way to Think

What if, instead of asking for data, you could just... join it?

Picture a document that exists everywhere at once. Not copies of a document, but the same document, simultaneously present on your phone, your laptop, and your colleague's tablet. When you edit it, everyone sees the change. Not because you sent them a request, but because the document itself knows how to propagate changes.

This is the idea behind what some call "living objects." They're not just data structures. They're distributed containers that hold state, record changes, sync across devices, and enforce rules about who can do what.

No more asking. Just sharing and evolving.

How It Would Work

In this model, interaction looks different:

1. Subscribe: Join a shared object
2. Sync: Continuously exchange state
3. Update: Make changes locally
4. Converge: Let the system resolve differences

There's no "server response" because there's no server in the traditional sense. Every participant holds part of the state. Changes propagate naturally. The system converges to consistency over time.

This isn't science fiction. It's built on well-established distributed systems principles:

• CRDTs (Conflict-free Replicated Data Types) let concurrent changes merge without conflicts
• Vector clocks track who changed what and when
• Gossip protocols spread updates efficiently across nodes
• Eventual consistency ensures everyone arrives at the same state

The Object Participation Network

One concrete proposal for this is the Object Participation Network (OPN). It defines how nodes interact with shared objects through simple message types:

• JOIN — participate in an object
• OP — apply a change
• SYNC — reconcile state
• GOSSIP — propagate updates
• VERIFY — validate authenticity

Think of it like editing a shared document, but at the infrastructure level. No API calls. No backend coordination. Just continuous synchronization.

Why This Matters Now

We're at an interesting moment in software. The tools we're building are becoming more collaborative, more real-time, and more distributed. AI agents are starting to act on behalf of users, making decisions and taking actions across multiple systems.

The request-response model wasn't designed for this world. It assumes a clear client-server boundary. It assumes the client initiates and the server responds. It assumes state lives in one place.

But modern applications blur these lines. Your phone is sometimes a client, sometimes a server. Data lives in multiple places. Updates happen from multiple sources. The old model still works, but it's showing its age.

The Reality Check

This approach isn't without challenges:

Conflict resolution: When two people edit the same thing simultaneously, how do you merge those changes? CRDTs help, but they're not magic.

Offline support: What happens when a device disconnects for hours? You need a strategy for rejoining and catching up.

Security: If there's no central server, how do you enforce permissions? Trust has to be embedded in the data itself.

Scalability: Keeping everything synchronized across thousands of devices is expensive. The system needs to be smart about what gets synced and when.

Looking Forward

The request-response model isn't going away. It's too useful, too well-understood, and too embedded in how we build software. But it's not the only option anymore.

As systems become more distributed, more real-time, and more collaborative, we might see more applications move toward shared state models. Not replacing APIs entirely, but complementing them for use cases where continuous synchronization makes more sense than constant polling.

The internet was built on asking and answering. Maybe the next version will be built on sharing and converging.

---

_This post explores ideas from Rethinking the Internet: Designing a Post Request-Response Protocol, originally published on Medium._