Channel Model and Timeline

Channel hosting protocol · Channel core objects

A channel is hosted by the relay designated by its creator; no migration flow is defined. Successful creation automatically makes the creator account owner. The owner manages descriptor updates and closure; owner and moderators may publish, edit, and delete public content. Descriptors use consecutive revisions. Descriptor updates, posts, edits, and deletions enter one public timeline in hosting-relay acceptance order.

Channel Timeline Lifecycle

Event Writes

On creation, the hosting relay stores the initial ChannelDescriptor as the creation event at sequence 0. Each subsequent accepted descriptor update, post, edit, or deletion receives a sequence greater than the current head and enters the timeline with its complete accepted descriptor or content object as payload.

Each entry also records acceptance time accepted_at and corresponding descriptor_rev. Descriptor events use their own revision; content events use the descriptor revision effective at acceptance. Creation has revision 0.

Sequences express acceptance order within a channel. Duplicate publications, edits leaving post state unchanged, failed requests, reports, and reads create no events.

Writes follow Atomic commit and persistence rules. Assigned sequences MUST NOT be reassigned to other events; cleanup MUST NOT renumber retained events.

Post Editing

A post event establishes the message ID and initial state, including body, attachments, and unknown properties. Duplicate recognition follows channel.post. Edits do not modify or replace original posts; clients apply verified edits by relay-assigned sequence. Edits may update body, attachments, and unknown properties. Whether an event is produced follows state comparison under Post editing. For body and attachment structure, see Channel content write rules. Edit permission does not depend on the target post's author.

A single edit is not complete post state. Reconstruction at a point in time requires the corresponding post and edit events.

Post Deletion

A deletion event is terminal for the target post. Appending it and stopping channel.read from returning the target ChannelPost and all preceding ChannelPostEdit events targeting it MUST take effect atomically. Deletion permission does not depend on the author.

After obtaining and applying deletion, conforming clients MUST remove the post and its existing edits from their local channel timeline. New clients no longer obtain their bodies from the hosting relay.

Deletion controls subsequent relay-provided timelines and conforming-client behavior, not guaranteed remote erasure. The protocol cannot ensure that clients holding old posts continue synchronizing or perform deletion, or retract separately saved or forwarded copies.

Channel Closure

The ChannelDescriptor produced by channel.close is the final write. No new descriptor update, post, edit, or deletion may be accepted afterward, and closed state cannot be reversed.

Rejections of channel.update, channel.close, channel.post, channel.post.edit, or channel.post.delete because the channel is closed all return state_conflict. Invalid parameter formats still use bad_request. Duplicate recognition follows each method; rejection MUST NOT change state or timeline.

Event Retention and Cleanup

While a channel is active, event retention and cleanup follow these rules.

Each event's minimum deadline is its accepted_at plus channel_timeline_retention declared by relay.info at acceptance. Except for content cleanup below, the host MUST retain it at least through that deadline. Later changes MUST NOT shorten it. Creation, descriptor updates, posts, edits, and deletions share this rule.

While an original post remains readable through channel.read, all edits targeting it MUST remain retained and obtainable under timeline reading rules, even after an edit's own minimum retention expires. This dependency does not extend the original post's minimum retention. Once deletion or cleanup stops returning the post, its edits also stop returning.

After successful deletion, the relay may immediately clean up the post and its existing edits without waiting for their individual minimum deadlines. After retention-based cleanup of the original post, it may likewise immediately clean up edits without waiting for theirs.

A deletion event MUST remain retained and readable at least until the later of its own and the original post's minimum deadlines. A client resuming after deletion-event cleanup may never learn its cached post was deleted.

Reads, duplicate publications, subscription state, and stopping post returns after deletion MUST NOT refresh acceptance times or original deadlines. After a post stops returning, the relay MUST still retain its publishing-account/message-ID binding, original sequence, and information needed for duplicate-content comparison at least through the original post's minimum deadline. Cleanup or later configuration reduction cannot remove this early.

Cleanup MUST NOT change the timeline head, rewrite other events, or reuse sequences. An edit's target is unavailable once its original post is cleaned up or no longer returned.

Device certificates and complete descriptors at the relevant revisions needed to verify these edits and deletions MUST remain retained with the events and available under their read rules.

Descriptor Retention and Permission Verification

The initial timeline ChannelDescriptor represents creation; subsequent ones represent updates. While active, the latest descriptor MUST remain as current channel state. Historical descriptors required by the timeline MUST remain complete, with signer references and certificates for both current and required historical descriptors. All these descriptors and their signer certificates MUST be retrievable through channel.resolve. While current-state or dependency requirements persist, event cleanup MUST NOT delete the required descriptor or certificate.

To verify content events, clients retrieve and verify the complete ChannelDescriptor named by outer descriptor_rev, confirming the operation's signing account equals creator or appears in moderators. Verified descriptors and certificates may be cached and reused by revision. Event structure, certificate references, and signature verification follow ChannelEvent and Device certificates for channel events.

Atomic Commit and Persistence Rules

Creation, updates, closure, posting, editing, and deletion MUST atomically activate a complete consistent result comprising required hosting state, current descriptor, post state, complete event and verification material, descriptor revision, accepted_at, and sequence. At activation, permission, current revision, channel state, target-post state, and other preconditions MUST still hold. Content permission checks and revision recording MUST use the same current descriptor. Failure MUST NOT leave partial business effects or advance the head.

Before success or notification, the relay MUST persist everything required for the operation. Activated results must remain complete and consistent after restart or recovery. Notification failure does not roll back channel state or timeline.

Trust and Resource Boundaries

Clients MUST verify host identity and channel.host.v1 through the Registry and current RelayDescriptor, and use valid device sessions. Timeline sequence is the relay's claim of acceptance order; accepted_at claims acceptance time; content descriptor_rev claims the effective descriptor revision at acceptance.

Creation, writing, reporting, and subscription limits follow Resource and security controls. Invalid signatures, insufficient permissions, and revision rollback MUST NOT change verified state.