Real Objects, as in Alan Kay, not as encapsulation, abstraction, polymorphism, and inheritance.

OOP, to me, means only messaging, local retention and protection, hiding of state-process, and extreme late-binding of all things.

Most modern “OOP” (Java, C++, etc.) Focus on Class Types Inheritance

But Kay’s original idea was to focus on Messaging, Independent objects, Late binding, and Extensible systems.

Think about objects and messages, and not in terms of Remote Procedure Call.

We are missing key properties in our current Objects (Notifications, Vault, Contacts, Linkbase). Because of this, our systems tend to become brittle, centralized, and difficult to evolve.

Objects are behaviours and states. Objects can be regular objects or Agents.

An object is like a small computer.

Inspired by Alan Kay, we should aim for objects that can operate at internet scale—without central coordination, and without embedding infrastructure concerns into their design.

1. The big idea is Message Passing

   In OOP, the messaging is between classes and Objects. Messaging is a Command. In Real Object is an ask. There is negotiation between autonomous objects over requests: permissions, you might need to do something else, etc., and there is an interpretation of the message/

   Intercommunication between Objects, not the syntax of Objects like classes or inheritance. The autonomous nature of Objects. We need to focus on this because this is what object-oriented programming is. Streams of messaging what to listening.

   (Protobufs are considered RPCs, or Messaging?) Interaction is message-based, not endpoint-based. Objects exchange:

   • intents

   • commands

   • events

   • not tightly coupled RPC calls.

   The vision is to imagine Life and the number of messages that pass all the time.

2. Autonomous Objects: Encapsulation.

   1. Local retention.

      Local retention refers to the idea that objects encapsulate both their data (state) and the operations (methods) that can be performed on that data. Objects maintain internal state and provide methods to manipulate or access that state, controlling how the data is used.

   2. Protection

      Protection relates to encapsulation, in which objects protect their internal data and methods from direct external access. The idea is to ensure that an object's internal state can only be modified through the defined methods, providing a level of security and data integrity.

   3. Hiding the state process

      Hiding of state-process refers to the concept of data hiding or information hiding. It means that an object should hide its internal state and implementation details from other objects or external entities. Hiding the internal workings of an object allows for easier maintenance and modification without affecting other parts of the system.

3. Objects use Identities and don't care about physical location Every Object should have a URL or IP.

   Objects do not care where they live. They communicate via identity and messaging. The transport/daemon layer handles routing, networking, and delivery.

4. Objects share their needs with the System

   Event-Driven Subscription Model, Objects declare what they need: “Notify me of X”. The system is responsible for delivering relevant events.

5. Objects need to sync we can useLog-Based Synchronization Timestamp facts are required for meaning. AI needs those AI Timestamps Facts.

   1. Objects evolve through append-only events.

      deal with race conditions. They rely on the daemon’s syncing infrastructure to:

      replicate state

      merge updates

      recover from disconnection

6. Dynamic Late Binding Semantic Negotiation Objects do not assume shared schemas. You don't know how the other side of the world is going to call something. They negotiate meaning at runtime:

   This one is so cool, but impossible to get. The experience of changing the software without having to build again. The possibility to extend the syntax without reloading. Helping to change the requirements while you interact with the software. Basically, as we can't do this, we need Schemas, plugins, importers, etc.

   1. capabilities

   2. versions

   3. interpretations

   4. loser-binding of messages to parse messages on the fly and allow human language to work.

We are still missing foundational building blocks. to make the system work But what matters now is having a clear direction—so each step moves us closer to a system that is composable, decentralized, and alive.

Real Objects are the structure that LLMs and AI want.

“The best way to predict the future is to invent it.” — Alan Kay