31 lines
2.0 KiB
Markdown
31 lines
2.0 KiB
Markdown
|
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.
|