111
edits
Changes
matrix and our use of it
Matrix is a fairly modern FLOSS federated chat protocol.
The fundamental structure of the Matrix network depends on the concept of a <b>homeserver</b>. Users sign up on one homeserver, and can chat to any room or user on any other federated homeserver.
Use require registration -- "guest" accounts have historically been implemented, but due to protocol limitations they are essentially throwaway "real" accounts, and
A "Matrix Space" is the semantic equivalent to a Discord Server or Slack Workspace. Confusingly, a user doesn't need to be in a Space to chat in one of the rooms within. On top of this, rooms don't need to be contained within a Space.
__TOC__
== VTLUUG Matrix ==
The LUUG hosts a Synapse Matrix homeserver at [https://matrix.vtluug.org matrix.vtluug.org], and an Element client/frontend at [https://element.vtluug.org element.vtluug.org]
Relevant addresses:
* #vtluug:matrix.vtluug.org
** this is the VTLUUG Space
* #vtluug-g:matrix.vtluug.org
** the main channel, bridged to [[pound vtluug|#vtluug]] on IRC
== Babby's Guide to Using Matrix ==
This is a (pictoral!) step-by-step guide to registering with our homeserver and joining #vtluug-g:matrix.org using our element instance.
[[File:Matrix_tut.jpg|600px]]
== Issues with the Matrix Protocol ==
<pre>
// from #vtluug. many of the issues in the article have since been mitigated or resolved
2024-03-02 16:40:39 Caitlin 04:08 cynic this is re: setting up a matrix homeserver
2024-03-02 16:40:43 Caitlin strong advice: don't bother :p
2024-03-02 16:41:23 Caitlin https://telegra.ph/why-not-matrix-08-07
2024-03-02 16:41:25 +Wadsworth [ why not matrix? – Telegraph ]
</pre>
There are several built-in issues with Matrix:
* The federation works by updating other servers with the shared event state, which takes the form of an append-only Directed Acyclic Graph. As a result, nothing is ever truly deleted from your state: even as you prune old accounts, they take up space and compute time in your graph
* The only way, in fact, to clean up a room's federation graph is to re-create it
* Backlogs can be forged by the homeserver
* Element can be very slow at times, especially if there's a lot of state to sync
* It's not [[IRC|glorious IRC]]
* The IRC bridges suck
** Most of them create fake Matrix users to puppet, which (as discussed above) permanently slows down processing of the room
Most of these are irrelevant to our purposes, however, given that we are bridging with IRC: a protocol with no backlogs and easily forged history. We don't have the activity for performance issues to really show themselves, either.
[[Category:Infrastructure]] [[Category:Howtos]] [[Category:Featured_content]]
The fundamental structure of the Matrix network depends on the concept of a <b>homeserver</b>. Users sign up on one homeserver, and can chat to any room or user on any other federated homeserver.
Use require registration -- "guest" accounts have historically been implemented, but due to protocol limitations they are essentially throwaway "real" accounts, and
A "Matrix Space" is the semantic equivalent to a Discord Server or Slack Workspace. Confusingly, a user doesn't need to be in a Space to chat in one of the rooms within. On top of this, rooms don't need to be contained within a Space.
__TOC__
== VTLUUG Matrix ==
The LUUG hosts a Synapse Matrix homeserver at [https://matrix.vtluug.org matrix.vtluug.org], and an Element client/frontend at [https://element.vtluug.org element.vtluug.org]
Relevant addresses:
* #vtluug:matrix.vtluug.org
** this is the VTLUUG Space
* #vtluug-g:matrix.vtluug.org
** the main channel, bridged to [[pound vtluug|#vtluug]] on IRC
== Babby's Guide to Using Matrix ==
This is a (pictoral!) step-by-step guide to registering with our homeserver and joining #vtluug-g:matrix.org using our element instance.
[[File:Matrix_tut.jpg|600px]]
== Issues with the Matrix Protocol ==
<pre>
// from #vtluug. many of the issues in the article have since been mitigated or resolved
2024-03-02 16:40:39 Caitlin 04:08 cynic this is re: setting up a matrix homeserver
2024-03-02 16:40:43 Caitlin strong advice: don't bother :p
2024-03-02 16:41:23 Caitlin https://telegra.ph/why-not-matrix-08-07
2024-03-02 16:41:25 +Wadsworth [ why not matrix? – Telegraph ]
</pre>
There are several built-in issues with Matrix:
* The federation works by updating other servers with the shared event state, which takes the form of an append-only Directed Acyclic Graph. As a result, nothing is ever truly deleted from your state: even as you prune old accounts, they take up space and compute time in your graph
* The only way, in fact, to clean up a room's federation graph is to re-create it
* Backlogs can be forged by the homeserver
* Element can be very slow at times, especially if there's a lot of state to sync
* It's not [[IRC|glorious IRC]]
* The IRC bridges suck
** Most of them create fake Matrix users to puppet, which (as discussed above) permanently slows down processing of the room
Most of these are irrelevant to our purposes, however, given that we are bridging with IRC: a protocol with no backlogs and easily forged history. We don't have the activity for performance issues to really show themselves, either.
[[Category:Infrastructure]] [[Category:Howtos]] [[Category:Featured_content]]
