mirror of
https://github.com/mikaela/mikaela.github.io/
synced 2025-08-19 03:17:23 +02:00
Compare commits
4 Commits
a7a1dd628b
...
6b746babec
Author | SHA1 | Date | |
---|---|---|---|
6b746babec | |||
4164044de5 | |||
293db15574 | |||
9f273d3b75 |
@ -28,6 +28,8 @@ I also have a [txt with a list of all my accounts](/txt/matrix.txt) which [has S
|
||||
- [Can I see who is in any specific room without being there?](#can-i-see-who-is-in-any-specific-room-without-being-there)
|
||||
- [What are state resets?](#what-are-state-resets)
|
||||
- [How about DAG splits?](#how-about-dag-splits)
|
||||
- [Can I have a non-federated room?](#can-i-have-a-non-federated-room)
|
||||
- [What exactly is room upgrading?](#what-exactly-is-room-upgrading)
|
||||
- [What are these idlekicks for inactivity, why are they for?](#what-are-these-idlekicks-for-inactivity-why-are-they-for)
|
||||
- [But the relaybots look so ugly](#but-the-relaybots-look-so-ugly)
|
||||
- [I am told that I should Matrixify my IRC channel, what does that mean?](#i-am-told-that-i-should-matrixify-my-irc-channel-what-does-that-mean)
|
||||
@ -38,6 +40,7 @@ I also have a [txt with a list of all my accounts](/txt/matrix.txt) which [has S
|
||||
- [That doesn't help me](#that-doesnt-help-me)
|
||||
- [Personal questions](#personal-questions)
|
||||
- [Why so many accounts?](#why-so-many-accounts)
|
||||
- [Brief history of my experiences with dead homeservers](#brief-history-of-my-experiences-with-dead-homeservers)
|
||||
- [Why do you use Matrix URI scheme instead of matrix.to?](#why-do-you-use-matrix-uri-scheme-instead-of-matrixto)
|
||||
- [Why does one of your accounts have capital letter in the username?](#why-does-one-of-your-accounts-have-capital-letter-in-the-username)
|
||||
- [Which client do you recommend?](#which-client-do-you-recommend)
|
||||
@ -72,7 +75,7 @@ links._
|
||||
- [n/matrixspoilers](/n/matrixspoilers.html) has a quick note on spoilers.
|
||||
- [apothecary.gay has a Matrix Tips & Tricks page](https://apothecary.gay/rules/matrix-tricks/)
|
||||
- At the time of writing also on using spoilers and custom emotes/stickers.
|
||||
- Cos has written [Matrix tips they don't tell you](https://wordsmith.social/cos/matrix-for-company-use-should-we-disable-federation) containing a FAQ, hints and guides.
|
||||
- Cos has written [Matrix tips they don't tell you](https://wordsmith.social/cos/matrix-tips-they-dont-tell-you) containing a FAQ, hints and guides.
|
||||
|
||||
### How do you do custom not-emoji reactions?
|
||||
|
||||
@ -145,6 +148,56 @@ People understanding state resolution (which by the way don't include me)
|
||||
disagree on the exact cause only agreeing that it's difficult to fix. From
|
||||
what is told to me, I understand it to be tracked [in the same Synapse issue #8629](https://github.com/matrix-org/synapse/issues/8629).
|
||||
|
||||
### Can I have a non-federated room?
|
||||
|
||||
Yes, there are two methods.
|
||||
|
||||
1. During room creation, Element Web offers an option to have a non-federated
|
||||
room. That will permanently prevent any other homeserver from joining and
|
||||
to change that a manual room upgrade is required.
|
||||
1. What I recommend instead is setting a server ACL, so if necessary it can be
|
||||
changed later. This may be helpful when migrating to another domain (which
|
||||
Matrix doesn't support) or cooperation with another entity with their own
|
||||
homeserver or anything.
|
||||
|
||||
The second method begins with the usual `/devtools`, explore room state, `Send
|
||||
custom state event`, enter type as `m.room.server_acl` and contents:
|
||||
|
||||
```json
|
||||
{
|
||||
"allow": ["example.org"],
|
||||
"allow_ip_literals": false,
|
||||
"deny": []
|
||||
}
|
||||
```
|
||||
|
||||
Now assuming all homeservers in the room implement ACL, only `example.org`
|
||||
users can join the room.
|
||||
|
||||
For futher reading about ACL:
|
||||
|
||||
- [matrix.org: Moderation in Matrix, Banning servers from rooms (Server ACLs)](https://matrix.org/docs/guides/moderation#banning-servers-from-rooms-server-acls)
|
||||
- [[TODO: release our server-ACL enforcing scripts]](https://github.com/matrix-org/matrix.org/issues/557)
|
||||
- [Matrix Specification on ACL](https://spec.matrix.org/latest/client-server-api/#server-access-control-lists-acls-for-rooms)
|
||||
- [matrix-org/matrix-spec#928: Consider handling server ACLs through event auth rules rather than at the network level #928](https://github.com/matrix-org/matrix-spec/issues/928)
|
||||
|
||||
### What exactly is room upgrading?
|
||||
|
||||
Room upgrading basically means:
|
||||
|
||||
1. Create a new room.
|
||||
1. Send an event to old room saying "the room has now moved to new room"
|
||||
1. Unless upgraded manually, the client copies some state such as power
|
||||
levels from the old room to the new one.
|
||||
|
||||
Manual upgrading means poking the API endpoint manually and thus not copying
|
||||
creation event (non-federation state) or power levels. For an example see my
|
||||
[matrix-tombstone-room.bash script](https://gitea.blesmrt.net/mikaela/scripts/src/branch/master/bash/matrix-tombstone-room.bash)
|
||||
|
||||
See also [Matrix Specification on room versions](https://spec.matrix.org/latest/rooms/)
|
||||
or `CTRL-F` this page for `/upgraderoom {{site.matrixLatestRoomVersion}}`
|
||||
(Element Web command to perform the upgrade).
|
||||
|
||||
### What are these idlekicks for inactivity, why are they for?
|
||||
|
||||
Some Matrix rooms decide to connect their channel to IRC maintaining the same users on both sides, which can be heavy for the IRC network depending on bridge type of which there are three "major" variants:
|
||||
@ -284,7 +337,49 @@ sending raw events in JSON to them.
|
||||
|
||||
#### Why so many accounts?
|
||||
|
||||
In my opinion it's preferable to have multiple accounts on different homeservers for ensuring decentralisation instead of having a single authority in power and being able to issue commands from multiple servers in case of federation meltdown which multiple rooms experienced during the period of room version 9 before homeserver software started to nag on unintentionally open registration refusing to start. Additionally state resets are a good reason to keep old accounts around.
|
||||
My reasons for that are mane and I am often proved correct in them.
|
||||
|
||||
- By having multiple accounts on different homeservers, there is no single
|
||||
entity that can decide whether I participate on Matrix or not. This is also
|
||||
a benefit of decentralisation in general.
|
||||
- In case of federation meltdown, I have multiple entrypoints to send events
|
||||
and thus hopefully one of them goes through faster. There have been
|
||||
multiple incidents where this could have been useful for room
|
||||
administrators.
|
||||
- Matrix homeservers used to allow open registration with no kind of
|
||||
protection and no warnings they are being ran with that configuration
|
||||
until some time before room version 10 was released. This
|
||||
allowed multiple rooms to be spammed trivially and it took days for all
|
||||
homeservers to sync ACL bans in the worst cases. It also resulted to a lot
|
||||
of state resetting so the affected rooms never got cleaned up as the spam
|
||||
users kept coming back and clients had issues handling so inflated rooms.
|
||||
- State resets keep happening and thus I cannot trust other accounts than the
|
||||
one which created a room in question stay as power level 100.
|
||||
- Homeservers come and go, sometimes with little to no warning. As I have many
|
||||
functioning accounts generally with power levels set, homeserver migrations
|
||||
take me less effort than going through every room and ensuring just now
|
||||
created account has power.
|
||||
|
||||
##### Brief history of my experiences with dead homeservers
|
||||
|
||||
Believe my concern on homeservers coming and going or not, no one is safe.
|
||||
|
||||
1. 2018-09-07: [Disroot.org announced Matrix closure](https://disroot.org/en/blog/matrix-closure).
|
||||
1. 2019-04-12: [Matrix.org was compromised](https://matrix.org/blog/2019/04/11/we-have-discovered-and-addressed-a-security-breach-updated-2019-04-12)
|
||||
resulting the homeserver being down for a while, some integrations even
|
||||
longer and the XMPP bridge returned months later.
|
||||
1. From Disroot I moved to Feneas thinking that homeserver being a paid
|
||||
membership benefit would help it to stay up and be reliable. However in
|
||||
late 2021 and early 2022 we decided to disband the association due to
|
||||
COVID-19 pandemic, lack of volunteers, lack of money (which wasn't helped
|
||||
by [Finnish money gathering law issues](https://github.com/liberapay/liberapay.org/issues/30)
|
||||
etc.
|
||||
1. Around 2023-04-24 the-apothecary.club went down and writing this on
|
||||
2023-04-30 I am yet to hear anything about the downtime. Was it by intent,
|
||||
will it return, anything? However I haven't been participating their
|
||||
community in a long time and I was only using the account for testing
|
||||
purposes so the information not reaching me is understandable, especially
|
||||
considering their homeserver main room is not federated.
|
||||
|
||||
#### Why do you use Matrix URI scheme instead of matrix.to?
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user