Elonn Docs Platform Documentation

Services

Status: Current service orientation. This page is not the active project plan.

Elonn is a monorepo of independent PHP services. Each service owns its database, routes, and domain logic. Services communicate over HTTP/JSON. There is no shared library.

For current implementation status and agent orientation, start with Current State.

Service map

Service Role
api.elonn.local Identity authority and member directory — canonical auth token source
world.elonn.local Composition layer — aggregates maps, social, messages, time, and identity into runtime contracts
web.elonn.local Browser runtime shell — consumes world contracts, renders SurfaceStack, docks, rails, field controls, and field layer
social.elonn.local Social objects: profiles, communities, conversations, social events, Social DMs
messages.elonn.local Open one-to-one member Messages outside Social context
maps.elonn.local Geographic object service and POI normalization
find.elonn.local Discovery and search
time.elonn.local Calendars and scheduling
surface.elonn.local Interaction object persistence
elonn.local Public front door — login, registration, account state, handoff to runtime
admin.elonn.local Operator console

External protocol origin

services.elonn.com is a stable public hostname for standards-based external clients. It is not another application service or bounded context. In cPanel, the hostname points to the existing Time document root, so https://services.elonn.com/caldav/ executes the Time CalDAV implementation. Time remains the calendar authority and API remains the credential authority.

The cPanel deployment requirements are:

  • add services.elonn.com with the same document root as time.elonn.com
  • issue AutoSSL for the hostname
  • enable the PHP DOM extension for the selected PHP version
  • add _caldavs._tcp.elonn.com. SRV 0 1 443 services.elonn.com.
  • add _caldavs._tcp.elonn.com. TXT "path=/caldav/"

Future protocols may reuse the hostname on their standard paths or ports, but mail, CardDAV, JMAP, and Matrix endpoints must not be advertised before their own services exist.

Runtime request flow

elonn.local
  → api.elonn.local       (auth)
  → web.elonn.local       (runtime shell)
  → world.elonn.local     (contract composition)
  → surface.elonn.local   (surface stack state)
  → maps / social / messages / find / time  (domain data)

Ownership rules

  • api.elonn.local is the identity source of truth. Other services validate identity through API endpoints — they do not connect directly to the elonn_api database.
  • surface.elonn.local owns durable runtime surface, stack, focus, placement, and surface session state.
  • world.elonn.local does not own authored field data or surface persistence. It consumes from maps and surface, then composes runtime contracts and service panel URLs.
  • social.elonn.local is the source of event truth. Time ingests social events as calendar mirrors; social remains authoritative for event identity, visibility, participants, RSVP state, and discussion.
  • messages.elonn.local owns open one-to-one Messages. Social DMs remain Social-owned.
  • web.elonn.local does not call social, messages, maps, or time directly. All service access routes through world.
  • Panels are runtime UI in rails or surface bodies. Panels are not durable surfaces unless they need surface identity, placement, sharing, persistence, and stack membership.

Standard layout

Every service follows the same directory structure:

service.elonn.local/
├── public/index.php
├── src/
│   ├── Http/         router, request, response
│   ├── Controller/
│   ├── Services/
│   └── Support/
├── templates/
├── config/config.php
├── migrations/
├── vendor/
├── .env.example
└── .env

config/config.php is the only layer that reads $_ENV or $_SERVER. All other code consumes normalized config arrays from it.