Public Channels

One-way public broadcasting — signed, unencrypted events that anyone can read without a contract.

Public channels are the counterpart to Decentrl's private communication. While contracts establish encrypted, bilateral channels between two identities, public channels let any identity broadcast signed events that anyone can read — no contract, no encryption, no mutual consent required.

When to Use Public Channels

Private events (via DIRECT_AUTHENTICATED and TWO_WAY_PRIVATE channels) are ideal when data should only be visible to the sender and a specific recipient. Public channels are for data that should be openly accessible:

• Social feeds — posts, articles, status updates
• Public profiles — bio, avatar, display name
• Announcements — release notes, policy changes
• Discovery — published service capabilities, public metadata

How It Works

The flow is simpler than private communication because there's no encryption or contract negotiation:

1. Publisher signs the event — { channel_id, event, tags, timestamp } is signed with Ed25519
2. Publisher sends a ONE_WAY_PUBLIC command to their mediator
3. Mediator verifies the command signature AND the event signature, then stores the event
4. Anyone can query via a simple GET /public/{did} endpoint — no authentication needed
5. Readers verify the event signature against the publisher's public key (embedded in their DID)

What's Signed

Every public event carries a signature over:

{
  channel_id: string   // publisher-defined channel namespace
  event: string        // JSON-serialized event payload
  tags: string[]       // publisher-asserted metadata
  timestamp: number    // Unix seconds
}

This means readers can verify:

• The event content wasn't tampered with
• The tags are authentic (not injected by the mediator)
• The timestamp was set by the publisher
• The event was published by the DID that claims it

The mediator is a relay — it stores and serves events but cannot forge them.

Channels and Tags

Public events are organized by channel ID and optionally by tags:

• Channel ID — a namespace string (e.g. blog, profile, announcements). A single identity can publish to multiple channels.
• Tags — metadata labels for filtering. Tags are plaintext (unlike private event tags which are encrypted). Tag templates support interpolation: post:${title}.

Readers can filter by channel and/or tags when querying.

Public vs Private — Comparison

Combining Public and Private Events

A typical app uses both. For example, a social app might use:

• Public channels for posts, profile updates, and follower counts
• Private channels for direct messages, reactions, and read receipts

Both event types flow through the same defineDecentrlApp configuration and the same state reducers — they just use different prefixes (public: for own public events, channel: for external public events).

Security Considerations

• No confidentiality — public events are stored in plaintext. Don't publish sensitive data.
• Integrity guaranteed — signatures prevent tampering. Readers should always verify signatures.
• Publisher authentication — the signing key is embedded in the publisher's DID, so anyone can verify authorship.
• Mediator trust — the mediator can withhold events (censorship) but cannot forge or modify them. Readers who want censorship resistance can query multiple mediators or use content-addressed storage.
• Tags are public — unlike private events where tags are encrypted, public event tags reveal metadata. Design tag schemas accordingly.