[matrix] Conduit Beta at Ungleich(ungleich.ch)
ungleich.ch
[matrix] Conduit Beta at Ungleich
https://ungleich.ch/u/blog/2022-07-10-launching-ipv6only-conduit-matrix-server/
5 comments
What about user management? I only tried conduit for one day, the setup was fine, everything advertised seemingly worked. But i got really disappointed by the administrative interface. There is basically none, at least not without setting up scripts, monitoring panels etc yourself. I'm no professional sysadmin, so for something targeting selfhosters it needs to get robust administration built into it by default: there's gonna be mistakes, it's not gonna be well tended to daily or even weekly. I'd really like to use this, but i will wait until it's more robust in real-life scenario.
I should add they apparently try to go with an "admin channel" to which you send commands to to manage the server. This is imho a good and accessible idea. But at the time i used it it was very limited and i basically had to reset the db when i had the bad idea of activating e2e encryption on that room.
My take on dendrite is basically the same: seems like the core stuff works well enough, but real life administration and monitoring is messy (or mostly non-existent actually).
I should add they apparently try to go with an "admin channel" to which you send commands to to manage the server. This is imho a good and accessible idea. But at the time i used it it was very limited and i basically had to reset the db when i had the bad idea of activating e2e encryption on that room.
My take on dendrite is basically the same: seems like the core stuff works well enough, but real life administration and monitoring is messy (or mostly non-existent actually).
The admin room has a lot more commands nowadays:
- create-user: Create a new user
- database-memory-usage: Print database memory usage statistics
- deactivate-all: Deactivate a list of users
- deactivate-user: Deactivate a user
- disable-room: Disables incoming federation handling for a room
- enable-room: Enables incoming federation handling for a room again
- get-auth-chain: Get the auth_chain of a PDU
- get-pdu: Retrieve and print a PDU by ID from the Conduit database
- help: Print this message or the help of the given command(s)
- incoming-federation: List all rooms we are currently handling an incoming pdu from
- list-appservices: List all the currently registered appservices
- list-local-users: List users in the database
- list-rooms: List all rooms the server knows about
- parse-pdu: Parse and print a PDU from a JSON
- register-appservice: Register an appservice using its registration YAML
- reset-password: Reset user password
- show-config: Show configuration values
- unregister-appservice: Unregister an appservice using its ID
- create-user: Create a new user
- database-memory-usage: Print database memory usage statistics
- deactivate-all: Deactivate a list of users
- deactivate-user: Deactivate a user
- disable-room: Disables incoming federation handling for a room
- enable-room: Enables incoming federation handling for a room again
- get-auth-chain: Get the auth_chain of a PDU
- get-pdu: Retrieve and print a PDU by ID from the Conduit database
- help: Print this message or the help of the given command(s)
- incoming-federation: List all rooms we are currently handling an incoming pdu from
- list-appservices: List all the currently registered appservices
- list-local-users: List users in the database
- list-rooms: List all rooms the server knows about
- parse-pdu: Parse and print a PDU from a JSON
- register-appservice: Register an appservice using its registration YAML
- reset-password: Reset user password
- show-config: Show configuration values
- unregister-appservice: Unregister an appservice using its ID
Thanks for the heads up, i'll try again.
Neat. I tried conduit a few months ago and didn't find it to be stable enough for my personal usage.
I'll give ungleich's home server a try and set it up again if it works well enough.
Very strange choice to run a public instance that is IPv6-only.
Unless federation is disabled altogether, in which case it doesn't matter, joining a room from an IPv6-only instance with other servers in the room that only speak IPv4 will result in a quite terrible experience. Both sides will depend on dual-stack servers in the room to fill gaps and that will likely only happen when the missing events from the remote side are referenced by something else.
Unless federation is disabled altogether, in which case it doesn't matter, joining a room from an IPv6-only instance with other servers in the room that only speak IPv4 will result in a quite terrible experience. Both sides will depend on dual-stack servers in the room to fill gaps and that will likely only happen when the missing events from the remote side are referenced by something else.
Do you have statistics on how many servers do not support ipv6 at all, maybe weighted by their user count?
Not aware of anything that collects such statistics, no.
[deleted]
Unrelated. Tried Matrix for the first time a few days ago. Horrible experience (very slow). It's a shame it's borderline useless, because it brought back nostalgia from my IRC days.
Have you installed your own insurance? I have been using the matrix.org server along with a bunch of discord and irc bridges. The bridges do break and need attention from the room owners, which they sometimes do not get, but it is not horrible. I am using the element.io web interface. The gui clients I tried have not been better than the web interface.
No, I haven't installed my own instance. If that's a prerequisite to having a good experience, I don't want it.
I value a federated open standard, but I'm not gonna be the one running it...
The android Element client has been sluggish too, but I believe most of the lagginess comes from the matrix.org instance. Matrix supporters seem to brush this off as "oh well, that's just the matrix.org server that's laggy, it's not a problem intrinsic to the protocol." It's the most important server that's borderline unusable!
I value a federated open standard, but I'm not gonna be the one running it...
The android Element client has been sluggish too, but I believe most of the lagginess comes from the matrix.org instance. Matrix supporters seem to brush this off as "oh well, that's just the matrix.org server that's laggy, it's not a problem intrinsic to the protocol." It's the most important server that's borderline unusable!
No I thought running your own might offer a worse experience. That's why I asked. I didn't try it myself.
Honestly I didn't find matrix to be much worse than Discord. I don't know what people are looking for in these kinds of apps but Discord might be the worst (maybe weirdest?) application I used willingly.
Matrix irc bridges are good as an irc bouncer I don't need to run myself and there are a few open source communities that chose matrix as their base. For what I use it for they are fine. My personel favorite in this space is Zulip.
Honestly I didn't find matrix to be much worse than Discord. I don't know what people are looking for in these kinds of apps but Discord might be the worst (maybe weirdest?) application I used willingly.
Matrix irc bridges are good as an irc bouncer I don't need to run myself and there are a few open source communities that chose matrix as their base. For what I use it for they are fine. My personel favorite in this space is Zulip.
To be fair, it really isn't designed to rely on one server. And if you don't want to run your own, you can always have someone host the server for you.
I'm all for the freedom of only providing IPv6 but for federated protocols relying on the servers of others it's a bit weird. Works fine inbound in rooms hosted on homeservers this server can reach, might produce issues outbound (i.e. when someone on a homeserver missing IPv6 tries to DM someone on this homeserver).