What are /r/matrixdotorg's favorite Products & Services?

From 3.5 billion Reddit comments

>Will the encrypted conversation copy be stored only on those 2 servers or on all servers?

Yes, each server "hosts" the room.

​

>Will the 2 servers broadcast new entries to the conversation to all servers or only to each other?

Message-Events get send to all participants of that room.

If a server is not (yet) part of a room, they wont get the message-event.

​

Have a look at the specification: https://matrix.org/docs/spec/#room-structure

Whilst a room has an ID and a server, the server is only really necessary to be able to "know" a server in the room-swarm

To elaborate a bit:

curl \ -X PUT \ -H "Authorization: Bearer $TOKEN" \ -H 'Content-Type: application/json' \ "$SERVER/_matrix/client/r0/rooms/$ROOM_ID/send/m.room.message/m.$(date +%s)" \ --data '{"body": "'"$INPUT"'", "msgtype": "m.text"}'

(taken from https://github.com/ara4n/random/blob/master/bashtrix.sh )

See the spec: https://matrix.org/docs/spec/client_server/r0.6.1#put-matrix-client-r0-rooms-roomid-send-eventtype-txnid

I disagree with the comment by u/DonDino1. I'm running on a Linode 4GB machine ($30/month), where I also run a bunch of other stuff so the $30/month makes sense for me. I've been running for almost two years and joined some large rooms during that time. I've got about 25 users, and right now my entire system is using only 17GB on the VPS.

Unfortunately, changing your username is not really feasible, especially if you've joined rooms federated through other servers. But you can always easily change your display name.

About a month ago I migrated from a raspberry pi 4 to a VPS because the pi's SD card died while it was hosting from a friend's house. I restored the backed up DB to the VPS just fine. If you use pg_dump to create backups of your postgres database, you'll be able to restore or move the database around without a problem, even across different architectures. Reach out if you need help.

Not yet, it's a non trivial problem to solve in a distributed system. At least there was some progress this week with a new proposal to the spec around how it would work

>If I were to create my own client for a Matrix server, is there any documentation that could help me with this?

https://matrix.org/docs/spec/

https://matrix.org/docs/develop/

But really, this will be way too much for you. You can create your own chat application (not based on the Matrix protocol to keep it simpler), and it would be a great experience, but don't do it with the goal to actually use it for communication with your friends.

From personal experience, being an average server-running person (so not an expert)...

>I'm also kinda fed up with the amount of chat services I need to maintain. Matrix seems like a very good alternative.

It's understandable to want to merge everything into one chat app/service, but you'd need to get everyone you know to use that service, which is usually hard to do.

​

>Can I export all data related to specific users to a new server?

Generally I'd say no. You'd need to move the entire database, which may or may not work. By the time you want to move it (i.e. if you'll have already been running the server for a few years), the DB could be huge, plus there would be signature keys to move etc.

Also I don't think there is a way to change your username, except maybe by manually editing the DB, which is never a good idea.

In the short time I experimented with a Matrix server, I found it time-consuming and/or expensive to run. As I joined a few matrix.org rooms, my DB started growing quite fast, so I had to learn how to keep it trimmed. I found that process too time-consuming and complicated, but of course more experienced people might find it's not a big hassle or be able to automate it via scripts. If I had not been doing that, my DB would have grown to a size I couldn't financially sustain (I had it on a cloud VPS) fairly quickly.

Nevertheless, there is nothing like personal experience. If you do have access to a server, preferably one you own and that doesn't belong to your father, go ahead, install Synapse and experiment with it. It's the only way to find out, and you'll learn a lot in the process.

No, I rent my home server from https://ems.element.io. It’s run by the same organization that makes Element. I believe they use Amazon servers. I could run my own home server, but I want the 24/7 reliability that EMS gives me.

I heard about etke from reading This Week in Matrix blog posts. https://matrix.org/blog/posts

If you are comfortable with the linux command line, nginx/apache and a bit of networking (enough to set up nginx/apache as a reverse proxy if you need to, and open the right ports if not already open) , it's fairly straightforward to install Synapse.

I used a couple of guides (there are many!), one from matrix.org and one frop upcloud.com, they each cover it from different angles. You can read 2 or 3 guides and see which one (or which parts of each one) fit your use case.

The long term plan is actually to completely disable the Matrix.org homeserver. This doesn’t mean they will force everyone off it, but that they will simply not be a need for it anymore. The goal is to have Matrix be fully P2P, making every device running Matrix a “server”.

This would mean Matrix would not require traditional servers much at all, which gives users true control over their own communication.

Of course this is just a long term plan, and who knows if they’ll actually get there. But they are working on it in hopes that Matrix will get there.

I don't think you can carry on without a SSL certificate. In addition, you will need a domain for that.

Luckily you can get both for free: ddns.net for getting the domain and https://letsencrypt.org/ for the SSL certificate.

Not sure what you're presenting here, it looks like you sent them a doc and "they" marked it up? Could you specify who "they" are?

​

I suspect that there is confusion between "the protocol matrix" & "the server hosted at matrix.org" But I need more context to be sure about this. Regardless, it's definitely an easy point of confusion!

​

The only thing I feel confidant saying without more info is that of course if you're sending a single message on (or through) their server, it will need to know your username!

It seems like it'll work. But is it production ready and support a large userbase (guessing a couple hundred people for you)? My guess is no, I wouldn't run anything that mission critical/in production on Dendrite.

You'd probably be best read the FAQ and read through their blog posts to see if it's right for you to move to Dendrite over Synapse.

Yes and no. (How's that for a definitive answer?).

​

Matrix is fundamentally decentralized. THERE IS NO CENTRAL AUTHORITY. It's all peer-to-peer. This means if you run your own matrix server, you cannot be banned from it. If you are the admin, you can (of course) ban other users from your server. The admin can also choose to block/allow other servers to communicate. So your server can be blocked from other servers. Also individuals on any server (including your own) can block you from talking to them, just as you can block them from talking to you. But if you're an admin on your own server, you can never be banned from that server, ever. That's the beauty of decentralization :)

​

To be clear, there's a matrix server at "matrix.org" That sure is a big node in the matrix, but it's only one node. While they can certainly block you (or your server) from communicating to their server, they have no ability to block you from connecting to your server--Ever.

matrix.org, or whatever homeserver you use/set up for yourself, will have direct knowledge of your IP/VPN's IP.

Individual users, whether on the same or different homeserver, will not have direct access to each other's IP.

What are the resources (CPU/memory) available to your homeserver?

Joining large federated room like #matrix:matrix.org can take a long time as the entire state of the room needs to be fetched from a remote server. In some cases this can be several hundred MB of JSON. It can take a beefy server a while, or a small server a long time to process all of that.

Making room joins faster is one of Synapse's goals over the next few months, both from the implementation side, as well as reducing the amount of data that needs to be sent over the wire via changes to the protocol. The following section of the Matrix end-of-year wrapup touches on this in more detail: https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-special-2021#fast-joins-over-federation

I don't know if the issue can be fixed in element, but if you don't have another solution remember that there exist multiple clients and that some might have notifications without relying on google services (I never used any alternative client so I can't recommend you any though)

According to this there is a config option in the latest synapse:

> Today, we're ridiculously excited to be launching Space support as a beta in matrix-react-sdk and matrix-android-sdk2 (and thus Element Web/Desktop and Element Android) and Synapse 1.34.0 - so head over to your nearest Element, make sure it’s connected to the latest Synapse (and that Synapse has Spaces enabled in its config) and find some Space to explore! #community:matrix.org might be a good start :)

Not exactly sure where the config file is, it’s maybe in of the directories where synapse was installed in. Or you could ask on #synapse:matrix.org

Sample script:

#!/bin/bash USERNAME='@test:matrix.org' SERVER='https://matrix.org' PASSWORD='ChangeMe' ROOM_ID='' MESSAGE='Test message'

# get token TOKEN=curl -s -X POST https://matrix.org/_matrix/client/r0/login --data '{ "type": "m.login.password", "user": "'"$USERNAME"'", "password": "'"$PASSWORD"'" }' | grep \"access_token\" | sed -e 's/.*"access_token": "//' -e 's/",$//'

# check that you're joined to the room (redundant if you know you're already there) curl -s -X POST "$SERVER/_matrix/client/r0/join/$ROOM_ID?access_token=$TOKEN" > /dev/null

# send message curl -s -X PUT "$SERVER/_matrix/client/r0/rooms/$ROOM_ID/send/m.room.message/m.date +%s?access_token=$TOKEN" --data '{"body": "'"$MESSAGE"'", "msgtype": "m.text"}'

In Matrix, removing messages is called redactions and doesn't really remove messages, it just tells servers to remove "human readable information about a given message". This can be handy for moderation work. After a while, the message should get really deleted. https://matrix.org/docs/guides/moderation#redactions-aka-removing-messages

Also, using a federated platform is even more a matter of trust than regular platforms. Trusting your own server can be easy (because you can set up your own and check how it works), but you need to trust that all the servers in the room also work properly and do indeed delete content when your server asks them to.

^^This ^^was ^^posted ^^by ^^a ^^bot. ^^Source

In Matrix, removing messages is called reactions and doesn't really remove messages, it just tells servers to remove "human readable information about a given message". This can be handy for moderation work. After a while, the message should get really deleted. https://matrix.org/docs/guides/moderation#redactions-aka-removing-messages

Also, using a federated platform is even more a matter of trust than regular platforms. Trusting your own server can be easy (because you can set up your own and check how it works), but you need to trust that all the servers in the room also work properly and do indeed delete content when your server asks them to.

I’m not sure of an answer to either one of your questions, I’d recommend posting an issue on synapse github for both of them.

For the second issue perhaps try opening the user that can’t open messages in another matrix app like fluffychat.

Stumbled across your post while trying to figure out how to prevent regular users from creating Public rooms.

I deployed Rocket.Chat into our organization a few years ago. It's come a long way since we first started using it, however as we've grown, and with a lot more people working remotely now, some pain points have come up that are not initially obvious.

• Push notifications are limited to 10,000/month on the free tier and require you to be registered with their Cloud service, and have your personal server registered with their Cloud service. Push notifications are not reliable. I'd say I only receive about 1/4 of the notifications I should.
• E2E Encryption is in beta and does not work properly. @ mentions for users do not work in Encrypted channels, and users are prompted to setup their encryption key every time they log in. Doesn't seem to remember they've already done it.
• If the user tries sending a message when the server is unavailable (server down, client has no internet on their device), the message just fails. It doesn't check for connectivity first, and queue the message if the server isn't available. This is a huge pain point for our installers who are frequently trying to send messages while in elevators with no cell service.
• The Rocket.Chat Electron desktop client's auto-update feature hasn't worked in years, and they seem to just be ignoring that fact. Opened an issue on their GitHub a long time ago with a lot of responses of people having the same issue, and it's never been acknowledged by their dev team. This makes it very unfriendly to admins looking to deploy the solution to their work environment, as any subsequent client update will need to be done manually.

I could go on, but these are the major pain points for us, and the driving reason I'm now testing out Matrix Synapse and Element.

There are donations, investments and also https://modular.im/ that they get money from.

As for individual help, all on the bottom of their website is a "Support Matrix" section with patreon, liberapay and cryptocurremcy wallets