Skip to content

What is Sobamail? (AI Summary)

If you want to try this with the LLM of your choice, the prompt is very simple:

Summarize https://sobamail.com/docs/concepts/

Choose:

Summary #1

Here’s a concise summary of the Concepts page:

What is Sobamail

  • Sobamail is an email solution built over open‑source standards (SMTP, IMAP, POP3, webmail).
  • Beyond typical email, it provides a distributed application platform layered on top of email, enabling storage and transport of mutation events, apps, data, and assets.
  • The main client is Sobamail Desktop, which combines email UI with an application runtime (using V8 + Chromium Embedded Framework).

Key Concepts

Mailboxes

  • Each user has one mailbox, identified by their primary email address.

  • A mailbox stores:

  • A folder structure with message threads + metadata

  • Application instances and their mutation graphs / computed state

  • Blobs (for attachments, assets)

  • Mailboxes are replicated across multiple devices (user’s devices + Sobamail cloud).

  • Each replica is identified by a UUID (v4).

Application Model

  • Apps have application IDs, much like domain-style identifiers.
  • Apps can have multiple versions, identified by cryptographic hashes + version strings.
  • To be usable, apps must be instantiated → producing instances tied to a mailbox replica. Each instance has its own data store.

  • Instances run in different modes:

  • Developer mode: local-only, no replication

  • Private mode: synchronized across replicas of one mailbox
  • Shared mode: synchronized across replicas of multiple mailboxes (allowing multi‑user collaboration)

Version Progression

  • During development, apps run in developer mode, where replication & version checks are relaxed.
  • Once deployed, the app’s components are hashed and “frozen.” All replicas must use the same version to replay mutations to avoid state divergence.
  • Old versions are retained to replay past mutations as needed.
  • The Sobamail runtime itself is versioned. Apps must declare which “computer” (runtime version) they expect. Currently there is Replicated‑1.

Events & Messaging

  • The system is event‑driven: apps respond to incoming events, identified by object keys (namespace + name).

  • There are two types of email messages that Sobamail handles:

  • Message — regular email

  • Structured Message (SMessage) — includes a header indicating a structured payload (JSON or msgpack) called the Structured Message Content (SMC)
  • SMCs follow a schema:
{
  "namespace": "...",
  "name": "...",
  "content": [...]
}

The combined {namespace}name forms the object key used to route events. - Events are either replicated or non‑replicated:

  • Replicated events must obey strict rules to avoid conflicts, since they may be applied concurrently.
  • Non‑replicated events may query the local database and emit replicated events.

Application Components

  • Apps consist of two main parts:

  • Mutator module: defines how events are handled and mutations are produced

  • User Interface (UI) package: frontend code (HTML/CSS/JS) for the app UI

  • Mutator Module:

  • Written in JavaScript

  • Must export a process() method and metadata (objects of interest, app id, version, etc.)
  • When an event arrives, all apps are “broadcasted” to it; only those interested (declared objects) handle it.
  • Imports: modules are imported via URI + hash. This allows code reuse across apps.

  • UI Package:

  • It’s a standard frontend web app (must be Chrome‑compatible)

  • It communicates with the mutator via an email‑compatible RPC interface (not REST) — objects flow back and forth.
  • msgpack is preferred for data encoding, though JSON is also supported.

Replication & System Apps

  • Each mailbox has two built-in apps:

  • Application Manager (manages app versions, assets, etc.)

  • Mailbox Manager (manages folders, messages, metadata)
  • These are automatically replicated across all replicas of a mailbox, but not across mailboxes. They are singleton per mailbox.
  • App instances in Sobamail replicate their mutation events across replicas: when a replica goes online, it receives missing mutations.

Email Compatibility

  • Users can access their mailbox via POP3 or IMAP, as usual.
  • App instances can appear as folders; mutations can be surfaced as structured messages.

Summary #2

Sobamail Overview

Sobamail is a modern, email-based platform that combines traditional email features (SMTP, IMAP, POP3, webmail) with a distributed application framework. It enables apps to run on top of email infrastructure using structured, versioned data and reactive event handling.

Core Features

1. Mailboxes

  • Each user has one primary mailbox (email address) which stores:

  • Folders with message threads

  • Application instances (app state and mutations)
  • Blobs (immutable files like attachments or assets)
  • Mailbox replicas exist on devices/cloud, each identified by UUIDs.

2. Applications

  • Apps have:

  • Unique IDs

  • Versions (cryptographically hashed, immutable)
  • Instances (tied to mailboxes; can be local, private, or shared)
  • Apps react to events (e.g., emails) and process them via a process() method in a JavaScript Mutator module.

3. Application Architecture

  • Mutator module: Backend logic written in JS; handles events and mutations.
  • User Interface: Frontend in HTML/CSS/JS (displayed using Chromium Embedded Framework).
  • Uses msgpack or JSON for structured message data.

4. Events and Mutations

  • Apps respond to Structured Messages via object keys (in {namespace}Name format).
  • Mutations modify app state and are shared across mailbox replicas.
  • Only INSERT and DELETE operations are allowed (no UPDATE).
  • Events are processed reactively and used to synchronize app state.

5. Replication

  • App states and mailbox content are replicated across devices/cloud.

  • Each mailbox contains two special system apps:

  • Application Manager (manages apps)

  • Mailbox Manager (manages email/folders)
  • Replication ensures consistency, using structured messages for cross-mailbox synchronization (in development).

6. Runtime and Versioning

  • Apps specify a "computer" version (runtime environment) to ensure deterministic behavior.
  • Current computer: "soba://computer/R1" (experimental).
  • Once deployed, app versions are immutable; all mutations are processed by the exact version that created them.

7. Inter-App Operability

  • Apps can import code/modules from other apps via cryptographic URIs.
  • No data sharing between app instances yet, but code sharing is supported.

Email Compatibility

  • Standard email protocols (POP3, IMAP) supported.
  • Eventually, app data (like folders and mutations) will be accessible via email clients. (Planned feature)