I wish I could like XMPP, I really do, but no client I have used has a block function properly implemented, as in, you can’t unblock people you have blocked, and I tested it with a friend a few weeks ago and found that clients that don’t properly implement a block function (as in, not even letting you block anyone) can easily message someone who has blocked them from another client. This is an immediate No for a chat protocol in my opinion
I’m with 'ya - I was fully in to the XMPP ecosystem a few years ago and found the clients so incredibly frustrating (for a variety of feature implementation issues) that I had to dump it. XMPP isn’t for families, and from what you’re saying, not good for personal safety either.
Give it a try again, lots of things have improved with XMPP clients in recent years.
Blocking also usually works, but the default way of dealing with unwanted communication in XMPP is to not approve contacts in the first place. Of course there can always be cases where that might not be feasible and where blocking also fails.
I’ve more than my fill of XMPP experience since it was Jabber. Pretty completely done with it at this point - and my most recent experiences were still not great, and they’re within the past couple of years. My standpoint isn’t just from a user level, as well. Have run a few XMPP servers over the years.
Element, on the other hand, has really become an excellent client.
Personally I don’t think blocking is that important, because most of the time problems can be resolved in another way, like ignoring the messages. However, it can be necessary in extreme cases, and in fact it is already implemented in XMPP at the server level, as I understand. So there are probably many clients that support blocking whichever JID’s you desire. I myself have used the blocking feature in the past.
Personally I don’t think blocking is that important, because most of the time problems can be resolved in another way, like ignoring the messages.
Blocking is extremely important to personal safety. “Ignoring” isn’t appropriate advice to anyone who’s even been deluged with crap from a harasser.
Well it just depends on your mental fortitude. Harassers always stop when they don’t get a response, because your response is necessary for them to continue. Getting the messages at all can be upsetting, but the power is in your hands to delete them and not let it get to you.
No, harassers don’t always stop - this is a very simplistic view of things. Just ‘buck up’ and all will be well, eh? Have I misinterpreted your comments, or do you also believe that people who are on employment insurance are just lazy?
Case in point.
For me, blocking is one of the most important features any social app (chats, social media, etc) should have. I tried using Jabber to block my friend and had them message me from Xabber (from which I was entirely unable to block anyone), and their messages came through just fine. Months before that test, I had tried to test blocking someone else, but was unable to unblock them, even though all my clients said they weren’t blocked. I simply remained unable to message them, and the client kept telling me I had blocked their JID.
Could this have been an issue with the server I was using?
What client were you testing? It’s worth a bugreport if the block feature didn’t work as expected
It’s possible that the implementation leaves something to be desired. Because I have used this feature so little myself, I will have to investigate to see what is truly going on and know how the server handles it vs. how the client handles it. I am currently using Converations on my phone with a Disroot account, and I have someone blocked. When I go into “Account details” I can open “Show block list” in the drop-down menu and they are still there. (As they should be, lol.) I can hold down on it and elect to unblock them. My understanding is that the server keeps this list and doesn’t allow messages directly from that JID to even be delivered to my client. I can also imagine some clients not being aware of this at all.
Even though I blocked their JID, it’s possible we both can be in the same MUC and I get messages from them through the MUC itself. I’m not sure if it’s possible to block that without help from the MUC’s admin.
Edit: One caveat here is that if you block individual JID’s, someone could create more JID’s with which to message you. Some XMPP servers have this behavior whereby they silently delete all incoming messages from people you haven’t added to your roster, so this “add-first” policy helps them keep out spam. Ideally you would be able to contact your server admin in cases of abuse if it would become necessary to block problematic servers or warn the admins of said servers of abuse.
Even though I blocked their JID, it’s possible we both can be in the same MUC and I get messages from them through the MUC itself. I’m not sure if it’s possible to block that without help from the MUC’s admin.
Yes that is not possible as only MUC admins actually know the real user JID (privacy feature), so a client can not know that the person in the MUC with the pseudonymous nick “marmulak” is the same user as the “[email protected]” on your block-list.
Are most of the public XMPP onion servers robust (Calyx doesn’t even have a V3 address)?
If you’re using the onion to reach the server and not as domain part of your JID, sure. but federating with @.onion adresses is definitely not very widely supported in the ecosystem.
Some forums (of sorts) are on IRC. Are there such forum-type groups on XXMP? I don’t need chat, just forums/good info.
Not sure what you mean by forums on IRC, but yes there are some project related channels to discuss via XMPP. You can also join any IRC channel quite easily via the great XMPP-IRC Biboumi gateway (It is basically a IRC bouncer you connect to with an XMPP client).
The Libervia project has also implemented actual web forums utilizing XMPP, but it is still quite basic tbh.
thanks. I used Pidgin and Telegram for a short while (not now) and both had forum-type groups for projects and we ask and answer questions. One dev helped me set up his tiny project - a Pidgin plugin/addon, I think. Pidgin has XXMP. I might try it. judging how worth the effort it is.
Pidgin is a really outdated XMPP client though, it basically hasn’t seen much improvements for the XMPP side in 10 years. Better try another client.
oh, thanks for letting me know.
The better question is whether there’s something better than XMPP?
Depends on your usecase.
If you want strong censorship-resilience, Matrix is a better alternative. If you want a clear privacy/security model (with some caveats), XMPP is the best we have so far.
How is the privacy/security model better with XMPP?
XMPP is a simpler system that works on a “need to know” basis, meaning that servers and clients more or less only get the (meta) data that they need to function but not more. A group-chat for example exists only on one server and chat-history is only shared on request and usually is deleted quite quickly (that depends on the server settings though).
Matrix on the other hand works on a “replicate everything” basis (to be more resilient to censorship and other network disruptions). For that it runs a highly complicated distributed database where all (meta) data is automatically shared with all participating servers and is stored indefinitely. This has its upsides and downsides, but from a privacy/security perspective this is a strict negative.
I think your information on what matrix does with metadata is outdated or over-encompassing, or both. Is your knowledge on matrix up to date? (I’m asking honestly because I immediately went searching for what the current situation with matrix is, and most of what I find with regard to this was heavily worked on in 2019 and 2020 - maybe it’s still being worked on, but it doesn’t seem to be talked about much any longer).
It sounds like, for all practical purposes, Matrix should be plenty private. If one needs extreme levels of privacy, I don’t think you want to join an untrusted server, and definitely not join group chats. One couldn’t pretend to be cautious and do those things anyway.
On, on a complete side note - (and here I am doing an edit) - were you aware that every time you edit and submit, you may be sending out notification emails? I got a new email notification for each edit you made on yours.
Ah sorry for the notification spam. I did indeed edit a few times to make the message more clear.
I think my info on Matrix is pretty up to date. Yes message “pruning” in Matrix was indeed improved a bit in recent years, but the fundamental difference in system-architecture remains.
I can’t say that I am not biased in favor of XMPP of course, but I think my original message is pretty neutral and based on facts. From a security/privacy perspective not replicating data at all is always better, even when additional safety precautions like e2ee (that do exists in Matrix) mitigate the impact to some extend.
A group-chat for example exists only on one server and chat-history is only shared on request
That is technically true, but all servers from which users connect to the chatroom effectively get their hands on that traffic anyway to deliver it to the user (and could log it), which why end-to-end encryption is encouraged in chatrooms. [1]
It’s a tradeoff of XMPP that clients usually only interact with their own server (this is also true for Matrix). , This is done for scalability, reliability, and privacy. This way remote servers cannot for example record your IP address.
However, it’s very possible to negociate out-of-band access to some resources from your XMPP account (where leaks could occur, eg. for downloading on the web an image another user uploaded in a groupchat). For example, XEP-0070: Verifying HTTP Requests via XMPP defines a protocol for authenticating Jabber/XMPP users on the web.
[1] OMEMO encryption works rather reliably on “modern” clients in private messages and private groupchats, but is not yet supported in public chatrooms because encryption for so many recipients is resource-expensive and key verification in a public setting is a nightmare (do you really trust all those keys if anyone can join?) so there’s arguably little benefit in that.
That is technically true, but all servers from which users connect to the chatroom effectively get their hands on that traffic anyway to deliver it to the user (and could log it)
Yes, but only the data it needs to know to deliver what the client requests, not the full historic room state as in the case of Matrix.
I don’t think it’s better, but it’s certainly different. For example, the XMPP ecosystem is mostly not based on web technologies, which makes incentives to build lighter clients: they have less attack surface, and arguably less unexpected fingerprint/leaks than a modern web browser engine.
Still, there’s plenty of good and bad aspects with both. I’d say the reference implementation of Matrix (element) is pretty solid security-wise (good crypto, lots of eyes) compared to more amateur-ish XMPP clients, but on the other hand XMPP clients tend to play well with onion routing, while Element as a web client is quasi-unusable in the Tor Browser (lots of UI actions appear to be latency-sensitive) and using another javascript-enabled browser (than the Tor Browser) over tor defeats the whole purpose thanks to WebRTC leaks (and others).
I’d recommend you take a look at this FAQ. If something is not clear or missing, just ping us and we’ll add relevant information :)
How easy would it be for a government (USA), to block or attack Matrix/XMPP servers, or place the people/admins using them under surveillance? How resistant is Matrix/XMPP in China, Iran, and other places? Is there something better?
From the FAQ i linked:
While it is highly unlikely that a government would block the whole XMPP protocol (which is used for many things), it is entirely possible that they block specific servers, or block client connections to foreign servers, as is the case with many services going through China’s Great Firewall for instance. (…) In the most extreme cases, it is possible for a network operator (or government order) to block the Jabber/XMPP network entirely. In this case, using censorship-circumvention mechanisms like Tor can help you stay in touch. However, please be aware that circumventing government censorship may be a criminal offense where you reside, and you may end up having trouble with your local authorities if they find out.
Both XMPP and Matrix can be reached via HTTPS so it becomes complicated for complete eradication. If state-level censorship is a concern of yours, Matrix is certainly more suited as a protocol as it has complex algorithms to resolve global state (consensus) in case some servers can’t talk to one another.
Some other technologies like Briar are even more suited for this threat model, as it assumes all networks are compromised and/or unreachable. That is, it relies on gossip over lan-friendly medium (local wifi, USB keys…) with optional use of Tor onion services for reaching through the Internet without exposing so much metadata (beyond the fact you’re using tor).
The gossip protocol is interesting. Have also been interested in swarm, Whisper, devP2P, libp2p.
In Matrix client to server connections are just normal web-traffic, so that would require some deep packet inspection to block (pretty difficult but not impossible), however server federation uses a custom port and could probably blocked more easily.
XMPP by default uses custom ports and is quite easy to block by firewalls / routers, however it is possible to also use it via a normal web connection to circumvent that. That said, a lot of professional services use XMPP internally (emergency communication services, smart-meters etc.) and thus wide-spread blocking would be pretty disruptive for a lot of things. It is also possible to connect to and run a XMPP server entirely through TOR, which is pretty hard to block.
Neither is really great in that regard, but they are still harder to block then centralized commercial services (although Telegram tries to be “smart” by hosting their stuff on AWS etc, which also makes it hard to block as other stuff would be effected). Using XMPP through TOR should be relatively resilient though, but note that in some countries using TOR and other such services is illegal by itself AFAIK.
I like that a XMPP node can be hidden on the Tor network, however I have some concerns on the safety of connecting to Tor, even through bridges (if a government can setup a bridge and then monitor connections).
I like that XMPP servers can talk to each other.
