2.0 KiB
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.