Elonn Docs Platform Documentation

Social Contract

Social is the shared social object service for Elonn. It helps members move through conversations, communities, and events using circle-based discovery.

This contract defines the ideal Social product and runtime experience. It is not constrained by the current service implementation.

Open platform Messages are specified separately in messages-contract.md. Social DMs are private one-to-one communications inside Social context and remain part of Social.

Purpose

Social gives every member a shared place to see what is happening around them:

  • conversations they can join or continue
  • communities they belong to or can discover
  • events they can attend or discuss

The main Social surface opens as a dashboard with those three categories. The next stops are the Conversations, Communities, and Events pages. Those pages use the same circle filters so a member can narrow or widen the Social world they are looking at.

Core Model

Social is organized around three primary object categories:

Category Meaning
Conversations Threaded group discussions with replies.
Communities Shared member places that can contain members, conversations, and events.
Events Social gatherings with participants, RSVP state, and an attached discussion context.

Supporting Social systems enrich those objects:

System Role
Profiles Show member identity inside Social objects.
Presence Shows current availability and context where visible.
Activity Summarizes relevant Social changes and recent movement.
Notifications Alerts members about Social objects that need attention.
Relationships Holds explicit blocks.
Media Provides Social-owned media references for objects that need them.
Social DMs Private one-to-one communication initiated from Social context.

Profiles, presence, activity, notifications, relationships, media, and Social DMs are not top-level dashboard categories in this contract. They appear through conversations, communities, events, and their detail views.

Circles And Discovery

Circles are discovery filters. They decide what is surfaced, prioritized, and filtered. They do not grant access by themselves.

Circle reach comes only from shared private community membership:

Filter Meaning
Inner People who share a private community with the member directly.
Trusted People who are Inner to the member's Inner circle.
Extended People who are Inner to the member's Trusted circle.
All The widest Social view the member can access.

Rules:

  • Private communities create Inner circle bonds between active co-members.
  • Trusted and Extended are derived by walking outward through private community co-membership.
  • Public communities and public events do not create circle bonds.
  • Private event co-participation does not create circle bonds.
  • Members do not create circles directly.
  • Social has no followers, following, friends, friend requests, or manual connection lists.
  • Blocks remove members from discovery results and Social surfacing. A block is not a circle edge.

Discovery answers: "Which visible Social objects should appear for this circle filter?"

Access answers: "Is this member allowed to open this object?"

Access comes from object visibility, ownership, community membership, invitation, or participation. A circle filter must never reveal a private object the member is not allowed to open.

Dashboard

The main Social surface opens to a dashboard. The dashboard must show:

  • a Conversations category
  • a Communities category
  • an Events category
  • counts for each category
  • recent or important highlights for each category
  • an action to open the full page for each category
  • create actions for conversations, communities, and events when the member is allowed to create them

The dashboard is not a generic feed and not a People page. People appear inside object context as authors, members, participants, organizers, invitees, presence signals, and notification actors.

Category Pages

Conversations, Communities, and Events pages must all expose the same circle filter set:

  • Inner
  • Trusted
  • Extended
  • All

The selected filter changes which visible objects are shown and prioritized on the page. It does not change the member's underlying permissions.

Conversations Page

A conversation is a titled, threaded group discussion. A reply is a post inside a conversation or event discussion.

Conversation access may come from:

  • public visibility
  • community membership
  • explicit participation
  • ownership or moderation rights

The circle filter applies to conversation context, such as authors, participants, the owning community, and recent activity. A conversation can appear in a circle view when its visible context belongs to that circle.

Runtimes must support:

  • browsing conversation lists by circle filter
  • opening conversation detail surfaces
  • reading replies
  • posting replies when allowed
  • creating conversations when allowed
  • editing conversations when allowed

Replies are not Messages or Social DMs. UI copy should call them replies when they belong to conversations or events.

Social DMs

Social DMs are private one-to-one threads initiated from Social context: member/profile cards, conversations, communities, events, replies, participant lists, presence, activity, notifications, or discovery results.

Social DMs must:

  • stay inside the Social surface or Social right rail context
  • never appear as a global member-dashboard feature
  • never appear as a separate lower-dock service
  • keep exactly two participants
  • guide members to create or use a Social community, conversation, or event when they need more than two participants

Communities Page

A community is a named shared place for members. Communities can contain members, conversations, and events.

Community access may come from:

  • public visibility
  • active membership
  • invitation
  • ownership or moderation rights

The circle filter applies to community context, such as shared private membership, visible members, visible conversations, visible events, and recent activity. A private community can only appear for a member who is allowed to open it.

Runtimes must support:

  • browsing community lists by circle filter
  • opening community detail surfaces
  • seeing visible members and recent Social activity
  • creating communities when allowed
  • inviting or adding members when allowed
  • editing communities when allowed

Events Page

An event is a Social gathering. Bare event means a Social event. Time-owned calendar entries must be called calendar events.

Event access may come from:

  • public visibility
  • ownership
  • invitation
  • participation
  • membership in a community that owns or hosts the event

The circle filter applies to event context, such as organizers, participants, hosting communities, attached discussion, and recent activity. Event participation does not create circle reach.

Runtimes must support:

  • browsing event lists by circle filter
  • opening event detail surfaces
  • seeing schedule, location, organizer, participation, and RSVP state when available
  • reading and posting event replies when allowed
  • creating events when allowed
  • editing events when allowed
  • RSVP or participation actions when allowed

When a Social event needs calendar behavior, Social may publish a calendar mirror to Time. Social remains authoritative for event identity, Social visibility, participants, RSVP state, and event discussion. Time remains authoritative for calendar behavior.

Runtime Delivery

Runtimes deliver Social through a main Social surface in the center stack, category pages, and durable object detail surfaces.

Required runtime behavior:

  • Open the Social surface to the dashboard.
  • Render Conversations, Communities, and Events as the dashboard's primary categories.
  • Open category pages from the dashboard.
  • Render the shared circle filter set on every category page.
  • Keep a useful right rail visible with Social navigation, counts, and context while the center stack holds the dashboard or category page.
  • Do not route Social dashboard or category clicks through the generic carry-panel shell.
  • Preserve the selected category and circle filter during normal navigation.
  • Open conversation, community, and event detail as durable surfaces when the action asks for a surface.
  • Use modal or inline panels only when the provided action is not a durable object surface.
  • Submit create, edit, reply, RSVP, invite, and notification actions only through World-provided URLs.
  • Refresh the affected panel, surface, or session after successful Social mutations.
  • Show auth, permission, empty, loading, validation, and unavailable states without leaving blank panels.

The runtime does not own Social truth. It renders the contract, captures member intent, and sends actions through World.

World Boundary

Runtimes use World routes for visible Social behavior. They do not call social.elonn.local directly.

World is responsible for:

  • relaying Social reads and writes
  • rewriting Social links and actions into World URLs
  • composing Social panels into runtime surfaces
  • preserving service ownership while keeping runtime calls on the World boundary

Social-owned links and actions exposed to runtimes must be World-safe by the time the runtime receives them.

Ownership Boundaries

Social owns:

  • conversations and replies
  • communities and community membership
  • Social events, participants, RSVP state, and event replies
  • profiles and presence
  • activity and notifications
  • block relationships
  • circle and discovery behavior
  • Social media references
  • Social DMs

Social does not own:

  • open platform Messages
  • auth sessions or identity credentials
  • Time-owned calendar entries
  • runtime layout, focus, placement, or stack order
  • World composition
  • rendering in web, Android, iPad, XR, or future runtimes

Non-Goals

This contract must not introduce:

  • followers or following
  • friends or friend requests
  • manual social lists
  • private-event-derived circle reach
  • stored circle membership records as the product model
  • a standalone People page
  • Messages as Social conversations
  • Social DMs as a global member-dashboard or lower-dock service
  • runtime calls directly to Social for visible behavior