Does XMPP suck?
I have to admit that I decided to write this article very spontaneously, having read the article “XMPP sucks” and felt some closeness to the author’s feelings, as I also use XMPR in one of our products. Nevertheless, clenching my emotions into a fist, I nevertheless decided to simply state why I have mixed feelings about this protocol and spread out the pros and cons. Also tell you what we have chosen for the server and client. That's all for you, dear reader, to make the right choice and pull out less hair in your future projects.
I work at Thirdlane , where we make products for VoIP and unified communications. At one time, we chose a protocol for communication in one of our products. At the moment of choosing a protocol, the question was simply: whether to write the protocol yourself, or use HMRD. We did not consider other protocols. After not long discussions, we chose HMRD, relying on the fact that it is a standard open protocol with extensive use, documentation, various implementations and extensions that on the surface seemed to meet 100% of our requirements. Now, after quite a long time robots with HMRR, I can say that I am not sure that we have made the right choice. However, I do not know what my feelings would be if we went the other way. Of course, sitting in the evenings having a cup of tea, I sometimes dream of returning at that time and writing my own private protocol with blackjack and node.js, but alas. Immediately remember the words of Socrates:
“If you marry, or don't marry, you will regret it anyway.”
At the moment of selection, the main advantages of the protocol seemed to us as follows:
')
Using XML as a format for data, we considered a drawback, but not critical, because we found the stanza.io library which makes it easy to convert XML into an easy-to-use JSON.
Since our product is focused on a web browser, we only have JS in our hands, we love it, it's cool, stylish, and finally. If you look at the JS-libraries for working with XMPP, then we will see several handicrafts such as strophe, xmpp-ftw, JSJaC. None of them appealed to me, unlike the aforementioned stanza.io , which I personally fell in love with at first sight. The library is very well thought out and very cleanly written, supports all vital XEPs, it is easy and pleasant to work with it. Its only drawback is weak documentation, which often required reading the source code. But it was also useful.
Here, we also didn’t take long to make a choice, since at that moment there was no Stream Management or Web Socket transport in Openfire. Ejabberd also dropped immediately, due to Erlang. In addition, both products, being Open Source, tend to commercialize, which is not good. Ultimately, we chose Prosody. Smart, lightweight, written in a beautiful language Lua, responsive community, the project is not dead, each XEP is a separate module that is easy to connect / disconnect, the ability to easily write your own modules, well, in general, it is nice.
Protocol:
Here I will list only what seems to me important, and which I personally encountered.
XEP-0115: Entity Capabilities
This, of course, a big plus. This thing allows us to find out which of the XEPs are implemented in the client of our interlocutor, whether to send him chat state notifications or not, well, or something else there.
XEP-0280: Message Carbons
This is also a great credit, it allows you to synchronize messages with all your devices, that is, if you are logged on to a laptop, mobile and desktop, then this will allow you to keep the correspondence in sync.
XEP-0308: Last Message Correction
This is just very convenient, fix ochepyatku in a message that has already been sent. This is great, everyone uses it, everything is easier now, the harmarnats are calm.
XEP-0184: Message Delivery Receipts
This is just a song. Together with stream management, it lets the user know that the message was sent and that the server received it, and lets you know that the message was delivered to the addressee. Very useful, but, unfortunately, this information does not fall into the history of correspondence - "XEP-0313: Message Archive Management".
XEP-0313: Message Archive Management
This is sad ... This XEP is used to store history and its receipt. First of all, you will never know whether any message was delivered if the client was closed. Secondly, getting a story is an indication of what date you want and what is the limit. As for me, paging would be more appropriate here. Also, you can not organize a search for messages on the text on the server, which is also sad. But in the presence of hands, this, of course, is solved with all sorts of crutches. Here I fully agree with the author of the above article. It is not clear how in the protocol this was missed.
XEP-0045: Multi-User Chat
This is the worst thing that happened with HMRR. It is sadness and longing, pain and suffering, despondency and despair. I will say this: the number of Satan is not 666, it is 0045. First of all, these are not group chats, this is an imitation of IRC. Everything. At this one could finish about 0045, but let's still figure out who is to blame and what to do? Do you know how to enter the room? Send a request to enter the room. Do you know how to create a room? Send a request to enter the room. If it does not exist, it will be created. The uniqueness of the server room name decides who wants it. Like? Wellcome to hell. The person who created the room (well, or who has the right) sets the number of recent messages that will be sent to the client who enters the room. Just entered, and you N messages from the group flew straight into the face. The worst thing is that 0045 does not provide for the storage of offline participants. A user is considered to have left the room as soon as he closes his client. In order to return later to this room, you need to either remember her name, or use "XEP-0048: Bookmarks". Imagine the situation now: you were invited to a group chat, you entered, talked and added this room to your bookmarks, and also indicated that you would enter this room automatically every time you log in. Do you know what happens if this room was removed while you were offline? When logging in, you will read the bookmarks and make “the entrance to the room”, and as we know that the creation is no different from the connection, it is correct! You will create a new room. Still? I will have for you. If the room is not specified as “persistent”, it will be deleted as soon as the last user closes the client or exits it. These are the cases, who is to blame - it is clear, now the question is: what to do?
We solved this problem as follows: all rooms are created and configured as “member-only” and persistent. In our client, we draw in the list of participants all those who have the right to enter the room. As it turned out, Prosody prohibits getting such a list to all participants by default, although XEP says the opposite. We discussed this with the developers of Prosody, I hope that they will agree and correct it. In the meantime, we have our own change in the Prosody code. We also had to make a change so that the user could exclude himself from this list (yes, by default, it is also impossible), which means his exit from the room. They also wrote a custom module for Prosody, which monitors the change of the list of room users (room affiliation) and informs all participants of this. In such an uncomplicated way, we have made conferences "almost like in Skype." Interestingly, the XMPP community is now discussing a similar implementation of the MUC only using Pub / Sub, which was confirmed to me by one of the participants in the working group.
XEP-0085: Chat State Notifications
A useful thing, it's always good to know whether a user is typing or not, just a nice HER.
XEP-0198: Stream Management
It's just from the category of Mast-Hev. For each of your bunch in the direction of the server, he will respond that he received it, so you know exactly what the message was sent for example. It also allows you to use the protocol when the connection to the network is not stable, for example, if you are sitting on the phone and you sometimes lose the connection. This will allow you to resume the connection, rather than re-login.
After all, I still find it difficult to explain why my feelings remained negative. After all, we have ensured that everything worked beautifully. Perhaps due to the fact that we expected that we would use a protocol in which there is everything and there would be no need to waste time on solving obvious problems. But “having been involved in a fight”, we came across a pile of pitfalls and not thoughtful realizations. In the end, all the problems were solved, but as in that joke "the spoon was found, but the sediment remained." Also, probably, because we spent a lot of time studying specifications, reading someone else's source code and putting in order HEPs that we didn’t fit, moreover, so that they remain backward compatible with native clients - that all together , there is a very not grateful occupation. But, as I said, we have achieved the desired result. I think it’s up to you to decide whether you’re ready to study complex specifications, dig into the bugs of their implementations in clients and servers. If you make a great service, and even with integrations, then writing your own extensions is guaranteed. Look at the same HipChat, he has a bunch of custom stanzas. These are at least described in the documentation, and nobody knows what is under the hood of Lync or Jabber. On the other hand, if you need basic functionality, then HMRP is exactly what you need. A huge amount of everything out of the box, works 99% of cases.
I work at Thirdlane , where we make products for VoIP and unified communications. At one time, we chose a protocol for communication in one of our products. At the moment of choosing a protocol, the question was simply: whether to write the protocol yourself, or use HMRD. We did not consider other protocols. After not long discussions, we chose HMRD, relying on the fact that it is a standard open protocol with extensive use, documentation, various implementations and extensions that on the surface seemed to meet 100% of our requirements. Now, after quite a long time robots with HMRR, I can say that I am not sure that we have made the right choice. However, I do not know what my feelings would be if we went the other way. Of course, sitting in the evenings having a cup of tea, I sometimes dream of returning at that time and writing my own private protocol with blackjack and node.js, but alas. Immediately remember the words of Socrates:
“If you marry, or don't marry, you will regret it anyway.”
At the moment of selection, the main advantages of the protocol seemed to us as follows:
')
- This is an open protocol;
- There is a huge number of servers and clients for it;
- The ability to integrate the final product with the outside world;
- It is used in cool products: MS Lync, Cisco Jabber, Atlassian HipChat, etc ..;
- A huge number of extensions in the form of XEPs;
- Ability to extend the protocol.
Using XML as a format for data, we considered a drawback, but not critical, because we found the stanza.io library which makes it easy to convert XML into an easy-to-use JSON.
Client side
Since our product is focused on a web browser, we only have JS in our hands, we love it, it's cool, stylish, and finally. If you look at the JS-libraries for working with XMPP, then we will see several handicrafts such as strophe, xmpp-ftw, JSJaC. None of them appealed to me, unlike the aforementioned stanza.io , which I personally fell in love with at first sight. The library is very well thought out and very cleanly written, supports all vital XEPs, it is easy and pleasant to work with it. Its only drawback is weak documentation, which often required reading the source code. But it was also useful.
Server side
Here, we also didn’t take long to make a choice, since at that moment there was no Stream Management or Web Socket transport in Openfire. Ejabberd also dropped immediately, due to Erlang. In addition, both products, being Open Source, tend to commercialize, which is not good. Ultimately, we chose Prosody. Smart, lightweight, written in a beautiful language Lua, responsive community, the project is not dead, each XEP is a separate module that is easy to connect / disconnect, the ability to easily write your own modules, well, in general, it is nice.
Protocol:
Here I will list only what seems to me important, and which I personally encountered.
XEP-0115: Entity Capabilities
This, of course, a big plus. This thing allows us to find out which of the XEPs are implemented in the client of our interlocutor, whether to send him chat state notifications or not, well, or something else there.
XEP-0280: Message Carbons
This is also a great credit, it allows you to synchronize messages with all your devices, that is, if you are logged on to a laptop, mobile and desktop, then this will allow you to keep the correspondence in sync.
XEP-0308: Last Message Correction
This is just very convenient, fix ochepyatku in a message that has already been sent. This is great, everyone uses it, everything is easier now, the harmarnats are calm.
XEP-0184: Message Delivery Receipts
This is just a song. Together with stream management, it lets the user know that the message was sent and that the server received it, and lets you know that the message was delivered to the addressee. Very useful, but, unfortunately, this information does not fall into the history of correspondence - "XEP-0313: Message Archive Management".
XEP-0313: Message Archive Management
This is sad ... This XEP is used to store history and its receipt. First of all, you will never know whether any message was delivered if the client was closed. Secondly, getting a story is an indication of what date you want and what is the limit. As for me, paging would be more appropriate here. Also, you can not organize a search for messages on the text on the server, which is also sad. But in the presence of hands, this, of course, is solved with all sorts of crutches. Here I fully agree with the author of the above article. It is not clear how in the protocol this was missed.
XEP-0045: Multi-User Chat
This is the worst thing that happened with HMRR. It is sadness and longing, pain and suffering, despondency and despair. I will say this: the number of Satan is not 666, it is 0045. First of all, these are not group chats, this is an imitation of IRC. Everything. At this one could finish about 0045, but let's still figure out who is to blame and what to do? Do you know how to enter the room? Send a request to enter the room. Do you know how to create a room? Send a request to enter the room. If it does not exist, it will be created. The uniqueness of the server room name decides who wants it. Like? Wellcome to hell. The person who created the room (well, or who has the right) sets the number of recent messages that will be sent to the client who enters the room. Just entered, and you N messages from the group flew straight into the face. The worst thing is that 0045 does not provide for the storage of offline participants. A user is considered to have left the room as soon as he closes his client. In order to return later to this room, you need to either remember her name, or use "XEP-0048: Bookmarks". Imagine the situation now: you were invited to a group chat, you entered, talked and added this room to your bookmarks, and also indicated that you would enter this room automatically every time you log in. Do you know what happens if this room was removed while you were offline? When logging in, you will read the bookmarks and make “the entrance to the room”, and as we know that the creation is no different from the connection, it is correct! You will create a new room. Still? I will have for you. If the room is not specified as “persistent”, it will be deleted as soon as the last user closes the client or exits it. These are the cases, who is to blame - it is clear, now the question is: what to do?
We solved this problem as follows: all rooms are created and configured as “member-only” and persistent. In our client, we draw in the list of participants all those who have the right to enter the room. As it turned out, Prosody prohibits getting such a list to all participants by default, although XEP says the opposite. We discussed this with the developers of Prosody, I hope that they will agree and correct it. In the meantime, we have our own change in the Prosody code. We also had to make a change so that the user could exclude himself from this list (yes, by default, it is also impossible), which means his exit from the room. They also wrote a custom module for Prosody, which monitors the change of the list of room users (room affiliation) and informs all participants of this. In such an uncomplicated way, we have made conferences "almost like in Skype." Interestingly, the XMPP community is now discussing a similar implementation of the MUC only using Pub / Sub, which was confirmed to me by one of the participants in the working group.
XEP-0085: Chat State Notifications
A useful thing, it's always good to know whether a user is typing or not, just a nice HER.
XEP-0198: Stream Management
It's just from the category of Mast-Hev. For each of your bunch in the direction of the server, he will respond that he received it, so you know exactly what the message was sent for example. It also allows you to use the protocol when the connection to the network is not stable, for example, if you are sitting on the phone and you sometimes lose the connection. This will allow you to resume the connection, rather than re-login.
Conclusion
After all, I still find it difficult to explain why my feelings remained negative. After all, we have ensured that everything worked beautifully. Perhaps due to the fact that we expected that we would use a protocol in which there is everything and there would be no need to waste time on solving obvious problems. But “having been involved in a fight”, we came across a pile of pitfalls and not thoughtful realizations. In the end, all the problems were solved, but as in that joke "the spoon was found, but the sediment remained." Also, probably, because we spent a lot of time studying specifications, reading someone else's source code and putting in order HEPs that we didn’t fit, moreover, so that they remain backward compatible with native clients - that all together , there is a very not grateful occupation. But, as I said, we have achieved the desired result. I think it’s up to you to decide whether you’re ready to study complex specifications, dig into the bugs of their implementations in clients and servers. If you make a great service, and even with integrations, then writing your own extensions is guaranteed. Look at the same HipChat, he has a bunch of custom stanzas. These are at least described in the documentation, and nobody knows what is under the hood of Lync or Jabber. On the other hand, if you need basic functionality, then HMRP is exactly what you need. A huge amount of everything out of the box, works 99% of cases.
Source: https://habr.com/ru/post/261517/
All Articles