What is Reddit's opinion of
XMPP?
From 3.5 billion Reddit comments
97 reviews of this app found across Reddit:
We already have an open standard for IM apps and some of them (Google Talk or whatever is called now) use it.
The problem is that most IM devs want to lock you in their own clients so they can datamine you, force ads down your throat and who knows what other shady things.
Thankfully we have one of those
It's just a matter of whether these big companies are using it or if they've locked it down so nobody else can communicate with it outside their closed-source client
I'll never knock anyone for trying to contribute to the community, so your effort here is appreciated, but honestly, Discord and several other walled-garden platforms are likely gonna be off the table for a lot of open-source users. Most free, provider-offered messaging platforms exist as analytics cash cows for their providers and not much else. I get that Discord is popular, and I can understand why, but if you want to host a messaging service for a project like GNOME, let me throw my drop in the bucket for hosting an IRC or XMPP server.
xmpp is a an open source / well supported protocol.
there are clients for basically everything. (no seriously, basically everything. my refrigerator has an xmpp client..)
IRC is a very pervasive and simple protocol - which might be reason enough to build an application around a dedicated IRC service back end.
Check out the XMPP protocol, however, and it's extensions. Think IRC, but with an open XML transport - optionally over https for easy secure channel operation and browser<->webservice integration.
XMPP started life in telephony to augment or even replace SIP - and is often still referred to as the Jabber protocol, both inside and outside that context.
Many modern chat platforms use it, like HipChat, GTalk/ Google Talk, and Whatsapp. XMPP's use cases are not just for multi-user chat ( https://xmpp.org/extensions/xep-0045.html ) but also for machine-to-machine messaging ( like NATS or AMPQ -like deployment scenarios).
Google still uses XMPP (although ~~last I heard,~~ they still weren't using encryption for server-to-server communication, which is a little sketchy).
*Edit: Added link since apparently some people don't believe me
Another one? Do we rly need all those apps on different protocols when there is https://xmpp.org ?
Make a kickass client for XMPP everyone will want to use, don't reinvent the fuckin' wheel again, all those new apps fails cause of this fragmentation of procotols.
>>Not particularly web-friendly - you can’t easily speak XMPP from a web browser.
>Why the hell would you want to?! It's a browser, not an IM client.
I agree, and that statement is also factually wrong. Or maybe it was written before 2003, when neither BOSH or websocket existed.
>Apples and oranges. Tox also has a wire protocol.
Did it get specified yet? Last time I looked there was only incomplete drafts and implementations.
I'm positive they're not using Google apps. One guy is hosting his own server on his home network, the other I believe is using some third-party XMPP server host. Both of them are rather paranoid of Google et al.
This article from a few months ago indicates XMPP isn't dead yet, but there are some providers (including jabber.org) that won't federate with Google due to a lack of TLS support.
> It's true that nerds pushed those, but ultimately Google and Firefox became the standard because they are actually useful.
So is XMPP.
> slip the open protocols in
Choose one here: https://xmpp.org/xmpp-software/clients/
Tell them "I like X better because [insert cute reason, such as "it won't bother you like fb chat does"]."
Send them here https://duck.co/blog/using-pidgin-with-xmpp-jabber
Yep, you are right about the many XMPP extensions (XEPs), but this is supposed to be (and effectively is) an implementer's concern. Libraries built around XMPP are surprisingly good, documented, and well maintained with respect to current XEPs and standards. So in practice it's not so difficult to create a new, modern and well behaving client based on "off the shelf" good libraries (like babbler, smack, sleek, …). Same goes for bots (with, say, errbot.io)
I started that experiment some weeks ago of making a client of my own to judge by myself the difficulty, and so far the experience has been positive: I learned a lot about protocols, authentication mechanisms and indeed read a few RFCs and XEPs, not because I was forced into that by the limitations of the ecosystem, but because it grew in me as a sensible and pretty well thought-out stack.
On the topic of combining together and document protocol's extensions as a whole (in a similar fashion as what OpenGL does), this is tackled by the "Compliance Suites" XEPs: https://xmpp.org/extensions/xep-0387.html
This article from May '14 indicates the encryption still had not been enabled, and that was post-Snowden leaks. I'm testing gmail and my google apps domain on the xmpp test site the article linked to, but it's running rather slow at the moment.
~~*Edit: My Google apps domain seemed to fail for whatever reason, but gmail.com passed (results), so it does look like it was resolved after all.~~
~~*Edit2: The passed test was client->server test, the server-server test failed completely for some reason, so I can't say for sure if it's still ongoing.~~
*Edit3: *Edit: This XMPP Blog Post from 2 months ago indicate they still do not support TLS for server-to-server communication.
There is this whole war of communication messengers going on.
XMPP folks have tried to counter the argument put by Matrix people https://xmpp.org/about/myths.html
A lot of the myths of XMPP (including higher power consumption on mobile devices) have been addressed long back. Its so robust, that I would like to receive my reminder messages on XMPP than email from my service providers like the town library, medical providers, my credit card company, the weather service, the word-of-the-day services etc. I understand XMPP has had the same pubsub since a long time, something that Matrix is trying to address as a shortcoming. And pubsub is going to be relevant as IoT matures.
The last universally widely adopted internet standard relevant to end users has been HTTP/2. Everything else is still fighting to become a standard leading to walled gardens with a huge network effect WhatsApp (instant messengers), Twitter (social media), Spotify (internet radio).
Again, as I understand, XMPP has the potential to compete with HTTP than with WhatsApp. There was simply not enough investment done when it was needed on implementing from the big players like Google and Microsoft. Microsoft wanted to promote its own platform based on SIP and Google gave up after trying for a few years trying to promote its own walled gardens after that.
Movim is an example of use of XMPP as an underlying protocol for a federated social platform.
It's using XMPP pubsub, you'll find technical details in XEP-0060 .
Basically, pubsub use "nodes" which we can more or less see as "table" (or "collections") on a classic database. There is one node listing tickets, and each tickets have a link to a comments node (which is using XEP-0277).
In addition, I'm using data forms (XEP-0004) to specify the fields of a ticket (e.g. one of the field is the state of the ticket, i.e. "queued", "in review", "closed", etc.).
So to interoperate, an issue tracker must use XMPP with thoses XEPs. Any XMPP account on any server can read or write to the tickets list or comment an issue if the permissions allows it (pubsub permisson model allows easily to create public or private tickets).
An other nice point, is that it's possible to create gateways to non-XMPP issue tracker, the very same way as we do it for third party chat system. For instance, it would be possible to see and interact with tickets from Gitlab or Github from your XMPP client.
edit: it would be possible to have a fallback mechanism for client not implementing the needed XEPs, for example by using ad-hocs command, or event chat directly.
XMPP - Flexible real time communication protocol - multiple flavours and implementations available
OTR - Off the record messaging - imagine a reporter making a real world "off the record" interview
These two can be combined to provide a secure messaging solution - personally I use pidgin with the otr plugin installed.
Easy to install and setup, there are a lot of detailed guides already available.
Other clients are available https://xmpp.org/software/clients.html if you need an android/ios/etc client.
But why?
When combined XMPP and OTR makes you certain you are talking with who you think you are talking to, this is of paramount importance if you are using it for DNM related communications.
No-one else can read your messages, the level of encryption considered to be better than PGP
No signed messages - this means no-one can prove that the messages, in the case they were intercepted, were sent by you. Deniability
Impossible for >2 people to be in the same conversation, OTR DOES NOT support more than 2 connected/communicating clients - if you read the message sent to you, you can be assured that no-one else can.
Finally and probably most importantly the key pairs that are used for OTR communication are entirely dynamic, so if your private key becomes compromised there is no danger of previous messages being decrypted as the keys for each conversation are NOT interchangeable.
Honestly, I fucking love this stuff - if anyone has any questions feel free to PM me :)
Don't really care for any prizes, was enjoyable enough to just prattle on for 3 mins about security while I drink my morning coffee
> To sum up, all the non-structured data of your app should go to MongoDB and the structured one will be stored on MySQL database.
Wat.
Unstructured data is just a binary blob. Use S3 or GCS. Or if you need something you can host yourself, GridFS.
> Each communication your app makes with the server should be encrypted. A PGP based cryptographic encryption will suffice here.
Sure, don't use HTTPS, which is already implemented everywhere.
> We don’t recommend cryptographic hashes, since it’s very easy to buy or download a list of hashes for all phone numbers.
Why are you hashing phone numbers? Why are you not salting hashes? Why would you send hashes of my phone number to another person's phone? Are you trying to use phone numbers as user identifiers? But people change phone numbers, and sometimes people use mobile devices without phone numbers.
> There’s a reason why Layer charges $1,500 per month. A better way is to either go with Firebase or OpenFire. They both provide XMPP protocols for chat functionality.
https://xmpp.org/software/servers.html
> On a depressing note, nobody except a few knows what exactly goes behind Tinder’s algorithm. But, at the macro scale, it’s a combination of machine learning inspired by real world system dynamics to provide most contextual profiles to it’s users.
Presently, machine learning requires you to have a lot of data. That means many users. You'll need something more manual while priming your neural networks.
> You can:
> * Provide users with a way to report inappropriate content or harassment of any sort.
> * You can add a threshold, e.g. a threshold (number of times a content/profile has been reported) after which the content/profile gets deleted/suspendedOr
> * Do Both
Yes, you can automatically suspend an account based on number of reports without providing a way to report an account. What?
Not too sure if there is an app that supports direct communication with another app, but I've been in the same situation (on a ship) where there was no internet but we still wanted to chat.
Ended up running a small XMPP server like OpenFire (https://www.igniterealtime.org/projects/openfire/) and then using a XMPP client on the phone (Monal - https://appsto.re/au/ms-7s.i)
You can find a list of other XMPP servers here - https://xmpp.org/software/servers.html
I'll just add that I ran the XMPP server on a laptop for a fully portable solution.
Hope this helps
There's XMPP, but I've never actually tried to use it much. There are free servers you can connect to, or you can setup your own server if you want.
I'm also not sure if it's got clients for every platform.
If you care about privacy Telegram might not be the best option anyway since all your messages are stored unencrypted on their servers. A better alternative is, for example, XMPP, as it is decentralized and e2e encrypted using OMEMO.
While HTTP traditionally doesn't permit keeping connections open to stream data, there are ways to do it.
Long polling works without any special server support just by having the application wait for data to appear before sending a response, and if there's no data after a while it will instead return a minimal response to tell the client to make another request. The amount of time you can wait mostly depends on how long various parts are willing to wait for a response; a minute is pretty safe. This is the approach often used by XMPP BOSH, which is a scheme for running XMPP over HTTP.
Websockets are a newer approach to the same problem, which requires protocol support on both ends but looks just like a regular TCP socket that happens to be run through a web server.
Gajim has two plugins that seem to be relevant (I never used these, though):
> Displays a preview of images inside the chat window. > > If you right click on the picture you have several options: > > * Save the picture to a location of your choice > * Open the picture with your File Manager > * Open the Link with your Browser
> This plugin is designed to send a small (0 - 40 kb) graphic images to your contact. > > The client on the other side must support XEP-0071 and maintain the scheme data: URI.
Thanks all those interesting questions! - Movim is considered as a XMPP client, therefor your "Movim account" is also a fully standard XMPP account that you can use on all the others clients ou there (Conversations, Gajim, Pidgin…). - Using Pubsub and especially this specific standard extension of XMPP : https://xmpp.org/extensions/xep-0277.html - Yes exactly, the pods are not storing anything important except some cache to boost things up :) When you're connecting using another pod eveything is synced up automatically, you can even be connected to 2 pods simultaneously (it's like being connected to two XMPP clients actually). - Yes, using this tool https://github.com/edhelas/atomtopubsub/ :) - Because Pubsub is way more than RSS news feed, it's real time (the news are "pushed" to you) it's fully integrated in XMPP, it's scalable and it's well specified :) Also its quite easy to write small tools to import RSS/Atom news feed to Pubsub feeds.
Sorry, but this looks like a terribly thought out specification. Why bother reinventing the wheel yet again when there's XMPP that's already doing everything that Matrix is trying to do and more? Just look at the massive protocol extensions list alone that'll cover everything you could possibly want in a decentralised two-way communication protocol.
Seems to be a mental condition going on in the past couple of years with a lot of these new networking protocol authors where if it's not using JSON or new_text_format_here based then must recreate what's already been done using said text format flavor of the year, but doing it a lot worse by ignoring already existing standards that solved many of the problems they're attempting to solve themselves.
> gajim: what server or hostname do i need?
Gaijim is a XMPP client, like email, Matrix, Mastodon. You can register on one server and talk to others.
Heres a list of public servers:
https://list.jabber.at/
https://www.xmpp.net/directory.php
With XMPP you can use your own GPG/PGP keys or OMEMO for E2EE
Heres a list of clients:
https://xmpp.org/software/clients/
XMPP vs Element/Matrix,Discord,Signal:
- small footprint
- useful on old devices
- works on (almost) any OS
Regarding alternatives, there is the project I work on, Snikket. It uses XMPP, a protocol that is federated like Matrix but has been around a lot longer.
One notable difference is that Snikket (and most other XMPP projects) don't have as strong emphasis on bridging these days, instead focusing on developing the core experience. That said, bridges do exist, such as whatsxmpp (WhatsApp).
If you have time, try out both options and see what suits you best. At the end of the day, that's the best option for you :)
> But XMPP is the one that I thought of being the most fitting successor to IRC that had most of matrix's advantages while being mature.
XMPP would have to be extended by some functions in some areas to become interesting for the masses. For this purpose, there are usually already corresponding XEPs (https://xmpp.org/extensions/). And this has often been the case for years without anyone taking care of it.
And that, in my opinion, is the biggest problem with XMPP. Too little is changing. Matrix, on the other hand, is being actively developed. For example, when many IRC channels moved from Freenode to libera.chat, a bridge between Matrix and libera.chat was created within a few days. This still seems to have bugs, but it works in principle. And they are working on eliminating these bugs.
With XMPP, I have also made the experience in recent years that many servers are configured very differently and therefore some functions were often not offered. So far, I have not experienced this with Matrix servers (even with non-official servers) in the same way.
There is also <code>XEP-0368</code> which seem to have been adopted by quite a few client/servers which allows one to specify dedicated TLS endpoints through _xmpps-{client,server}, instead of STARTTLS ones which can get MITM'ed.
It needed a bit of research because there's multiple Servers available and you need to setup the modules you need. XMPP by itself is a pretty simple protocol but you can add "extensions". For example XEP-0363 (HTTP File Upload) let you upload pictures/video and send them as a message.
I installed Prosody.im, which was fairly easy to setup, once I understood which extensions I needed!
If you are using a local XMPP client like Pidgin then you don't need a web client like xmpp.jp and jabber-hotchilli.net .
Here is a list of XMPP servers. They federate with each other so you can pick any one you want:
Why Pidgin for XMPP? There are lots of dedicated clients available:
This is what you get when you increasingly have to depend on corporate walled gardens for all communications - not that there is much choice in that these days when the network effect ensures that everyone you care to communicate with is also on these platforms.
They are of course within their rights to define what is allowed or not allowed, nobody is entitled to a platform to air their views - but if you want to be free of the pitchfork thought police brigade you'll just have to use your own server, or use an open standard like Jabber/XMPP for chatting.
>Anyways, the other party was very upset and in all likelihood reported me after our discussion.
The worst part are the fucking petty authoritarians who aren't content with ignoring or blocking stuff they don't like - oh no, how dare you say anything that offends me, here let me get your account nuked at best and your life destroyed by doxxing and reporting to your employer (where another control freak in HR will jump to assist me) to get you fired. But nothing fascistic about punishing people for thoughtcrime whatsoever of course.
To suggest an alternative, Disroot.org provides a free and privacy focused set of services from XMPP to Nextcloud to WebDAV file storage and more.
As for XMPP, there are any number of free servers and clients available - it works like email. Anyone registered on any Jabber server can chat with anyone else and if you are offended, close the chat, block the other person and get on with your life. The way the internet used to function before the 2010s happened and a handful of companies took control of everything.
I mentioned file sharing not as a means for a/v chatting, but to point out the underlying requirements are already in place.
I think xmpp is a good choice. Open, decentralized, very popular (Facebook and Google both use it for IM services, or about 5G user accounts), can do text, video, voice, fire sharing, and logs. Multiple clients for just about every platform.
Probably Client-to-Server Examples would be more informative - it gives you example of the flow.
In principle, you should: * open stream to the server * perform TLS (optional, but more and more required) * authenticated (most popular is SASL, which has many mechanisms - most basic one: PLAIN, is just username and password encoded in Base64) * bind resource
I wouldn't recommend using google servers as they offer some quirks, but you can register for an free account on tigase.im service.
You can also check out Tigase JaXMPP Client Library for inspiration.
Since I was also interested in this I tried lookging for xmpp apis in c# on .net/.netcore base.
This is what I found: https://xmpp.org/software/libraries.html which point specifically to https://www.ag-software.net/matrix-vnext/ and https://waher.se/IoTGateway/Libraries.md#networking
The second one seems to be written for IoT stuff. the first one contains at least a c# sample. Based on the first one it should be possible. But it seems like the only way to make it PowerShell native is to a) call a bunch of c# calls or b) to write a c# module.
If you're talking about sending actual SMS messages then you're out of luck. iOS doesn't allow access to those. You'll be able to populate a message in the Messages app, but the user will have to hit send.
Depending on your requirements you might be able to get away with an app extension of the Messages App: https://developer.apple.com/documentation/messages
If you need to build a dedicated messaging app you should look into XMPP servers and interacting with them. I've never implemented one, but I'm sure you'll be able to send location data grabbed from CoreLocation and associate that with a message. This website has a list of them: https://xmpp.org/software/servers.html
Hi zaidka, main developper of Movim here. XMPP already contains everything to do realtime news feed by default (especially with the https://xmpp.org/extensions/xep-0060.html that is now available on most of the XMPP servers).
We simply used the existing standard and implemented it in Movim in a "news feed" UI.
Actually, with client state indication the xmpp connection can just be a passive open websocket which hardly drains any energy. I run conversations 24/7 without any issue (conversations uses less energy than my email client, for instance, even though I typically use it more).
This is the core issue with iOS, though, since it doesn't allow a continually open connection, and thus requires push in order to work properly. This is in the xmpp spec but it's not widely adopted, and requires some work server-side, which I haven't done yet.
Actually, privacy and interoperability are two different things. Do you know that you can pick up one of the XMPP server implementations and build your own server using that? Yes, you can create your own private walled garden with XMPP if you want, but those who want interoperability, they can have it too.
Whatever reasons TPTB had for choosing Skype, privacy isn't one of them. Hell, its now even known that Microsoft shares data with the NSA, so how is Skype so full of privacy?
> Replaced with what? No other form of communication has been better for me
The same thing we replaced voicemail with: Mostly nothing.
But in all seriousness I do agree that there's no perfect medium or platform. A signal advantage of email is that the user of any standards-compliant email system can send email to another user regardless of which standards-compliant email system they use. We had the opportunity to make chat apps also work that way but there was too much commercial value in creating walled gardens and so now that dream is gone from us.
XMPP.
It's a federated service (similar to how email works, you have an account on a service that forwards messages to others). Your address is just like email:
Check out Snikket and Monal on iOS, Gajim for Windows, etc. There are multiple clients for each OS, generally.
You usually have to setup your account through a web page (not through the client).
I'd personally go with the two options you mentioned, but you could also look into XMPP. It's a messaging protocol built on top of TCP (not http like websocket) and is used by the likes of WhatsApp (and even FCM internally) etc. But again, depending on your use case it is probably overkill.
> OMEMO (runs over XMPP) has been audited
The audit you linked is already more than five years old. It covers OMEMO in its earliest days. After the audit, the XEP had several fundamental changes (e.g., switching from Axolotl to Olm to SignalProtocol, migrating to other cryptographic primitives), and is still experimental. So the audit is likely completely outdated. Plus, an audit of a specification doesn't mean that clients/servers implement the specification correctly.
> OMEMO is supported by a lot of XMPP clients: omemo.top
The omemo.top website is partially wrong. For instance, Psi (without the +) doesn't support OMEMO, and other clients support it partially only (e.g., they only support 1-to-1 chats, no MUCs).
It looks like the man-in-the-middle security flaw (https://xmpp.org/extensions/xep-0364.html#securityhttps://en.wikipedia.org/wiki/Off-the-Record\_Messaging#Authentication
"As of OTR 3.1, the protocol supports mutual authentication of users using a shared secret through the socialist millionaire protocol. This feature makes it possible for users to verify the identity of the remote party and avoid a man-in-the-middle attack without the inconvenience of manually comparing public key fingerprints through an outside channel."
Yes, OX is XEP-0373: OpenPGP for XMPP. Regarding OMEMO vs OX - while both of them facilitate e2e encryption they are not the same or that related. OMEMO relies on Signal protocol (with the idea to use MLS in the future).
I can recommend https://blog.jabberhead.tk/2018/09/07/future-of-omemo/ as a readup :-)
Keine Ahnung, aber Voice gehört ja auch nicht zum „Kern“ (vgl. XMPP Compliance Suites 2021) – und dieser Kern funktioniert wunderbar über alle vernünftigen Clients und Server hinweg.
Bei SMS ist es Text, bei E-Mail ist es Text+Anhänge, und bei XMPP ist es Text+Anhänge+Status.
Dass XMPP darüber hinaus mehr Features (wie Audiocalls) bieten kann, ist nett, aber da kann man ja natürlich nicht erwarten, dass alle Clients alle Features anbieten. Das ist ja das Elegante am Protokoll, dass beliebige Zusatzfeatures eingebaut werden können und deren Support den anderen Clients mitgeteilt werden kann, die dann entweder mitspielen oder höflich ablehnen.
Hi @SlaveZelda!
There's a specific XMPP extension to enable push notification support on servers implementations: https://xmpp.org/extensions/xep-0357.html
Unfortunately jackal doesn't yet support it, but other implementations such as Prosody and ejabberd offer support.
Hi @SlaveZelda!
There's a specific XMPP extension to enable push notification support on servers implementations: https://xmpp.org/extensions/xep-0357.html
Unfortunately jackal doesn't yet support it, but other implementations such as Prosody and ejabberd offer support.
I'd still like to know why Grindr charges for certain features of XMPP, an open source protocol, such as when someone reads your message, or the typing status, or the ability to retract messages, all of which are either built into or XEP extensions of XMPP
xmpp.org
Le jour où ton serveur Jabber ferme, tu dis simplement à ton client de pointer vers le nouveau compte de ton choix et… c'est tout. Tu gardes ton client, tes habitudes, tes contacts, l'ordre précieux de tes stickers et la vie continue. Pour tous les écosystèmes captifs bah… tu recommences de zéro, quoi.
Le chiffrement OMEMO (en gros la technologie de chiffrement de bout en bout de XMPP, qui se base sur la même techno que Signal, voir https://xmpp.org/extensions/xep-0384.html) actuel ne chiffre pas les métadonnées en effet.
La prochaine version intégrera ça (voir https://xmpp.org/extensions/xep-0420.html) et est déjà standardisée, il y a un travail préparatoire sur les clients pour supporter ça (c'est pas simple).
OMEMO est déjà intégré dans de nombreux clients XMPP https://omemo.top/ et ne nécessite pas de gros changements coté serveur (la plupart du temps il n'y a rien à faire).
Do you have a source on that?
14.2 End-to-End Encryption No end-to-end message or session encryption method is specified herein. Users SHOULD NOT trust a service to keep secret any text sent through a room. A future specification might define a method for end-to-end encryption of MUC traffic, but currently there is no such specification.
https://xmpp.org/extensions/xep-0045.html#security-e2e
The standard seems to explicitly not define E2EE, much less multiuser E2EE, which is incredibly complex.
Even the original Intercept article on this problem notes there are many challenges.
>Matthew Green, a cryptographer and computer science professor at Johns Hopkins University, points out that group video conferencing is difficult to encrypt end to end. That’s because the service provider needs to detect who is talking to act like a switchboard, which allows it to only send a high-resolution videostream from the person who is talking at the moment, or who a user selects to the rest of the group, and to send low-resolution videostreams of other participants. This type of optimization is much easier if the service provider can see everything because it’s unencrypted.
>an email 2.0 system would need to be created
Have you heard of the XMPP? It's electronic, it's a messaging service, and it's designed from its very inception to be extensible allowing people to add in all kinds of nifty features that weren't there at the beginning.
XMPP withstands heavy loads and has support for video calls. XMPP has become the base platform for famous applications such as Zoom and WhatsApp https://xmpp.org/uses/instant-messaging.html
You might want to look at OpenPGP over XMPP for a pre-existing example. There are several open source OpenPGP supporting XMPP clients to look at. The standard is here:
Vanilla OpenPGP does not provide forward secrecy. You might not care as forward secrecy in messaging tends to be not that useful in practice. I will just include a link to my PGP advocacy article on that subject as it covers the relevant issues:
Matrix has done pretty good publicity I suppose.XMPP is actually quite easy to host yourself.Whilst being less resource hungry than Mattix, they have even added voice and video capabilities. The text-only argument about XMPP hasn't been true for years now.
See XMPP Upload and A/V Calls
This is going to sound dumb, but I've been really turned off of matrix by the community. There are a lot of Matrix evangelizers that shout down criticism and swarm the upvote/downvote mechanisms.
I have had a lot of issues with the reliability of notifications with matrix apps like Riot, and when I asked about it I got shouted down and called a troll.
Their attacks on XMPP led to this charming webpage needing to exist.
That said, matrix is great. I have the Riot.im app installed on my phone (I hear they are in the process of rebranding.) I use the app to follow a couple of Linux communities.
Anyway, matrix is great and I think the simplicity of the protocol means it has a bright future ahead of it. I think XMPP is a bit more mature but the technology suffers from a coordination problem where they can't get everyone to use the same set of extensions.
I think both will survive long-term, and as a community we should support both.
There is XEP 0289 but it would need some more work for handling of case where one node is going offline etc and it would also need server implementations...
Yes, OMEMO, OTR, and PGP all work in the clients, OMEMO being the usually recommended one. (It's essentially the same protocol as Signal's, i.e. the "Double Ratchet"). That compliance view is a good one. In fact Conversations is a good client for most people on Android. But there are many clients for all sorts of Operating systems: https://xmpp.org/software/clients.html
>WebRTC
As you said this is a browser technology. This is an extra layer, unavailable in node. Even specialize libraries like peer.js says it clearly https://peerjs.com/
Now, you might be able to implement that headless, using electron or maybe pupeeter, but this will all a shit load of stuffs 100mo, to just send some messages.
If you want to make all yourself, which is always good (!!), I think using electron is not the good way!
You are looking to make a cli text chat app, stick to the regular model server/client, even rest or websocket.
You are looking to implement a video/audio app, stick to the same model, client/server, a RDP flux, using FFMPEG, or why not vlc, XMPP, jabber...
Notice something, security! Our shell is not a place where we want remote stuffs to get executed, you have to trust the remote, implement filtering, and you will disclose your IP and port using webrtc. Not good. This is why a server/client model is safer, since only the server will be aware of those IPs.
From my view, websockets are the way to go.
You have pretty much all options at hand for E2E encryption:
- OMEMO if you want perfect forward secrecy, history syncing across multiple devices, group chats support. It's pretty much a default these days and the only one that matters in practice
- OpenPGP/OX if you don't want forward secrecy (because you want your history resynced on new devices)
- OTR if you have a single device which you want to use for encrypted chats across a transport/gateway/bridge (e.g. with someone on IRC), bad UX in practice and most clients dropping support as a consequence
> Can't appear offline on Jabber lol
That thing is called XMPP (SCNR) and that information is not true and hasn't been for a long time.
>i googled what it was I found out that it is an anonymous chat for a dark web server
I have no idea how you came to this conclusion. Settle down, and read this. I had no idea what this was, but it's all very simple to understand. XMPP is a messaging protocol utilised by numerous software vendors, including WhatsApp and Zoom. It also appears that it powers Apple's push notifications. The project originally went by the name Jabber.
This should raise no alarm bells unless it's being invoked by unknown software.
Mi riferivo al protocollo XMPP https://xmpp.org/about/technology-overview.html Storico protocollo di chat decentralizzato.
In alternativa si potrebbero usare sistemi completamente serverless tipo torrent
Like I said, if you already know how to send packets from an Android app, just determine what features you need, then implement the specification as described in XEP and RFC.
XMPP really isn't a complicated protocol. It's basically just sending and recieving xml stanzas, and handling the responses.
If you don't understand what this means, you probably don't really know the basics of xmpp. I would suggest learning how it works before trying to build an xmpp client from scratch.
I first learned how XMPP works with this book but it's more of a textbook than a step-by-step you can blindly follow. It's based on web development with the StropheJS library, not mobile development, but has a ton of great information. The source code for each chapter is on github, but some of it is out of date (flashxhr). But if you truly understand it, you'll know what needs to be fixed.
Pidgin by itself won't really do anything. It's the software that you use to connect to a chat server, and that's where your contacts would be stored. So anyway, if you just install Pidgin and stop there, no one will be able to locate you, because you won't be signed into anything where other people are also signed in.
You might be able to still use Pidgin to sign into some old networks. AIM is gone now so not that one. Like you said Google Talk has moved to Hangouts (GTalk used to be XMPP). I'm not sure if you can still use Pidgin to connect with GTalk/Hangouts in some way at all -- for a long time there was a deprecated but still-working way to do that (last verified years ago, no idea of current status).
You could look into XMPP. Pidgin connects to XMPP servers just fine. There are numerous servers around the world; you can run your own or join one that someone else runs. A cool thing about XMPP is that you can chat with and have contacts with people on OTHER XMPP servers, kind of like email but real-time. You can have private conversations or join group chat rooms. For tracking down people you already know and chatting with them over XMPP, I'm not sure how you'd do that other than connecting with them first some other way and exchanging addresses ().
Good luck!
>XMPP is no where near the same as signal though and has it's own problems.
As i said in the beginning XMPP with Plugins. And i mean the OMEMO Plugin witch implements the double Ratchet from the Signal Protocol
https://xmpp.org/extensions/xep-0384.html
I think if you use this on your own server or the server from people you Trust you have a better privacy than Signal.
>I mean.. wtf
Yeah Matrix is indeed a clusterfuck but in my context i can understand the argument of unencrypted rooms.
In example i use Matrix for the local hackerspace. There are over 100 people lurking in this room we talk about upcoming events, project, news and stuff like that. The room is open and we encourage everyone to come into the room. So if evil wants to read the messages he could just join the room. Why encrypt it?
But there are some rooms that are closed and encrypted. But this actually sucks because of the high usage of browsers and key management and so on.
Correlating IP and MAC addresses (without additional controls at the switch level) provides no security benefit. Both are not static and will change as a privacy feature, if not maliciously.
It is also non trivial to implement. Remotely there isn't really a way of knowing all IPs and layer 2 addresses of a host. On the host, there isn't a portable function to make this association, so you are mucking around in OS specific interface details. Temporary addresses mean this can't be a static list, many clients will come from a new IP every few hours. Bonded interfaces may have different layer 2 addresses for the same IP in some configurations. Technically, on a LAN there could be interfaces that have a link local but no associated global scope address, what to do with them?
​
Instead, consider getting inspired by or hacking on an existing chat protocol with security at the application level. Especially for anything serious to put into production. For example, an XMPP server, with proper TLS and auth. Or go serverless on a local network with XEP-0174, aka the Bonjour support in Pidgin. With a TLS session, merely spoofing the IP address without knowing the private key is not going to work.
There has been some protocol work going into this (see link below), but the general consensus was that in a federated system that's open for third party clients (the essence of XMPP) doing ephemeral messages doesn't really make sense since you cannot force the receiver to reliably delete the message as requested.
What you probably need is writing an XMPP Component and connect to a server that implement the rest of XMPP (included the federation part), the protocol is defined in XEP-0114:
https://xmpp.org/extensions/xep-0114.html
And you can find an example here (sorry, it's in Python because I found no free .Net library implementing the component protocol):
https://slixmpp.readthedocs.io/getting_started/component.html
XMPP was and still is an excellent messaging protocol. For many years, dating back to the early Jabber years, I was a strong advocate and used XMPP messaging on a daily basis.
The big challenge has been the decline over the past years in the availability of (and updates to) independent XMPP *clients*. There *are* many clients listed at https://xmpp.org/software/clients.html but when I last looked (a year or so ago) a good number had not been updated in a while.
Meanwhile user expectations are increasing because people are used to using modern messaging clients (ex. Slack, WhatsApp, Facebook Messenger, iMessage, Signal, Wire, Threema, Line, WeChat, etc) and they EXPECT that many similar things can be done in any messaging service they use.
It's hard for independent clients to keep up with those expectations. The business model isn't necessarily there that will keep up. There are proprietary clients (ex. Cisco) that use XMPP within their systems, but those clients are not usually available to work with standalone XMPP servers.
So you are aware that they spy on you and misuse your bandwidth to advertise things to you, and you still think there might be something good in all this?
If you only use it for your wife it's easy, tell her to switch to something else.
Ideally you would use an open source protocol and client, such as XMPP. Since everything is open, no single company has control over it. Even better, the client can't do anything behind your back, because the source code is open. If you don't like a client or server, you can change to another one and still keep your contacts.
Of course, you can't ask all your friends to switch to something else, but this is what I did for my family and close friends, and they are all happy with it. Give it a try!
are you looking for ACTUAL SMS messaging? or just something similar to Instant Messages with access via web and cell phone? If it's more the latter I would look at XMPP. It's a open source messaging protocol. You can selfhost a server and then have a self hosted web client where people can sign in and send messages or install a app on their phones and connect to the server.
That depends on the way you choose to transfer the data. XEP-0234 negotiates the file size to your contact, in the xep there are different conditions mentioned which would lead your contact to about the transfer. Thus the transfer amount 8s possible to be limited by your contacts storage and connection. With XEP-0363 the upload size is limited by the configured maximum filesize of the server.
Most providers state the maximum upload size on thier website. Alternatively there are multiple sites collecting such data points for great amounts of public servers. Those sources could be inaccurate though.
If XMPP doesn't do what you want, you need only install a plugin!
If you use Prosody, then here is where you want to head.
If you're concerned about clients, then you probably want this page.
Don't forget the online tester, that tests your server's security.
XMPP is alive and well :-)
https://xmpp.org/software/libraries.html
Can't be that hard to implement a library, can it? There are probably reasons why it didn't happen.
Imagine a full featured ingame xmpp client with embedded videos/images, accessible from outside via multiple clients at the same time, notifications for whatever device, millions of available chatbots and tools, channel services..
Implementint a client-side XEP usually consist of the following steps:
- read and understand the XEP
- (in case of a complex XEP) identify the important parts that you want to implement
- start implementing them
- test them against other implementations as you go
That may sound not very helpful, but every XEP is different, so there is no definitive answer for this.
I'd start by implementing a XEP which is merely about information transfer. XEP-0107: Mood is a classic, which is quite simple to implrment.
Basically you have to read up, how libstrophe does implement extension elements and hoe you listen for them.
I can recommend the book "The definitive Guide to XMPP", which helped me a lot to start with XMPP :)
Ejabberds documentation documents mix 0.1.0 the xep revision history on the other hand lists the latest revision 0.14.1 from the 5 January 2019.
I would recommend asking in the xsf muc about the current mix state.
Source: https://xmpp.org/extensions/xep-0369.html https://docs.ejabberd.im/tutorials/mix-010
> but this is the future because json?
JSON-over-WebSockets / JSON from a developers perspective is developers wet dream compared to XML and writing custom services on Matrix is a breath of fresh air. XMPP is too complex, but the XML stuff is really the smallest issue, compared with other complexities in the protocol. For example, an issue is understanding which "devices" (#xxxx) of the same Jabber ID will receive a message targeted at that ID. And there are more such surprises in XMPP. The protocol complexities often seem to put forth "how do we represent this in XML?"
Furthermore, the MUC specification is utterly incomprehensible because the terms it uses for things are so wildly different from how they are used everywhere else, that laying out a strategy is really hard. I've seen this issue in other XEPs as well.
XMPP does not require servers to work, so you may want to reconsider it. If you've got a way for the clients to discover each other in the network, you may make XMPP work for you.
I am kind of a XMPP fan though ;) But I think it's a mature protocol, with multitude of clients and features.
I rather convert people to https://xmpp.org which is 20 years old, federated (you can even self host if you want, but don't have to), end to end encrypted and well established protocol.
It has clients for all possible platforms and since someone asked this before, yes every client can talk with other clients.
Did you know that Google Talk was based on it? Most people used xmpp through that, so when Google killed Gtalk, it basically killed xmpp adoption for a while, but the protocol is doing very well and has shitloads of features, including out of the box strong encryption (OMEMO).
The documentation about that is a bit sparse, Kontalk currently uses a customized version of OpenPGP (as of XEP-0027) to overcome some the XEP security issues. Plans for switching to XEP-0374 are obsolete though, because we are planning to switch to OMEMO and since we don't have resources to do both, we are prioritizing OMEMO :)
Disclaimer: I'm the project leader
If you're going through all that trouble, why not figure out XMPP?
- XMPP is the open standard for messaging and presence
- XMPP powers emerging technologies like IoT, WebRTC, and social.
- No one owns XMPP. It's free and open for everyone since 1999.
- It's a living standard. Engineers actively extend and improve it.
- Millions use XMPP software daily to connect to people and services.
There are multiple apps to use: https://play.google.com/store/apps/collection/search_results_cluster_apps?clp=ggEGCgRYTVBQ:S:ANO1ljLfP30
Multiple self-hosted servers: https://xmpp.org/software/servers.html
Multiple public servers: https://list.jabber.at/
We tried this exact library but it didn't supported async IO and for us it was a deal breaker.
The number of commits in a repository do not represent the size of any software. Our library was functional after few weeks of implementation and since then we are improving the communication, transport, performance and related stuff. We rarelly add a new protocol feature. You can check the specification updates here: https://github.com/takenet/lime
If you want to compare the complexity, just look at the XMPP core specification and compare with the one that I provided in my previous comment: https://datatracker.ietf.org/doc/rfc6121/?include_text=1
But you know, XMPP pratically is unusable without its extensions (XEPs). And there are so many XEPs (https://xmpp.org/extensions/) that you have almost a new protocol depending of the active XEPs in a server. Our protocol just defines the frame format using JSON (which is a lot easier to work compared with XML) and the basic client / server behavior, which was what we needed.
If I understand you correctly, then I know not of any self-hosted service that would allow you to bypass your carrier and message others who are using their vanilla sms programs.
If you have a small group of friends you chat with, or if you are bored, then I would recommend setting up an xmpp server with prosody on a vps. Currently I am doing this as an alternative to using kik, telegram, whatsapp, etc. You can find many tutorials online.
For android phones, I would recommend using conversations (free on F-droid) or Xabber. Conversations provides a very slick and minimal interface, making it a suitable choice if you are trying to get stubborn people to switch over from something else. Xabber is also very nice, but less accessible to newcomers. I'm not sure about Xabber, but conversations also supports some important xmpp plugins for mobile usage.
Tor messenger is based on XMPP alias Jabber (The stuff WhatsApp basically stole from and closed the source afterwards).
XMPP/Jabber has some weaknesses but the good thing it's open source, there exist OTR and Tor's solution even fixes the known OTR problems.
There coming some neat features (cause it's still beta) but the normal chat is already good to go, the upper layer of their chat uses Instandbird, so you can (same like Thunderbird/Firefox) configure and tweak almost all settings via about:config.
However, trying to implement an XMPP server/client from scratch would take ages...
Look at this example XEP: https://xmpp.org/extensions/xep-0045.html
Just reading and implementing that properly could take a full year if you want to do it right.
There are a lot of libraries that have already implemented these things, I'm sure. But plugging in all these libraries and then trying to understand them all would take just as much cognitive effort, don't you think?
Here - https://ulloo.net/ the latest version of jabber server. It supports most XEP. But in order to accurately answer your question, write a list of your XEP used in standard: XEP-0000 where 0000 XEP code. For a complete list of all existing XEP can be found here: https://xmpp.org/extensions
You don't need to resort to metaphors, I'm a computer scientist and I've written IRC bots and XMPP code. I also remember when extended SMS and MMS were things only some people had.
XMPP was designed to be extended without breaking things, that's why it's based on XML. There are a whole series of XMPP extensions which amount to adding some elements to a message which one person's software can do things with without breaking other people's software -- just like the SMS extensions were designed to add functionality without breaking other people's software.
For a long time Facebook, Apple and Google had chat implementations which were entirely valid XMPP, just with different sets of extensions. For example, XEP-0319 worked on Google, but not on Facebook -- so people on Facebook would show up as always present. Mostly a cosmetic issue, like the issue of extended length SMS message being arbitrarily chopped into pieces when shown to a recipient without extended SMS support.
With MMS, they built the system so that people without MMS would receive a URL via SMS which they could launch with a WAP browser to view the content. Which was a horrible hack, but technically didn't break the experience for SMS users.
Well, there are plenty to choose from.
I personally use Gajim on daily-use PC. It supports everything that I need, that is:
message carbons (all messages are sent to every client logged in with your credentials)
MAM - server stores some(or all) of your previous messages on server, so when you change clients (and only one is logged in at a time), you can see all your previous conversations
many, many other nice XEP's
it has a nice, well-working OTR plugin
As mobile clients are concerned, I mainy use Conversations due to the same reason I use Gajim. It supports XEPs I want.
As far as I know, at this time this is the only open-source Android XMPP client that supports MAM.
Xabber is nice too, recently they have added carbons support, but you would need to download this F-Droid version, not the one from Google Play.
Oh, and there also is Profanity for console.
If you would like to learn more about XMPP and XEPs, this is the best place to look.
Hey Matt,
You wrote XEP-0142 - Workgroup Queues. My company loves this, but the only place I've seen anything like it implemented is in the FastPath plugin for OpenFire.
Are there any plans to implement something similar in Chime? We love being able to talk to someone, anyone, from a particular team or department. And I can't find that functionality anywhere else.
> Can XMPP talk to Gmail or Facebook contacts?
I think Facebook are deprecating their XMPP APIs. I think it will still work with gchat: https://xmpp.org/2015/03/no-its-not-the-end-of-xmpp-for-google-talk/
> What options folks have who don't own a XMPP server how do they talk to you?
They can get a free jabber account (just google search for that), or they can get an account on your server. All Jabber servers are interoperable. You don't have to be on the same jabber server / network to communicate with other jabber/xmpp users.
> What do XMPP username look like?
typically just , but sometimes .
> What info do you have to give other folks if they want to talk to you over XMPP?
Just give them your user name. They can add you / you can add them. If you add them to your account, they'll get a message saying, "this person has added you to their jabber account list. do you want to accept their acct?"