Publishing Content

Sthalam enables sovereign individuals to publish and distribute content on their own terms—without platforms, algorithms, or intermediaries. Publishers create websites, micro-blog posts, and newsletters, then share them directly with viewers through their sovereign nodes.

Publishing requires a self-sovereign identity with cryptographic keys (PGP keypair, Ed25519 signing keys, UCAN public key). See Creating Your Identity for how identity creation works in the Osvauld ecosystem.

Content Types

Websites

Build interactive multi-page websites using HUML (Human Markup Language):

• Visual Builder: Design websites with blocks (text, headings, images, markdown, HTML)
• Navigation Flows: Create page transitions and branching logic
• Custom Styling: Apply CSS for complete design control
• Interactive Elements: Add forms, comment threads, and navigation buttons

Micro-blogs

Publish Twitter-like posts with discussions:

• Short-form Content: Quick updates and thoughts
• Comment Threads: Real-time collaborative discussions
• Subscriber Distribution: Viewers poll node to receive updates

Newsletters

Direct distribution without email platforms:

• Rich Content: Formatted text, images, and markdown
• Subscriber Delivery: Sent directly to all connected viewers
• Pull-Based Updates: Viewers poll node to receive new content when published

Forms & Submissions

Collect viewer feedback and data through interactive forms:

• Multiple Forms: Embed multiple independent forms in a single website (contact, feedback, survey)
• Field Metadata: Custom metadata for parsing form fields (parse_as, validation, categories)
• Privacy Preservation: Viewers submit data without seeing other submissions (append-only)
• Structured Collection: Organize submissions by form_id for easy management
• Pull-Based Sync: Publisher polls node to receive viewer submissions

Publishing Flow

Step 1: Content Creation

Create your content using HUML templates and Sthalam’s visual editor:

1. Generate HUML Template: Use an LLM (ChatGPT, Claude, etc.) to generate HUML templates. Upload the HUML_TEMPLATE_GUIDE.md and describe what you want to build—the LLM will generate the HUML code for your initial template.
2. Edit Generated Content: Use the properties panel to edit the generated content. Markdown is supported for rich text formatting.
3. Customize Your Design: Edit content as you like, add more blocks (text, forms, comment threads, navigation), apply styling with CSS.
4. Add Interactivity: Insert multiple forms for submissions and thread blocks for comments throughout your website.
5. Preview: Review your content before publishing.

Once your template is ready with all blocks and styling configured, proceed to publish.

Step 2: Publishing to Sovereign Node

When you publish content, Sthalam establishes cryptographic ownership:

Root UCAN Generation:

{
  "aud": "publisher_did",
  "cap": {
    "sthalam:resource:resource_uuid": {
      "crud/delete": [{}],
      "crud/read": [{}],
      "crud/update": [{}],
      "ucan/share": [{}]
    }
  },
  "exp": 2702046575,
  "iss": "publisher_did"
}

This self-issued token establishes you as the cryptographic owner with full control.

Data Encryption (At Rest):

1. Generate random AES-256-GCM key for the resource
2. Encrypt website content with AES key
3. Encrypt AES key with your PGP public key
4. Store encrypted content and encrypted key locally

AES Key Re-encryption for Node: When sharing to your sovereign node:

1. Decrypt the AES key using your PGP private key
2. Re-encrypt the AES key with the node’s PGP public key
3. Send encrypted content (unchanged) and re-encrypted AES key to node
4. Node can decrypt to perform CRDT operations (calculate diffs, append data, merge updates)
5. Node stores data encrypted at rest (your trusted sovereign infrastructure)

AES Key Re-encryption for Viewers: When a viewer requests a resource from the node:

1. Node decrypts the AES key using its PGP private key
2. Node re-encrypts the AES key with the viewer’s PGP public key
3. Viewer receives encrypted content and viewer-encrypted AES key
4. If viewer doesn’t open the app, data remains encrypted and inaccessible

Note: In later releases, the node will generate a new AES key per viewer, encrypt the content with the new key, and encrypt the new AES key with the viewer’s PGP public key for enhanced security isolation.

Encryption Guarantees:

• At Rest: All data encrypted with AES-256-GCM on disk (publisher, node, viewer)
• Node Operations: Node can decrypt to perform CRDT operations, then re-encrypts for storage
• In Transit: QUIC connection provides TLS encryption by default
• Multi-Layer Security: Data encrypted at rest + encrypted in transit = always encrypted

Folder Sharing with Sovereign Node:

• Select a folder to share with your sovereign node
• All resources within the folder will be shared with the node (with re-encrypted AES keys)
• When you add new content to the folder, hit “Sync Resource” to sync it to the node
• Node stores encrypted resources and makes them available for viewer access

Step 3: Generating Share Tokens

Create connection strings for viewers to access your content:

Folder-Level Sharing:

• Select folder containing your websites/posts
• All resources in folder will be accessible
• Generate public view token (30-day validity)

Initial UCAN Token Structure (Wildcard Audience):

{
  "aud": "*",
  "cap": {
    "sthalam:folder:folder_uuid": {
      "view/public": [{}]
    }
  },
  "exp": 1759045632,
  "iss": "publisher_did"
}

Important: This wildcard token (aud: "*") is used ONLY for first-time connection. After the viewer connects for the first time, the node issues a viewer-specific token (see Token Upgrade below).

Connection String: Base64-encoded JSON containing:

• Publisher’s user public key
• Publisher’s device public key
• UCAN token (wildcard for initial connection)
• UCAN verification public key

Step 4: Distribution

Share the connection string with viewers:

Distribution Channels:

• Email, chat, social media
• QR codes for mobile sharing
• Website embeds
• Out-of-band communication

Viewer Experience:

1. Receives connection string (with wildcard token)
2. Pastes into Sthalam viewer
3. Establishes P2P connection to your node using wildcard token
4. Node authenticates and upgrades token (see Step 5)
5. Initial sync downloads all content
6. Must actively poll node to receive future updates

Step 5: Token Upgrade After First Connection

When a viewer connects for the first time using the wildcard token (aud: "*"), the sovereign node performs a security upgrade:

First Connection Flow:

1. Viewer Connects: Uses wildcard token from connection string
2. Node Authenticates: Validates wildcard token and viewer identity
3. Token Issuance: Node issues two new viewer-specific tokens:
   • Folder token: For accessing folder resources
   • User token: For user connection capabilities
4. Viewer Stores: New tokens saved locally for all future connections
5. Original Token Discarded: Connection string token is never used again

Viewer-Specific Token Structures:

1. Folder Token (for accessing folder resources):

{
  "aud": "viewer_did",
  "cap": {
    "sthalam:folder:folder_uuid": {
      "view/public": [{}]
    }
  },
  "exp": 1759045632,
  "iss": "publisher_did",
  "fct": {
    "issued_from": "original_connection_string_token_cid"
  }
}

2. User Token (for user connection capabilities):

{
  "aud": "viewer_did",
  "cap": {
    "sthalam:user:user_uuid": {
      "user/connect": [{}]
    }
  },
  "exp": 1759045632,
  "iss": "publisher_did",
  "fct": {
    "issued_from": "original_connection_string_token_cid"
  }
}

Important: Both tokens include the fct (facts) field containing a reference to the original connection string token CID, creating a cryptographic audit trail of token issuance.

Key Differences:

• Initial Token: aud: "*" (anyone with link can use it once)
• New Tokens: Two tokens with aud: "viewer_did" (specific to this viewer)
  • Folder token for resource access
  • User token for connection capabilities
• Facts Field: Links new tokens to original connection string token via CID reference
• Usage: Initial token used ONLY for first connection, new tokens for all subsequent connections

Security Benefits:

• Wildcard Token Simplicity: Easy sharing via connection string
• Viewer-Specific Security: After first connection, access is tied to viewer’s identity
• Cryptographic Audit Trail: Facts field creates provable link from new tokens to original connection string
• Token Provenance: Can trace which connection string was used to issue any viewer token
• Revocation Capability: Publisher can revoke specific viewer tokens (future feature)

Subsequent Connections: After token issuance, viewers use their viewer-specific tokens for all future connections:

• Folder token for accessing resources
• User token for connection establishment
• Faster authentication (no wildcard validation needed)
• Specific audience verification with aud: "viewer_did"
• Better security and access control
• Original connection string token never used again

Subscription Model

When viewers connect to your folder, they subscribe to all your content:

Pull-Based Updates:

• New websites you publish → Viewers pull when polling node
• New micro-blog posts → Viewers receive when they poll
• New newsletters → Viewers pull from node
• Updated content → Viewers sync via active polling

Sovereign Distribution:

• No email lists or newsletter platforms
• No algorithms controlling reach
• Direct publisher → node ← viewer (viewer pulls)
• Full sovereignty over distribution
• Viewers control when they poll for updates

Security Properties

Cryptographic Ownership: Root UCAN establishes mathematical ownership

Multi-Layer Encryption:

• At Rest: All data encrypted with AES-256-GCM at publisher, node, and viewer
• In Transit: QUIC connection provides TLS encryption by default
• AES Key Re-encryption: Keys re-encrypted for node and each viewer using PGP (later releases will generate new AES keys per viewer)
• Zero Access: If viewer doesn’t open app, data remains encrypted and inaccessible

Access Control: UCAN tokens define exactly what viewers can access

Revocation Capability: Future support for invalidating access

Data Sovereignty:

• Content remains encrypted on your sovereign node under your control
• Node is your trusted infrastructure and can decrypt to serve viewers
• Viewers receive content encrypted specifically for them with re-encrypted AES keys

What Happens After Publishing

Once content is published and shared:

1. Resource Available: Content stored on your sovereign node
2. Viewers Connect: Anyone with connection string can subscribe
3. Initial Sync: Viewers receive all current content in folder
4. Ongoing Updates: Viewers must actively poll node to receive new content
5. Interaction: Viewers can submit forms and comment on threads based on permissions

Publishing with Sthalam means building your audience on your own infrastructure, maintaining full control over content and distribution while enabling direct sovereign-to-sovereign connections.