Matrix uses rooms to establish contexts.

We can have a forum context,
wherein a few things happen.

One is that the forum will have a root post; equivalently, any post can be the root of a forum.

The context of that post can be preserved.

The forum is thus a collection of posts. Each post MAY have its own internal structure.
A post MAY "replace" a prior post. This consists of on-chain and off-chain elements.
On-chain, a new post replaces a prior post.

---

Reading Matrix spec, https://spec.matrix.org/latest/

> Events are signed by the originating server (the signature includes the parent relations, type, depth and payload hash) and are pushed over federation to the participating servers in a room, currently using full mesh topology. Servers may also request backfill of events over federation from the other servers participating in a room.

> In order to ensure that the mapping from 3PID to user ID is genuine, a globally federated cluster of trusted “identity servers” (IS) are used to verify the 3PID and persist and replicate the mappings.
>
> Usage of an IS is not required in order for a client application to be part of the Matrix ecosystem. However, without one clients will not be able to look up user IDs using 3PIDs.

> Users may publish arbitrary key/value data associated with their account
>
> - such as a human-readable display name, a profile photo URL, contact information (email address, phone numbers, website URLs etc).

> Users may also store arbitrary private key/value data in their account - such as client preferences, or server configuration settings which lack any other dedicated API. The API is symmetrical to managing Profile data.

> The client-server API allows clients to send messages, control rooms and synchronise conversation history. It is designed to support both lightweight clients which store no state and lazy-load data from the server as required - as well as heavyweight clients which maintain a full local persistent copy of server state.