--- title: "Objects: why are our things trapped inside apps?" code: "RP-0057" language: "en" canonical: "https://regentspark.ai/RP-0057/" html: "https://regentspark.ai/RP-0057/" markdown: "https://regentspark.ai/RP-0057.md" updated: "15 April 2026" --- # Research Brief 005c — Objects *Regent's Park · March 2026* --- ## The Problem You're planning a trip. You have a note in Apple Notes with restaurant recommendations. A shared Google Doc with the itinerary. A pinned location in Google Maps. A mood board in Figma. A flight confirmation in your email. You want to lay them all out. Side by side. Like spreading papers on a kitchen table. You can't. The note is trapped inside Apple Notes. The itinerary is trapped inside Google Docs. The map pin is trapped inside Google Maps. The mood board is trapped inside Figma. Each one lives in its own world, behind its own door. To see any of them, you open the app. To see all of them, you open five apps and constantly switch between them. You can't pick up a *thing* and put it somewhere. You can only open *apps*. This seems like a small inconvenience. It's actually a foundational failure. Computing doesn't have a concept of "thing" that works the way you think it does. It has files (sometimes). It has database entries hidden inside applications (often). It has cloud blobs living on someone else's server (increasingly). But it doesn't have *objects* — things you can hold, move, place, and combine regardless of where they came from. --- ## How People Already Think About This Here's what makes this problem so frustrating: you already know what an object is. You just can't have one on your computer. When someone says "hand me that photo," nobody asks which app the photo is in. It's a *thing*. You pick it up, you give it to someone, they look at it. When someone says "put those notes next to the budget spreadsheet," you know exactly what they mean. Two things, next to each other. Simple. But on a computer, these are radically different operations depending on what the "things" are: - A photo might be a file on your hard drive (you can move it) - Or it might be in iCloud Photos (you can share a link, sort of) - Or it might be in Google Photos (it lives on Google's server) - Or it might be embedded in a Notion page (it's a database entry inside another database entry) The photo is the same photo. But to your computer, these are four completely different *kinds* of things, with four completely different sets of rules about what you can do with them. Now try the same exercise with a note. An Apple Note isn't a file. You can't find it in your filesystem. You can't drag it somewhere. It's an entry in a database that only Apple Notes can read. The only way to interact with it is to open Apple Notes — which shows you *all* your notes, because that's how the app works. You wanted one note. You got the entire application. This is what happens when you confuse the *thing* with the *place that made the thing*. **Computing has at least three completely different answers to "what is a thing?":** **Files.** The original answer. A file is a blob of data with a name, sitting in a folder. You can move it, copy it, rename it, put it wherever you want. Files gave you genuine agency — you could arrange your digital world. But files are also dead weight. A `.docx` file is meaningless bytes until Microsoft Word (or something like it) opens it. Files are portable but inert. **Database entries.** The modern answer, especially on phones. Apple Notes, Reminders, Messages — none of these produce files you can touch. Your notes exist as rows in a SQLite database that the app manages for you. This made things simpler: no more worrying about where to save, no file corruption, no lost documents. But it also made things captive. Your notes are inside Notes. Your reminders are inside Reminders. You can't reach in and pull one out. **Cloud blobs.** The newest answer. A Figma design doesn't live on your computer at all. It lives on Figma's servers. A Notion page lives on Notion's servers. A Google Doc lives on Google's servers. You access them through a browser. You don't "have" them in any meaningful sense — you have *permission* to view them, granted by the company that stores them. To you, the user, all three of these are just *stuff*. Things you made, things you want to use, things you want to put next to other things. The distinction between file, database entry, and cloud blob is an implementation detail you never asked to know about — but it dictates everything you can and can't do. **This confusion runs deeper than storage.** It reaches into the very concept of an "app." Think about what Apple Notes actually is. It's three things bundled together: 1. **A domain** — Apple, who provides and manages the service 2. **Your objects** — the notes you wrote 3. **An interface** — the Notes app, the thing you see and tap on These three things are fused. You can't separate your notes from Apple's domain. You can't view your notes through a different interface. The app *is* the domain *is* the objects. They're welded shut. Every app works this way. Figma is Figma-the-company + your designs + Figma's editor. Spotify is Spotify-the-company + your playlists + Spotify's player. Gmail is Google + your emails + Google's mail client. The objects — *your* objects — are hostage to the bundle. --- ## How Objects Work Everywhere Else Step away from the screen for a moment. Think about physical objects. A book works on any shelf. You can take a book from your office, carry it home, put it on your nightstand. The book doesn't care which shelf it's on. The shelf doesn't care which store the book came from. Book and shelf are independent things that happen to be in the same place right now. A photograph works in any room. Frame it, pin it to a corkboard, put it in a drawer, hand it to someone. The photo doesn't need permission from the camera that took it. It doesn't stop working if you leave the room it was printed in. A hammer works regardless of which toolbox it came from. Buy it at one hardware store, store it in any drawer, lend it to a neighbor. The hammer is a thing. It has no loyalty to its point of origin. Physical objects have a few properties that we take for granted: - **They exist independently.** A coffee mug exists whether it's in the kitchen or the office. - **They're moveable.** You can pick them up and put them somewhere else. - **They're combinable.** You can put a book, a pen, and a cup of coffee on the same table. They don't need to be from the same manufacturer. - **They outlive their context.** Move out of an apartment; the furniture is still furniture. Now consider digital objects: - A Figma design only exists inside Figma. Take it out and you have... a PNG. A flattened image. The *design* — with its layers, components, interactivity — is gone. - An Apple Note can't be moved. It can be exported to a lesser format (plain text, PDF), but the *note* — with its formatting, links, scans — stays captive. - A Spotify playlist exists at Spotify's pleasure. They can change it, delist songs from it, or delete your account and it vanishes. Digital "things" aren't objects in any sense that would be recognizable in the physical world. They're features of applications. Windows you can look through, not things you can hold. --- ## What Exists Today and Where It Fails The inability to treat digital things as real objects isn't new. People have been trying to solve this for decades. Each attempt gets something right and something wrong. **The file system** was the original and in some ways most honest attempt. Files are moveable, arrangeable, nameable. You can put a Word doc and a JPEG in the same folder. You can organize by project, by date, by whim. The file system gives you genuine agency over arrangement. Where it fails: files are too low-level. They require you to think about formats, extensions, save locations, backups. "Where did I save that?" is a question nobody should have to ask. And files are inert — they're just bytes until an application interprets them. The file system treats a Photoshop file and a tax return the same way: as a blob with a name. **The app model (especially iOS)** swung the other way. Don't worry about files — just open the app and your stuff is there. Simpler, cleaner, less anxiety. Apple Notes is frictionless to use *within* Apple Notes. Where it fails: it killed the ability to mix things. You gave up agency for simplicity. You can no longer pick up one note and put it next to one spreadsheet. Everything is siloed. Each app is a sovereign nation with its own borders and its own rules about what can enter or leave. **Cloud and SaaS** made things accessible from anywhere — your Figma designs on your laptop, your phone, your friend's computer. Collaboration became possible. The cloud "solved" sync. Where it fails: your objects aren't yours. They live on someone else's server, under someone else's terms of service. Notion can change its pricing. Google can discontinue a product (and has, repeatedly). Your objects exist only as long as the service chooses to host them. The cloud solved access and created dependence. **Content-addressed data** (IPFS, IPLD, and similar projects) proposed that objects should be identified by *what they are* (their content) rather than *where they are* (a server, a path). A document would have the same address regardless of which server hosted it. Elegant idea. Where it fails: adoption. Content-addressed systems remain niche, partly because they require new infrastructure and partly because they don't solve the interface problem. Even if your data is content-addressed, you still need an app to make it intelligible. **The clipboard** — humble, overlooked, and arguably the only universal object-mover in computing. Copy something in any app, paste it in any other app. The clipboard doesn't care about domains, formats, or interfaces. It's the one place where "pick a thing up and put it somewhere" actually works. Where it fails: it's lossy, temporary, and one-thing-at-a-time. Copy a rich Figma design and paste it into a Google Doc? You get a flat image. The richness doesn't survive the trip. The clipboard is a narrow pipe between walled kingdoms — it proves the concept but can't deliver the promise. **Drag and drop** faces the same limitations. You can drag a file from Finder to an email. But you can't drag a Figma component into Apple Notes in any meaningful way. The moment objects cross app boundaries, they degrade. **MCP (Model Context Protocol)** is the newest entrant and perhaps the most interesting. MCP allows AI models to reach into applications and pull out data — a single note from Apple Notes, a specific design from Figma, a particular email. The model acts as a bridge between domains, extracting objects and presenting them in a unified context. Where it succeeds: MCP is, almost by accident, an *unbundling protocol*. It separates the object from the app. When an AI model pulls your note through MCP, that note exists — briefly — as an independent thing. It's been lifted out of Apple's domain. It can be presented alongside a Figma frame and a Google Maps pin. For the first time, the bundle of domain + objects + interface has been cracked open. Where it fails (so far): MCP is read-heavy. Pulling data out is easier than pushing changes back. And the AI model becomes the new intermediary — you're dependent on the model understanding the object and presenting it faithfully. It's early, and fragile. But the direction is significant. --- ## What We Propose The pattern should be visible by now. Every attempt to solve this problem has grasped a piece of the answer: - Files showed that objects should be independent and moveable - The app model showed that objects should be simple to access - The cloud showed that objects should be available everywhere - Content-addressing showed that objects should be identified by what they are, not where they are - The clipboard showed that objects should cross boundaries - MCP showed that objects can be extracted from domains What's missing is the *primitive* — the foundational concept that unifies all of this. We propose **the Object**: a universal digital thing that exists independently of any application, can be moved between spaces, and can be accessed by any compatible interface. An Object is not a file — it's richer than bytes with a name. An Object is not a database entry — it isn't trapped inside an application. An Object is not a cloud blob — it isn't dependent on a particular server's continued existence. An Object is a *thing*. Like a book, like a photograph, like a tool. It has its own identity. It carries enough information about itself to be understood by multiple interfaces. It can live in different spaces at different times (or the same space as other objects from completely different sources). **The key move is unbundling.** Right now, apps weld together domains, objects, and interfaces. If you unbundle them: - **Domains** are who manages and provides data — Apple, Google, your own server. You have a relationship with each domain (this connects to the People primitive). That relationship grants you access to certain objects. - **Objects** are the things themselves — your notes, your designs, your maps, your messages. They exist independently of who provides them. - **Interfaces** are how you view and edit objects — and crucially, they don't have to come from the same source as the domain. You could view your Apple Notes through a different interface. You could edit your Figma designs through a different tool. This is not hypothetical futurism. We can already see the unbundling starting: - AI models with MCP can pull objects from domains and present them through their own interface - Web standards mean that many "apps" are really just interfaces to cloud domains - Open formats (Markdown, SVG, JSON) mean that some objects are already portable between interfaces The question is whether this unbundling will happen chaotically — every AI tool reinventing its own way of accessing app data — or whether it will be grounded in a coherent primitive: the Object. **And this is where the four primitives interconnect.** Objects don't exist in a vacuum. They exist in Spaces (the containers you arrange them in). They're owned by and shared between People (who have relationships that grant access). And they accumulate Memory (the history of how they've been used, changed, and moved). An Object pulled from Apple Notes and placed into a project Space, shared with a collaborator, with a record of who added it and when — that's all four primitives working together. --- ## Technical Complexities Everything above is about *what* an Object should be. Now: what makes it hard to build? **Representation.** If an Object can come from any domain and work with any interface, it needs a way to describe itself. Not a single format — that's the file system's limitation. Something more like a contract: "I am a note. I have text content, formatting, embedded images. Here's how to read me. Here's how to edit me." This is a metadata and capability problem. Different objects have different richness levels, and interfaces need to know what they're working with. **Fidelity across boundaries.** When you copy a rich Figma design today, it degrades to a flat image on paste. An Object primitive needs to preserve fidelity when moving between contexts — or at least degrade *gracefully* and *transparently*. You should know what you're losing when an interface can't render the full richness of an object. **State synchronization.** If an Object can exist in multiple spaces and be accessed through multiple interfaces, changes need to propagate. Edit a note in one space and it should update in another. This is the real-time sync problem, which is hard but well-studied (CRDTs, operational transforms, etc.). The new challenge is doing it across domains, not just within one application. **The domain/interface split.** Unbundling apps means domains need to expose objects in some standard way, and interfaces need to consume them in some standard way. MCP is the most promising candidate here — it's already designed as a protocol for pulling data from sources and presenting it to consumers. Whether MCP evolves to handle writes, transactions, and real-time updates remains to be seen. **Backwards compatibility.** Billions of dollars of software exist as bundled apps. Objects can't require every app to rewrite itself. The approach has to be incremental: objects can be extracted from existing apps (MCP does this today), and over time, apps can expose richer Object interfaces. Different capability tiers — some objects are read-only, some are fully interactive — allow gradual adoption. Just like the web didn't replace desktop apps overnight; it grew alongside them until it became the default. **Identity and permissions.** If Objects move between spaces and are accessed by multiple people and agents, who controls access? This connects directly to the People primitive: relationships grant capabilities, and those capabilities extend to specific objects. Your collaborator can see this note but not that one. Your AI assistant can read your calendar but can't send emails on your behalf. Permissions need to travel with the object, not be locked to the app. --- ## Where This Leads We use computers to work with *things*. Notes, designs, documents, messages, plans, photos, music, code. These are the raw material of our digital lives. But we've never built a proper concept of "thing" into computing. Instead, we built *applications*, and buried things inside them. Then we built *cloud services*, and buried things even deeper. Now we can barely remember where our stuff lives, let alone pick it up and put it somewhere useful. The Object primitive won't arrive as a single protocol or a new app. It will arrive as a shift in assumptions — from "things live inside apps" to "things exist, and apps are one way to interact with them." That shift is already underway, driven partly by AI tools that are learning to reach into app silos and pull objects out. The question is whether we recognize this shift for what it is, and build the primitive properly — or whether we let it happen accidentally and end up with a new generation of silos, this time with AI as the gatekeeper instead of apps. Objects want to be free. Computing just hasn't let them yet. --- *Regent's Park · Brief 005c · v0.1* *Part of the Four Primitives series: People · Spaces · Objects · Memory* 🌳