Set Law Applied to Context .me thinks in spaces. Not schemas. Not tables. Not object classes. A space is a region of meaning (context) that can contain other spaces. Everything else follows from set laws.
**Core Rule
**A space can contain spaces.
space ⊇ subspace ⊇ subspace ⊇ subspace
Examples:
profile is a space
profile.contact is a subspace of profile
wallet.hidden is a subspace of wallet
friends[age > 18] is a selected subspace of friends
In .me, paths are how we navigate nested spaces:
me.profile.name("Abella");
me.profile.contact.email("abella@neurons.me");
me.wallet["_"]("vault-key");
me.wallet.hidden.note("private");
Namespace
A namespace is a named space.
Examples:
self
kernel
ana
family.photos
In protocol form:
me://self:read/profile
me://kernel:export/snapshot
me://family.photos:read/2026.vacation.cover
So:
namespace names the space
selector states the operation
path identifies the subspace
Set View
We can describe a space by the sets that act on it:
A = audience set
T = topology set
C = capability set
P = path / subspace set
These are not different ontologies. They are different views of the same space.
Space Predicates
The common adjectives are just set statements:
public space: the readable audience is broadly open
private space: the audience is tightly bounded, often {self}
shared space: the audience contains more than one principal
encrypted space: readable membership is enforced cryptographically
replicated space: the topology has multiple carriers
Examples:
wallet may be a private encrypted space
family.photos may be a shared replicated encrypted space
profile.public may be a public space
No new noun is required beyond space.
Refinement
More specific spaces are subsets of less specific spaces.
profile.contact.email ⊆ profile.contact ⊆ profile
wallet.hidden ⊆ wallet
This same law appears across the system:
deeper path -> smaller semantic region
tighter audience -> smaller readable set
tighter context -> smaller resolution set
tighter capability -> smaller action set
Encryption As Membership
Encryption does not create a different universe. It creates a stricter readable membership over a space.
Examples:
a private space may have A = {self}
a shared encrypted space may have A = {me ∪ wife} The topology can be large while the readable audience stays small:
T = {home-daemon, office-daemon, phone}
A = {me, wife}
That means the same space may be replicated widely without becoming readable widely.
Why This Matters
This gives .me one ontology instead of many.
.me declares, creates, and navigates spaces
cleaker records, routes, and transports spaces
monad.ai serves, resolves, and persists spaces The system stays unified because everything still reduces to:
space inside space inside space
And all of it follows set law.
Top comments (1)
Thinking in spaces instead of schemas is a genuinely different primitive, and the part that jumped out at me is the access implication, not just the modeling one. The moment context is a containment hierarchy with selected subspaces (wallet.hidden, friends[age > 18]), you've also described a permission model: "what can this caller see" becomes "which subspace are they scoped to," and that's exactly the question that matters when an AI agent operates over someone's data. Most systems bolt access control on after the fact; modeling it as set membership from the start means the boundary is the data structure, not a separate rules layer that can drift out of sync. That's a clean answer to a problem I think about constantly, agents need to reason over context without being handed the whole space, so scoping to a subspace is both the retrieval story and the security story at once. This containment-as-permission idea maps tightly onto how I approach agent context in Moonshift. Is .me enforcing the subspace boundary at access time, or is it primarily a navigation/modeling convention right now and enforcement is layered on top?