Comparisons of XMPP, Signal, MQTT, Tox, Telegram

For ethical reasons I refuse any Google services. Strictly, no joke. Gmail users get a one shot answer from a special email account only for this purpose.
+1
So when it came to google-meet, this had prevented me from participating FreeBSD Bugathon. Period.
IRC is fine & enough to participate. The benefit of video was none, except for those who earn from traffic... I closed it after an hour & was only on IRC. Besides that, it was fun! Hope to see you there next time.
 
For users all in developed nations, XMPP is perfect.

If talking to people not in a developed nation, subject to poor infrastructure or blackouts for whatever reason, XMPP takes up critical bandwidth.
I saw you using the term "third world" and now talking about "developed nations". For my taste his kind of reference has the sound of a little too much hubris. A lot of poor infrastructure can be found i.e. in the "rust belt" or in "fly over states". Even NY and CA has blackouts.

If you wanted to talk about XMPP bandwith, please explain.
 
I saw you using the term "third world" and now talking about "developed nations". For my taste his kind of reference has the sound of a little too much hubris. A lot of poor infrastructure can be found i.e. in the "rust belt" or in "fly over states". Even NY and Florida has blackouts.

If you wanted to talk about XMPP bandwith, please explain.
It's not hubris, and this wasn't about the US where the majority of the time, Internet is reliable and blackouts happen but are rare. A few countries have nationwide Internet blackouts, sometimes intentionally timed. Some countries have low infrastructure as it is. However, this can apply to developed nations (regardless of where in that country) such broadband rather than dedicated DSL-like service, when too many customers are on at once.

XMPP has to hold a lot of data, as it holds the whole conversation as structured by XML, instead of a message at a time. The message data doesn't go directly, as it goes through many points.

When I use XMPP, a server would be in Japan. The Internet connection to the US, Europe or other countries to Japan doesn't have lag. When, the hosting server for the screename was switched to Europe, the connection would be a lot better. It has to do with distance among 3 or 4 points around the world; when these 4 points are all in developed countries, even if the distance is around the world twice, there isn't an issue, as messages will get there within a a few seconds. An XMPP conversation has to go through all of them, and have the whole XML data open, as XML is structured from beginning of the conversation to end.

Someone will send me a message, and it will arrive 4 or 12 hours later through XMPP. When they change names to a tld closer to their country to theirs, there's a major reduction in lag. Sometimes, a conversation will be dropped, and won't return for days. For certain times of a day, XMPP conversations can be made. It reminds me of when I used broadband service, where the Internet would work after midnight. Broadband is described as faster, which it can be, and in theory is, but when everyone is on at once, I rather have a slower but fast for my uses DSL line which is consistent. Even then, I'm not that concerned about broadband and XMMP. The problem is countries which don't consistently have reliable Internet service.

In those countries, where communicating is essential, XML messaging (XMPP) takes up too much critical bandwidth for their infrastructure.

An example of a country like this is Sudan. XMPP is unacceptable for use there. This is about people being able to communicate as they need to, and be not limited by poor or sabotaged infrastructure.
 
  • Like
Reactions: a6h
That's not a bandwidth problem isn't it?
It is, when there's some (perhaps alternate, minimal and basic) internet going on there, or if a minimal bandwidth network can be established. No matter how minimal and basic.

For instance, what if 90% of the Internet was cut intentionally, and there's 10% that can't be cut. Bandwidth matters there.

It's also bandwidth, when it has to do with infrastructure by itself, including if Internet infrastructure is kept under-maintained to restrict communications.
 
[...] XMPP has to hold a lot of data, as it holds the whole conversation as structured by XML, instead of a message at a time. The message data doesn't go directly, as it goes through many points. [...] In those countries, where communicating is essential, XML messaging (XMPP) takes up too much critical bandwidth for their infrastructure.
And what's a reasonable low-bandwidth alternative for XMPP? I tried TOX, but in contrast to XMPP+OTR encryption, it causes a constant data stream of several kbit/s. Mathematically, that makes it harder to break by brute-force attacks, but it's much more data intensive. IIRC I can enable compression in XMPP? I guess that helps with low-bandwidth connections, but keeping XML eases to build robust clients, because many libraries to parse XML exist for all reasonable programming languages & toolkits/frameworks.
 
  • Like
Reactions: a6h
What is specific to XMPP and wouldn't this hurt other protocols too?
More data can get through with other protocols, because XMPP uses XML, and because each message has to go through all points. That it uses XML itself for unnecessary data for messages causes a lot more data use. Other protocols go through all points for the connection, then the shorter route more direct for each message.

If XMPP takes up 10MB, and another protocol takes up a few KB per 20 messages. With a minimal network, more message of that other protocol get through. Let's say it's next door, and the server is in Europe. Instead of communicating directly to either next door or the closest ISP, that connection goes through Europe and back. XMPP is also like a clog on those infrastructures.

As with anything. More people can exit at a time through a big garage door than a small door. More water will flow through a larger diameter pipe than a smaller one. If someone puts a wooden block in a toilet, it will clog. The more that can get through, the better. If there are 5 open doors, and only 1 door is open, the more that can get through that by needing lower resources to get through that door.
 
And what's a reasonable low-bandwidth alternative for XMPP?
That's what this whole thread is about. There's nothing really ideal, the closest things are Signal, UseCrypt or SIP/SIMPLE not without being an expert on setting it up. XMPP is perfect when all points are through developed countries.

They need an XMPP/SIP hybrid, where the only thing that would be under XML is used for the handshake and an optional (and not required for messaging when it is used) count of the message numbers to synchronize and display if messages were dropped.
 
and because each message has to go through all points.
.. [for XMPP as opposed to SIP]

For an XMPP connection, each message has to go through all/most points that were used for the handshake, unlike SIP. All messages go between all included servers, which is a extra hop or more around the world. Using a server closer to a country than Japan caused an improvement. Not the short route (bypassing those servers once the handshake was already established) from computer to computer, like SIP.

For a webpage, a server from one place near the Atlantic to Japan or Australia can add 6 seconds to load compared to a visitor to a webpage in the same country or all parties near the Atlantic, to show an example of the lag for a large amount of data, even if the lag for smaller amounts of data is much smaller. There's more data for webpages, but it shows the difference in distance. When a message must pass through Japan, and Europe depending on where each person's XMPP server account is based, in that way. To pass from any combination of developed countries, whether through Japan, Europe, USA, even if it must go from the most indirect routes around the world twice, lag or bandwidth isn't an issue.

Still, XML is a problem. The whole structure of the conversation must be maintained, instead of 1 message at a time. XML consists of required closing tags, and a whole conversation an hour or more long is a sub element of another XML tag. The fact that messages are sub elements of other elements and the XML headers, rather than each message be its own full dataset. Also that each message isn't within it's own self contained XML or other element as well.

For single documents and one way messages (self contained messages), XML based is perfect no matter the network infrastructure. For two way messages, the basis of XML (sub-elements, and headers maintaining a whole conversation) over each message is a logjam on un-reliable networks.

I'm not a fan of JSON and Javascript, for a comparison to be made to that.

XML makes perfect sense for handshakes, logging in/out, terminating conversations, one-way messages/documents and optionally keeping minutes (to indicate messages dropped, or order of messages, and not being required for a conversation to continue, as this doesn't have to be kept up as quickly as the message are exchanged), not for real-time/two way messages. Individual messages within a whole conversation are better off self-contained, than being of a sub-element of other tags and a heading. XML requires structure of that whole conversation (with parts at a time having to be synchronized through 1 or 2 account servers, while maintaining the full XML structure) which is not being made from 1 direction at a time.
 
Here is a reader for using XMPP in constrained networks:


What's described there makes it better.

There's major issues on constrained networks with excess handshakes. The Open-source standards to improve this are at https://www.isode.com/products/swift-open-standards.html. HF radio has an open standard, but it's not listed there: it's very interesting, but not needed for typical use.

XMPP has the Jingle (STUN/TURN) extension to decouple a P2P connection from the server.
Sounds good. How to configure an XMPP client to make use of that.


Still, having to have these as extensions to XMPP and SIMPLE makes it so that applications of it aren't set to readily make use of needed features. They need a hybrid to also consolidate their user bases.
 
Matrix may be a another reasonable alternative. The german Wikipedia says the Bundeswehr (army) is switching from XMPP to Matrix, and the french government decided to switch, too.
 
I found France went with Tchap, which is only for the French government, plus those selected by them. Tchap is based on Element [https://element.io/], formerly RiotChat.


Element is a client for Matrix, https://matrix.org/. Two of its founders are also founders of the Matrix Foundation.

Matrix uses JSON, which means Javascript.
 
off-topic, but with all this open source hype going on, I'm not always shure who's "got the hat on"... Look at the owners of the repositories (sourceforge disaster), and where the server & client-side software used is completely free software... :-/
Not everything is Sourceforge. For example: FreeBSD, Signal, OTF. Everything is different, and everything should be verified/reviewed and left for discussion.

As for for-profits, Twitter isn't Facebook, and DuckDuckGo isn't Google.


When someone with a Windows computer downloaded a Tox client, it might have been from Sourceforge. I don't remember well. They said it asked for access to their files. I told them, then don't use that. It was likely Sourceforge, based on what I remember from the website's design/presentation from that time.

Maybe Tox switched that to host their own download, Github or something else for each OS. Before, what a person needed for their specific OS wasn't available for download from Tox's website.

I don't know if that was Tox's default behavior, if 3rd party developers for an application did that, or if it had other stuff packaged with it.
 
TL;DR-Boys: Don't click on that one!


EDIT:
Skimmers' capabilities may fade due to text excess length.​
Persons getting discombobulated when reading VIP names should not click on that either.​
 
TL;DR-Boys: Don't click on that one!


You are right. I regret even skimming it...

In the early two-thousands, he taught himself to sail by taking a solo two-month round trip to Mexico on a twenty-seven-foot Catalina with a broken engine. Later, he and three friends bought a fibreglass boat on Craigslist for a thousand dollars, restored it, and sailed through the Florida Keys to Grand Bahama Island.

Like what??? Why would i care?
 
A touch decision to make. I have just fitted the whole family with new mobile phones (POCO X3 NFC) running a custom ROM (ArrowOS 11) with microG (instead of Google Play Services) and a line of measures to enhance privacy.

Now I have to decide on a secure open source communication app/service that respects privacy and supports messaging, voice and video calls, and possibly has a desktop-app available that's compatible with FreeBSD as well.

Several options are not an option, one app/service has to suffice, and as far as I can see it petty much comes down to Signal versus Conversations (XMPP).

There is way too much information to skim through, but as it seems XMPP is still too geeky for the general public and chances are higher to convince others to move from WhatsApp to Signal than to using a XMPP client where you have to look for a reliable free Jabber/XMPP server.

Any more thoughts on this?
 
A touch decision to make.
We all honour you to have taken up a 1/2 year old thread! Right you are: this topic is still hot!
DEIT tougj tougj tougj
I have just fitted the whole family with new mobile phones (POCO X3 NFC) running a custom ROM (ArrowOS 11) with microG (instead of Google Play Services) and a line of measures to enhance privacy.
Can't comment, have to investigate further.
Several options are not an option, one app/service has to suffice, and as far as I can see it petty much comes
what a wonderful typo :)
down to Signal versus Conversations (XMPP).
Exactly. Or Matrix.
There is way too much information to skim through, but as it seems XMPP is still too geeky for the general public and chances are higher to convince others to move from WhatsApp
Wrong spelling: correct to: WhatsApe, please.
to Signal than to using a XMPP client where you have to look for a reliable free Jabber/XMPP server. Any more thoughts on this?
Yes: there are gateways, and some nerds/geeks/responsible persons are running these available for the public.
 
  • Thanks
Reactions: a6h
Back
Top