---
title: "People: why are we scattered across accounts?"
code: "RP-0129"
language: "en"
canonical: "https://regentspark.ai/RP-0129/"
html: "https://regentspark.ai/RP-0129/"
markdown: "https://regentspark.ai/RP-0129.md"
updated: "3 May 2026"
---
# People: why are we scattered across accounts?
*The first missing primitive of computing is not authentication. It is personhood.*
You are one person, but your computer sees dozens of fragments: a Google account, an Apple ID, a work login, a bank profile, a WhatsApp contact, a Slack member, a calendar attendee, a passkey, a device, a browser session. Each application creates a local shadow of you and calls it identity. The result is not only annoying; it is structurally wrong. People are not accounts. A person is a persistent actor with relationships, memory, reputation, permissions, and the ability to act directly or through delegates. This essay argues that computing needs People as a primitive: a portable relationship graph that lets humans, organizations, agents, and services participate across spaces without being re-created from scratch by every app.
## You are not your accounts
> **Summary:** Computing confuses local access records with people. That forces every app to create its own little ghost of you, then leaves you to stitch the ghosts together by hand.
You have too many accounts.
Not in the abstract, productivity-guru sense. In the daily, grinding, where-the-hell-is-my-password sense. You have a Google account, an Apple ID, a work Microsoft login, a bank login, an airline account, a gym app, three social media accounts you actually use, and six you forgot about. Somewhere in there you have a password manager with hundreds of entries, each one a tiny bureaucratic relationship you have been forced to maintain.
This is usually described as an authentication problem. Passwords are bad. Passkeys are better. Single sign-on is convenient. True enough, but too small.
The deeper absurdity is that your friend Sarah exists in your phone as a contact. She also exists in WhatsApp. And Instagram. And work Slack. And email. And the shared Google Doc you are both editing. These are all the same person. Your computer has no idea.
To your phone, Sarah-in-WhatsApp and Sarah-in-email are as unrelated as Sarah and a stranger in Peru. You are the integration layer. You carry the knowledge that these fragmented digital ghosts are one person because no system you use bothers to.
Now add agents. You talk to an assistant on your phone. It knows your preferences, your calendar, your writing style, your half-finished plan. You switch to your laptop, open a different tool, and the assistant has amnesia. Same you. Different keyhole. Start over.
This is not a minor UX annoyance. It is a symptom of something missing. Computing has users, accounts, profiles, contacts, sessions, devices, credentials, wallets, keys, and handles. It does not have a durable concept of a person.
```mermaid
flowchart TD
Person(("👤 Sarah"))
Phone["📱 Phone contact"]
WhatsApp["💬 WhatsApp profile"]
Slack["🏢 Slack member"]
Email["✉️ Email address"]
Doc["📄 Google Doc collaborator"]
Calendar["🗓️ Calendar attendee"]
Person -. "same human" .- Phone
Person -. "same human" .- WhatsApp
Person -. "same human" .- Slack
Person -. "same human" .- Email
Person -. "same human" .- Doc
Person -. "same human" .- Calendar
Phone -. "not linked" .- WhatsApp
WhatsApp -. "not linked" .- Slack
Slack -. "not linked" .- Email
Email -. "not linked" .- Doc
Doc -. "not linked" .- Calendar
```
The important thing is not that one database forgot to join a few records. The important thing is that each application believes it has the right to define the person locally. It does not receive Sarah as a participant in a wider world. It mints a Sarah-shaped entry inside its own kingdom.
That is why leaving a platform feels like dying a small bureaucratic death. You do not just lose posts or files. You lose relationships, history, trust, permissions, and context, because the platform treated those relationships as its own internal state.
The account is not the person. It is only one record of one relationship between a person and a service.
> **Alt text:** A person at a desk manipulates strings connected to several floating profile cards showing the same human silhouette in different app-like contexts.
> **Description:** The image shows a person seated at a desk in the foreground, viewed from behind, with both hands holding several thin strings that extend outward to multiple floating portrait cards around the room. The cards are arranged in a loose semicircle across the left, center, and right sides of the composition, each card containing a side-profile human silhouette; some cards have small dot markers in their top corners like window or profile indicators. The strings connect from the central seated person to the different portrait cards, visually implying that one person is linked to many separate digital representations or accounts rather than a single unified identity. The desk anchors the bottom of the scene with a notebook, stacked books, a mug, a small plant, and a desk lamp, while the background remains open and uncluttered so the network of relationships is the main focus. The image communicates fragmentation: one human identity is being split across multiple app-like contexts or profiles.
> **Image source:** content/RP-0129/illustrations/people-fragmented-accounts.png
ActivityPub already distinguishes between Actors, Objects, and Activities: a person, organization, service, or application can perform actions on objects. That vocabulary is useful prior art, but it mostly lives inside federated social networking. The People primitive asks for the broader computing version: actors that can move through spaces, hold permissions, build reputation, and delegate action across many kinds of software. See Entity Ontology for the ontology survey and ActivityPub notes.
## A person is a relationship graph
> **Summary:** Identity is not a profile or a username. Identity is the living graph of relationships around an actor: what is shared, what is remembered, what is permitted, and what can be done.
You already have a better model for identity than your computer does.
You are one person. You know that. When you walk from your kitchen to your office, you do not stop being you. When you switch from talking to your mother to talking to your boss, you are still you, but a different facet of you is active. Different history. Different permissions. Different expectations.
Your identity is not a static profile. It is the sum of your relationships.
You are:
- the person your mother calls on Sundays
- the person your bank trusts with a credit line
- the person your colleague messages about the quarterly plan
- the person the barista recognizes before you order
- the person your doctor knows through medical history
- the person your assistant can wake up, interrupt, protect, or represent
Each relationship has a different shape.
**What is shared:** your mother knows your childhood; your bank knows your salary; your barista knows your coffee order. Almost no overlap.
**What is permitted:** your employer can invite you to meetings; your bank can debit your account; your friend can call late; your dentist cannot read your work documents.
**What is remembered:** your mother remembers decades; your bank remembers transactions; your collaborator remembers the argument that changed the design; your assistant remembers the preference you repeated three times.
This is identity. A graph of scoped relationships, each with its own memory, permissions, reputation, and obligations.
This connects directly to Trust at the Edges. Trust is not a universal score attached to a profile; it lives on specific relationships. You may be trusted as a seller, distrusted as a meeting attendee, loved as a friend, and unknown as a borrower. Collapsing that into one profile destroys the context that made the trust meaningful.
```mermaid
flowchart TD
You(("👤 You"))
Mother["Family\nshared history, high trust"]
Bank["Bank\nfinancial permissions"]
Doctor["Doctor\nmedical context"]
Work["Employer\nrole + duties"]
Sarah["Sarah\nfriend + collaborator"]
Agent["AI agent\ndelegated authority"]
Coffee["Coffee shop\nthin recognition"]
You -->|"can call / knows history"| Mother
You -->|"can transact / audited"| Bank
You -->|"can share medical data"| Doctor
You -->|"work role + access"| Work
You -->|"shared memory + trust"| Sarah
You -->|"acts on your behalf"| Agent
You -->|"usual order"| Coffee
```
The physical world handles this almost effortlessly. You walk into a coffee shop. You do not “create an account.” You are just there. The barista might recognize you, or they might not. If they do, the relationship activates. If they do not, you can still speak. You can push a request into the world before a deep relationship exists.
But you cannot pull anything private without permission. You can say hello to a stranger. You cannot read their diary. You can hand someone a card. You cannot enter their house. Push is cheap and permissionless; pull requires trust.
Relationships also deepen over time. You meet someone at a party. Thin edge. You exchange numbers. Slightly thicker edge. You work together. Shared memory accumulates. Eventually they may introduce you to someone else, vouch for you, or give you access to something valuable. The social graph does work on your behalf.
Computing mostly throws this away. Every app starts with a new account and asks you to rebuild the relationship graph from zero. Your history does not travel. Your reputation does not travel. Your permissions do not travel. Your friend does not travel. Your agent does not travel.
You are not bringing yourself into a new space. You are being issued a new identity card at the door of every building you enter and told to start a new life.
Legal systems have long understood “person” as a functional category, not a biological one. Corporations, municipalities, ships, estates, and sometimes rivers can be treated as persons for specific purposes: holding rights, bearing obligations, entering relationships, and being accountable. See Personhood Beyond Biology for the deeper version of this argument.
The point is not that computers should treat every entity as morally equivalent. That would be silly. The point is structural: a person is an entity that participates in a system through identity, relationships, permissions, memory, reputation, and agency.
That entity may be a human. It may be an organization. It may be an AI agent acting on behalf of someone else. It may be a service or device with narrow authority. The primitive should be able to represent all of them without pretending they are the same kind of being.
## Accounts are local shadows
> **Summary:** Existing identity systems solve pieces of the problem — authentication, portability, handles, proof, federation — but none of them carry the relationship graph itself.
The identity landscape is not empty. People have been trying to solve pieces of this for decades.
**Usernames and passwords** are the default world. Every service gives you a local identity inside its database. That identity is easy for the service to manage and miserable for everyone else. You become a row in someone else's system.
**Sign in with Google or Apple** reduces the number of passwords, but centralizes the graph. It answers “can this platform vouch that you are the same account?” It does not answer “can you carry your relationships independently of the platform?” Convenience is bought by letting a few companies see more of your life.
**Passkeys** are a real improvement. They make authentication easier and safer by replacing passwords with device-backed cryptographic credentials. But passkeys prove access to a relationship; they do not carry the relationship. Your Amazon passkey is invisible to your bank, your work tools, your agent, or your friend's collaborative space.
**DIDs and Verifiable Credentials** aim at portable identity and cryptographic proof. The ideas are important. The ecosystem is also sprawling and difficult to ship. A standard can describe portable identity without making the everyday relationship graph usable.
**Nostr** takes the radical route: you are your key. Generate a keypair and you have a portable identity across clients. This is elegant and useful, but thin. A key can sign messages. It does not by itself solve recovery, reputation, scoped disclosure, relationship memory, or delegation.
**AT Protocol and the Fediverse** improve portability inside social ecosystems, but they remain mostly social identity systems. A Bluesky handle or Mastodon account may move better than an old Facebook profile, but it still does not become the person your bank, calendar, agent, doctor, and project space can all understand.
For the broad prior-art landscape — Nostr, DIDs, ActivityPub, AT Protocol, World ID, passkeys, and the missing Actor primitive — see Identity Landscape. The important conclusion here is narrower: authentication is not identity, and identity is not yet a portable relationship graph.
One reason Nostr keeps showing up in RP notes is not that it magically solves identity. It is that it proves a useful lower layer can be radically simple: a key signs events, relays move them, clients compete above it. The Actor Stack explores how that could compose with Lightning payments, CRDT shared state, and capability-style access control. This chapter deliberately stays one layer higher.
Every one of these systems solves a fragment. Authentication. Portability. Proof. Human-readable handles. Federation. Sovereignty. Recovery. Social identity.
None solves the central problem: your personhood lives in relationships, and nothing carries those relationships across contexts.
That is why “export my data” is never enough. Your posts are not your social life. Your contacts are not your relationships. Your credentials are not your reputation. Your account archive is not the living graph of what other people know, trust, permit, remember, and expect from you.
A downloaded ZIP file is a corpse. Useful for archaeology. Useless for participation.
## Agents make the gap impossible to ignore
> **Summary:** Humans can work around fragmented identity by remembering, copy-pasting, apologizing, and improvising. Agents cannot. They need explicit identity, delegation, permissions, memory, and payment rails, or they fail.
For years, broken personhood in computing was survivable because humans are excellent glue.
We remember that Sarah on WhatsApp is Sarah from work. We copy text from one app to another. We reset passwords. We forward screenshots. We explain context. We manually grant access. We know when “Nico from Telegram” is the same Nico whose calendar says “N S.” We live inside the cracks and quietly do the integration work.
Agents are bad at this in exactly the way that exposes the architecture.
An AI assistant acting on your behalf needs to know:
- who it is
- who you are
- what relationship it has with you
- what it is allowed to do
- which spaces it may enter
- which objects it may touch
- which people or agents it may contact
- what it may remember
- what it may spend
- how its authority can be revoked
Without those primitives, agent systems become piles of API keys, OAuth scopes, brittle integrations, browser hacks, and human confirmation dialogs. Fine for demos. Not enough for a world where software participants do real work together.
The hard part is delegation. If an agent books a meeting, sends an email, pays an invoice, comments on a document, or negotiates with another agent, whose action is that? The agent's? Yours? The organization’s? The answer cannot be “whatever the current app happened to implement.”
```mermaid
sequenceDiagram
participant You as You
participant Agent as Your agent
participant Space as Project space
participant Sarah as Sarah
participant Service as Payment service
You->>Agent: Delegate scheduling authority
Note over You,Agent: scoped, revocable relationship
Agent->>Space: Enter as delegated participant
Space->>Agent: Grants access to calendar + notes
Agent->>Sarah: Proposes meeting times
Sarah->>Agent: Accepts Friday
Agent->>Service: Pays booking fee within limit
Service->>Space: Records action + proof
Space->>You: Shows what happened and why
```
This is where the old “actor” language is useful. Not every person-shaped participant is a human being. A company can act. A bot can act. A device can act. An assistant can act on behalf of someone else. What matters is not consciousness. What matters is participation with identity, relationships, authority, accountability, and memory.
“Actor” here does not mean the Erlang/Akka actor model, though there is a family resemblance. In Regent's Park language, an Actor is a persistent participant in computing: something that can be identified, related to, delegated to, trusted or distrusted, and held accountable. The technical stack version lives in The Actor Stack.
Agents make the missing primitive urgent because they cannot rely on vibes. A human can infer that “book the usual place” means the café near the office, not the sushi restaurant from last summer. An agent needs access to the relationship memory that makes “usual” meaningful. A human can decide that forwarding a sensitive message is socially wrong even if technically possible. An agent needs permissions that encode not only access, but context.
If we do not build People as a primitive, every agent platform will invent its own account model, permission system, memory silo, and delegation interface. We will recreate the account swamp, but now with autonomous actors wandering through it. That is not a future. That is a compliance incident with a UI.
## What the People primitive must do
> **Summary:** A People primitive is not a global profile or a universal login. It is a portable relationship substrate: identity plus scoped relationships, memory, reputation, delegation, and recovery.
The tempting bad answer is to build one giant identity system.
One profile. One login. One graph. One wallet. One universal directory of everyone and everything. That is the super-app trap wearing a nicer coat. It would centralize the very thing we are trying to make portable.
The People primitive should be smaller and more basic. It should make relationships legible across systems without forcing every system into one database.
Put more sharply: the primitive is not a graph export. It is a way for edges to be recognized, carried, limited, proved, and forgotten. If all we do is copy a bigger contact list between apps, we have rebuilt the same swamp with better stationery.
A useful People primitive needs to preserve three tensions at once:
- **continuity without captivity** — the actor persists, but no app owns them
- **portability without total exposure** — relationships can travel, but only the relevant claims are revealed
- **delegation without impersonation** — an agent can act for someone without pretending to be them
At minimum, it needs six properties.
### 1. Persistent identity
A person needs continuity. The same actor should be recognizable across spaces, devices, and applications without being owned by any one of them.
This probably means cryptographic identity somewhere near the base. But “use a keypair” is not the answer by itself. People lose keys. Devices break. Families share authority. Organizations rotate roles. Agents are created, paused, delegated, revoked, and replaced.
Persistence must include recovery and lifecycle, not just a permanent string.
### 2. Scoped relationships
The relationship is the unit that matters.
You do not have one identity that every service should see in full. You have different relationships with different scopes. Your doctor, bank, friend, employer, assistant, and local coffee shop should not all receive the same view of you.
A real People primitive must let each edge carry its own permissions, memory, obligations, and disclosure rules.
### 3. Relationship memory
A relationship without memory is barely a relationship.
The system should remember what has happened between two actors: trust built, promises made, failures observed, permissions granted, permissions revoked, preferences learned, context shared.
This memory cannot be only local to one app. If Sarah and you have collaborated across email, docs, chat, and a project space, the relationship should not be shattered just because the medium changed.
### 4. Reputation at the edges
Reputation is not a global star rating. It is contextual.
Someone may be a brilliant designer, a slow email responder, a reliable payer, a poor meeting participant, and a trusted friend. Flattening that into a single score destroys the very thing reputation is supposed to capture.
The useful reputation primitive lives at the edges: what this actor has demonstrated in this kind of relationship, vouched for by whom, visible under what conditions.
Credit scores, platform ratings, PGP's Web of Trust, verifiable credentials, and blockchain reputation all show different failure modes of portable trust. The recurring lesson from Trust at the Edges is that context is not metadata; context is the trust. A good system should let someone selectively prove a relationship property, not flatten the person into a number.
### 5. Delegated agency
People act through representatives all the time. A lawyer signs on behalf of a client. An employee acts for a company. A parent acts for a child. An assistant books travel for an executive.
Computing needs this pattern explicitly.
Your AI agent should be able to act for you within a bounded scope. Your organization should be able to give an employee access for a role, then remove it cleanly when the role changes. A service should be able to prove it is acting under delegated authority, not pretending to be the person behind it.
Capability systems are the technical ancestor here. Instead of asking “who are you?” and then looking up everything you can do, a capability says “this bearer can do exactly this.” Entity Ontology covers Dennis & Van Horn's capability model, Mark Miller's work, and UCAN-style tokens; The Actor Stack applies the same pattern to actors participating in shared state.
### 6. Portability without exposure
Carrying relationships does not mean dumping your entire life into every new context.
A People primitive should let you bring enough of yourself to be recognized, trusted, and useful, while revealing only what the relationship requires. The graph should be portable, but disclosure should be selective.
This is the difference between “bring yourself” and “upload your soul.” The first is civilization. The second is a product manager with no adult supervision.
Selective disclosure matters because identity is dangerous when it becomes exhaust. A bank may need proof of income; it does not need your friend graph. A bar may need proof that you are over eighteen; it does not need your birthday. A project space may need to know your agent can edit the design brief; it does not need full access to your calendar.
Verifiable Credentials and the EU Digital Identity Wallet effort are relevant here because they focus on selective proof: presenting only the claim needed for a relationship. That still does not solve relationship memory or reputation, but it is an important ingredient. See Identity Landscape and Trust at the Edges.
```mermaid
flowchart LR
Person(("Person / Actor"))
ID["Persistent identity"]
Rel["Scoped relationships"]
Mem["Relationship memory"]
Rep["Contextual reputation"]
Del["Delegated agency"]
Rec["Recovery + lifecycle"]
Apps["Apps"]
Spaces["Spaces"]
Objects["Objects"]
Agents["Agents"]
Services["Services"]
Person --> ID
Person --> Rel
Rel --> Mem
Rel --> Rep
Person --> Del
Person --> Rec
ID --> Apps
Rel --> Spaces
Mem --> Objects
Del --> Agents
Rep --> Services
```
Notice what is not on this list: one mandated protocol, one provider, one canonical database, one universal social graph, one global wallet, one reputation score.
> **Alt text:** A central person walks between multiple surrounding scenes, with lines connecting them to family, medical, work, meeting, and agent-like contexts.
> **Description:** The illustration shows a single person walking in the center foreground, seen in profile, while a small network-like object sits at their midsection and sends colored lines outward to several separate “rooms” or domains around them. On the left are two stacked spaces: a top-left living-room scene with a seated woman holding a mug, and a bottom-left clinic/doctor scene with a seated doctor using a tablet. On the right are two more stacked spaces: a top-right institutional office or bank-like desk beneath a classical façade, and a bottom-right meeting room where two people sit across a table with a laptop and notes on the wall. Behind the central walker is a tall arched opening with a tree, and near the lower center-right there is a small robot-like figure in a niche; the lines visually connect the central person to each surrounding context, suggesting one person participating in multiple systems. The image communicates that a person is not a single account but a persistent center of relationships and delegated access spanning family, work, services, and agents.
> **Image source:** content/RP-0129/illustrations/people-relationship-graph.png
The primitive is not a product. It is the shape that many products and protocols should be able to share.
## What this changes
> **Summary:** Once People exist as a primitive, Spaces become places with participants, Objects have histories of use and ownership, Memory attaches to relationships, and agents can act without pretending to be browser extensions with anxiety.
People are the first primitive because the others need actors.
A Space without People is just a container. Add People and it becomes a place where participants can enter, leave, remember, collaborate, grant access, and share responsibility.
An Object without People is just data. Add People and it can have an author, owner, steward, viewer, signer, buyer, seller, witness, and history of use.
Memory without People is just a log. Add People and memory becomes contextual: who decided, who objected, who was present, who is allowed to know, whose relationship does this belong to?
Agents without People are just tools in accounts. Add People and agents become delegated participants with identity, scope, reputation, and accountability.
This does not require every app to disappear. Quite the opposite. A People primitive should make many applications more useful by letting them stop pretending they own the whole human.
A calendar can be a calendar. A bank can be a bank. A design tool can be a design tool. A project space can be a project space. Each can relate to the same actors under different scopes without minting a full replacement identity.
What changes is the substrate underneath.
Today, apps ask: “Create an account.”
A better system asks: “What relationship are we forming?”
That one change reframes everything. Login becomes recognition. Permissions become negotiated edges. Reputation becomes contextual. Agents become delegates. Collaboration becomes participation in a shared space, not synchronized captivity inside one app.
This is why People is not merely an identity primitive. It is the actor layer for computing.
The computer should know what you already know: you are one person, the people in your life are real, and relationships should survive the software that happens to mediate them.