This document describes the core properties of .me calculus model, a user-centric declarative identity model, and explains how identity declarations generate emergent semantic spaces without predefined schemas, categories, or centralized control.
⸻
1. Overview
ME is an identity atom.
It produces signed declarations instead of fixed profile fields.
Example:
me.instrumento("Moog Matriarch")
me.color("blue")
me.tengo("synth")
No method is predefined.
Every key is accepted.
Meaning is not enforced; meaning emerges from usage.
The output is a sequence of signed, timestamped declarations that can be persisted in a ledger.
⸻
2. Key Properties
2.1 Schema-less
• No predefined fields.
• Any string can be a key (e.g., instrumento, azul, creds, folder).
• Values may be scalars, lists, or pointers to previous declarations.
2.2 Signed Declarations
Each declaration produces:
{
"key": "...",
"value": "...",
"signature": "0x...",
"timestamp": ...
}
This ensures:
• reproducibility
• tamper resistance
• deterministic identity structure
2.3 Zero Semantics Inside .me
.me does not:
• interpret meaning
• categorize keys
• manage groups
• define contexts
• impose ontology
It only declares and signs.
Semantic interpretation happens in higher layers (Cleaker, .GUI, etc.).
⸻
3. Emergent Semantic Spaces
When multiple declarations reference:
• the same keys
• the same values
• the same users
• the same contexts
they naturally form semantic clusters and spaces.
These spaces are not defined by the system.
They arise from user behavior.
3.1 First-Order Functional Space (meSpace¹)
The set of all used keys:
{ instrumento, tengo, azul, device, ... }
This forms a functional weight space, where weights can be computed by:
• frequency
• recency
• recurrency
This is an emergent feature; not enforced.
3.2 Higher-Order Spaces (meSpace², meSpace³, …)
As patterns emerge in meSpace¹, higher-order structures form:
meSpace¹ ⊂ meSpace² ⊂ meSpace³ ⊂ …
Each layer encapsulates the previous one and represents:
• contexts
• groupings
• shared areas
• identity-linked namespaces
These spaces are not defined in the code.
They arise through repeated patterns across identities.
⸻
4. Route-Like Behavior
When users co-declare contexts with others, a shared namespace can be derived.
Example declaration:
me.context("sessionA", userB, userC)
Ledger can derive a deterministic route:
me.cleaker.me/@userB@userC/sessionA
This is not a router configuration.
It is an emergent path resulting from declared relationships.
No global registry exists.
No central index exists.
No predefined group structure exists.
Users create semantic spaces through usage, and the system derives routes from those declarations.
⸻
5. No Global Knowledge
Because spaces are emergent:
• The system designer cannot list all groups.
• No user can browse all spaces globally.
• Contexts only exist for those who participate in them.
• There is no central authority over classification.
This makes the system:
• decentralized
• ungoverned
• unindexed
• self-organizing
It behaves more like language evolution than software configuration.
⸻
6. Ledger Integration
The ledger (e.g., Cleaker) simply stores:
• identity roots
• signatures
• declarations
• pointers
• timestamps
and exposes queries.
It does not impose:
• categories
• taxonomies
• access structures
• validation rules beyond signatures
This separation ensures ME remains pure, while semantic structure emerges from the world-usage of declarations.
⸻
7. Summary
• ME is a pure declarative identity atom.
• No schemas, no predefined fields, and no ontologies are enforced.
• All structure (groups, spaces, contexts, routes) emerges from usage.
• Semantic spaces form naturally through repeated declarations.
• Higher-order spaces appear as layers over functional usage.
• Nothing in the system knows or governs all spaces.
• It’s a bottom-up, usage-driven identity field, not a top-down profile.
This enables a self-organizing semantic ecosystem, where users shape meaning, not the system.
Top comments (0)