Context#

Small groups of people and communities must rely on centralized and big tech tools to organize themselves or communicate.

There should be alternatives where communities can self host their platforms and own their data. With full independence and no dependency on big tech.

Some tools exist (forums or small centralized platforms), but they often add friction.

We believe that AT Protocol can solve many of these issues.

Exosphere#

Exosphere is a set of small and modular tools.

Principle#

• AT Protocol Authentication
• Public spheres are publicly readable, all interactions require an AT Protocol account
• Data belongs to the users (stored on their PDS)
• Self hostable

What kind of tools#

• Feature requests
• Kanban board
• Feed and discussions
• Micro blogging
• Forums
• Polls
• Event organization
• Forms

Spheres#

A Sphere is a community, a small group of friends, a family, a company, whatever. It can be self hosted, or rely on a Sphere hosting provider.

A Sphere can be public or private.

Private Spheres#

Private Spheres are invitation only, users must have an AT Protocol DID. All content is stored on the Sphere database to preserve privacy (AT Protocol repos are public by design).

Public Spheres#

Public Spheres content is readable by anyone. All interactions require AT Protocol authentication.

Write access modes#

• Open - Any authenticated user can participate (react, comment, post).
• Members only - Public read, but only invited members can participate. Anyone can view the content, but interactions (reactions, comments) are restricted to approved members. Enforced at the AppView/indexer level.

Future: unauthenticated access#

Unauthenticated write access (e.g. anonymous poll votes) may be added later as an opt-in feature for specific modules. See ARCHITECTURE.md for details on the tradeoffs.

Technical implementation#

We want the look and feel of Exosphere to be friendly but professional. Everything must be super reliable and fast from the ground up.

• Bun
• AT Protocol
• TypeScript
  • Strong types everywhere
  • Zod schemas where needed
• Backend: Hono.js
• Frontend: Preact
  • Preact Signals for state management
  • CSS / Design systems : vanilla-extract

Getting started#

Prerequisites#

• Bun
• Docker (for the local PDS)

Setup#

bun install

# Generate the OAuth private key (one-time)
bun run packages/core/scripts/generate-key.ts

Copy .env.example to .env and fill in the generated OAUTH_PRIVATE_KEY.

Local PDS#

A local PDS (Personal Data Server) lets you develop against AT Protocol without hitting production infrastructure.

# Generate PDS config (one-time, creates pds/pds.env)
bun run pds:init

# Start the PDS container
bun run pds:up

# Create test accounts
bun run pds:account alice
bun run pds:account bob

Each account is created with a handle like alice.pds.dev and a DID registered on plc.directory. The PDS runs at http://localhost:2583.

Login with the DID, not the handle. Local PDS handles (e.g. alice.pds.dev) don't resolve via DNS. The DID (did:plc:...) is printed when the account is created.

Other PDS commands:

Run#

# Start both backend (port 3000) and frontend (port 5173)
bun run dev

# Or start them separately
bun run dev:server
bun run dev:client

Open http://localhost:5173 in your browser. The Vite dev server proxies /api requests to the backend.