FollowInclude relevant public activity in Your network.
Technical model
Independent places, recursive spaces, explicit authority.
Aitta exchanges typed data and events between independently controlled places. Each Aitta chooses the software it trusts; relationships, permissions, storage, and state authority remain separate.
System vocabulary
Each role has one job.
Familiar words such as message, conversation, question, task, request, decision, space, and app stay in the ordinary interface. These terms define the model underneath.
AittaSocial
The software platform and product family.
Aitta
One independently controlled top-level place with its own authority, lifecycle, data, address, runtime, and trusted apps.
Aitta Network
The relationships and exchanges connecting Aittas and signed-in members—not a central feed or content store.
AittaSocial Hub
Identity, discovery, relationships, authorization evidence, and coordination. It is not the network itself or a shared content store.
Event
The universal typed unit: a message, action, response, state transition, or app root.
App implementation
Trusted, versioned software installed in an Aitta.
App instance
A concrete event-rooted instance interpreted by an app implementation.
App space
A root event and its authorized descendants, state, people, and nested apps.
Member
A signed-in person who may participate without owning an Aitta.
Feed
An ordered projection of events and spaces—not the authority or storage model.
Thread
One possible view of a root and descendants—not the universal primitive.
Universal recursive rule
Every event may be a child in one app space and the root of another.
Messages, replies, questions, decisions, actions, and app state use versioned, typed events. Namespaced types such as social.aitta.message let compatible apps recognize the same meaning.
Parent app spaceProject update
Child event · new rootQuestion
Nested app spaceRestricted decision
Nested appTask
The parent describes structure. The event type describes meaning.
Neither grants access.
Relation is not authorization
Connection never silently opens a door.
A related child may remain undiscoverable, unreadable, or unavailable when the viewer lacks the required access.
Code never travels with an event
Events carry data. Software stays local.
Each Aitta interprets an app instance through a trusted, versioned implementation already installed there. A remote sender cannot make an Aitta run new software.
An event may carry
- App type and compatible version range
- Global identity and parent relationship
- Actor identity and authoritative Aitta
- Typed data and state transitions
- Policy references
- Content hashes or signatures
An event never carries
- Executable JavaScript
- Arbitrary HTML
- Remote scripts
- Automatically installed packages
Safe unknown type
Unsupported apps fail boundedly.
An Aitta may show the trusted type identifier, source and authority, safe static data, an appropriate web fallback, and the reason interaction is unavailable. It never fetches and executes the sender's implementation.
Distributed state
Authority stays explicit.
The same logical app space may appear in several Aittas, but its state is not one ownerless pool. Every app contract defines who controls each category and what happens during conflict or revocation.
| State category | Meaning |
|---|---|
| Root-authoritative | Canonical wording, lifecycle, or closing state controlled by the originating root authority. |
| Child-event | The authority allowed to create or amend a particular descendant event. |
| Participant-authoritative | A person controls the response, request, or other event they create. |
| Local-only | Drafts, viewed status, notifications, display preferences, and other state that never needs to leave an Aitta. |
| Cached or derived | Rebuildable views and summaries with a clear source and invalidation rule. |
| Synchronized | State exchanged under an explicit app contract with conflict, revocation, and recovery behaviour. |
Example: a shared question
The originating Aitta may control canonical wording and closing state. A participant controls the response they create. Each Aitta controls local drafts, viewed status, and notifications. Owning the root never makes one Aitta the author of every descendant.
Members without Aittas
A person is not a deployment.
A member can sign in with ChatGPT, follow an Aitta, join an allowed space, respond, message, and use apps without owning an Aitta. A Hub account provides network identity evidence; it is not an Aitta, and joining never silently creates one.
Actor
The person or agent taking the action.
Storing Aitta
The Aitta accepting and retaining the event.
Canonical authority
The authority for the relevant shared state.
Hub evidence
The evidence authenticating the actor.
Sign in with ChatGPT provides only the identity information shown during sign-in. It does not give Aitta access to ChatGPT conversations, memory, files, tokens, or billing data.
Views, not primitives
Feeds and threads are projections.
Your network is an ordered view of relevant public activity from Aittas a member explicitly follows. Original content remains authoritative in those Aittas; the Hub does not become a shared content store.
A thread is one useful view of a root and descendants. It does not define every event relationship, nested app, access boundary, or authority rule.
Recursive spaces must always preserve a clear current context, visible ancestry, understandable access, predictable navigation, bounded depth, safe fallback, and explicit ownership and authority.
Open implementation