6 ms·

In the last year I had to re-implement one of the libraries for working with XMPP on another platform. It's horrible and not pleasant to work with at all. I gu

In the last year I had to re-implement one of the libraries for working with XMPP on another platform. It's horrible and not pleasant to work with at all. I guess most of the developers that worked with it had a bad time. That would be my bet why it hasn't taken of. IMO we need something simpler, websocket and JSON based. Less standards, less use-cases - for example I don't think xmpp should take care of vcards, nickname and tons of other things I forgot about. Programmer should be able to grok it realtively quickly and then specifics of your application should take longer to understand instead of having to spend ages on XMPP first and then ages on your specific hacks around it.

mariorossi666 7y ago
> for working with XMPP on another platform out of curiosity: what platform? I think I've never seen a platform where XMPP is not supported, even AtheOS, BeOS, GNU/Hurd, PalmOS and QNX have libraries for it. > IMO we need something simpler, websocket and JSON based nothing is stopping you to build a layer of compatibility
- ponyous 7y ago
  > what platform? React Native - iOS JavaScript runtime + Android JSC runtime. > nothing is stopping you to build a layer of compatibility I don't have 10 engineers. It's already super complex. Adding extra layer will just make things worse. I reckon custom solution would be simpler for majority of use cases.
  - mariorossi666 7y ago
    > React Native - iOS JavaScript runtime + Android JSC runtime. there are Java, Javascript and Swift libraries for XMPP > I don't have 10 engineers. It's already super complex The point is XMPP is a solved problem, you can simply use what you need of it, making it json over websocket won't make it anyway easier, you would use a library anyway Creating protocols just for the sake of it, it's the reason why this comic exists https://xkcd.com/927/ https://xkcd.com/927/ p.s.: Movim, afaik, solves that problem for you When you use Movim, it acts as an intermediary between the user's browser and an XMPP server. All the data that is sent and received by these two parties are managed by the Movim core, some of them are also saved in a database (for cache purposes). From the browser perspective, all communication with Movim is done using WebSockets (except for the "default" page loading). These sockets are proxied through your web-server to the Movim daemon. On the XMPP side Movim connects using pure TCP connections (like any XMPP client).
    - ponyous 7y ago
      Link me a JavaScript library that works cross platform on both iOS and Android with unified interface in React Native. Ideally it's maintained and if you are asking me why I wrote it, it's also because there was nothing available 2 years ago. Majority of JS XMPP libraries depend on the DOM for xml parsing - see strophe.js for example. This won't work in all JSC runtimes. > The point is XMPP is a solved problem Ye, which problem exactly? All of them are solved partially. Let me give you example, imagine you have a platform where users can chat in chatrooms (as simple as it gets really). On your platform you have a username and you are supposed to communicate with others with your username. You'd think xmpp is perfect! Nope, you'll have to fork the xmpp server for this use case. Why? Well, because XMPP standard supports nickname changing, which means in a context of a platform it would allow nickname spoofing. So you need to modify and add some security rules on top of it. "Solved problem" of course...
      - jcbrand 7y ago
        because XMPP standard supports nickname changing, which means in a context of a platform it would allow nickname spoofing Nicknames can be registered against a MUC so that other users can't use them. See here: https://xmpp.org/extensions/xep-0045.html#register https://xmpp.org/extensions/xep-0045.html#register This has been part of the MUC standard for years and there are XMPP servers which support this, so you don't need to fork. If you want to support nickname changing and still know whether it's the same user, you can use the newer XEP-0421: https://xmpp.org/extensions/xep-0421.html https://xmpp.org/extensions/xep-0421.html
      - jcbrand 7y ago
        Link me a JavaScript library that works cross platform on both iOS and Android with unified interface in React Native. https://github.com/xmppjs/xmpp.js https://github.com/xmppjs/xmpp.js
      - mariorossi666 7y ago
        as other have already said, Xmpp.js works quite well If it's Javascript it's already cross platform > Ye, which problem exactly? communicating via XMPP in a standardized way > All of them are solved partially And a new protocol based on half backed technologies would change that, how exactly? > On your platform you have a username and you are supposed to communicate with others with your username. On any forum or BBS I've been part of in my life, I've always used a nick, that changed over time. > Well, because XMPP standard supports nickname changing, which means in a context of a platform it would allow nickname spoofing. That's a feature, not a bug. In 1995 I could change my nick on IRC, in 1997 I could change my nick on ICQ, I still can change nick on Skype today (my artists friends do it on facebook all the times) Anyway, nick spoofing on XMPP is hardly a problem and it's not an XMPP fault. Have you ever tried to search for "someone has been impersonating me with FB messenger" on a search engine? > "Solved problem" of course. XMPP it's a solved problem, your chat where nick cannot be changed is your problem. Every implementation of standard protocols requires work, HTTP is a solved problem, but edge cases still exist. Name one standard federated protocol that could help you with that and make it simpler, please. Because I don't know any.
Leace 7y ago
> IMO we need something simpler, websocket and JSON based. Why JSON? JSON is the packaging format of this decade but remember when XMPP was conceived XML was the packaging format of that decade. Maybe CBOR would be more appropriate. No need to encode binary data (signatures, encryption) in base64 wrappers and more efficient encoding of frequently used stuff (no need for Whatsapp-stype FunXMPP).
- ponyous 7y ago
  For the sake of simplicity. Because JSON is native to web. And web is the biggest platform you have imo. It's annoying that you have to bring in XML parsing libraries if you want to implement XMPP in javascript environment.
  - shantly 7y ago
    > web > annoying that you have to bring in XML parsing libraries Uhhhhhh... https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_and_serializing_XML https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_a...
    - ponyous 7y ago
      Ok yeah, if you target web exclusively this will work. But if you target Android JSC runtime for example it won't, because you have no access to DOM. When I said web I should really say javascript. If you replace it my point still stands.
  - ktosobcy 7y ago
    > And web is the biggest platform you have imo. I thought we are in "mobile first" era already...
- xellisx 7y ago
  https://cbor.io/ https://cbor.io/
Flowdalic 7y ago
> Less standards, less use-cases - for example I don't think xmpp should take care of vcards, nickname and tons You mean you just want to use RFC 6120/6121? That's fine, just do it then.
z3t4 7y ago
This is my experience as well. Compared to for example IRC where you can just open a TCP socket and send ascii as it. I think a more simple protocol would lead to more integrations. It doesn't have to be as simple as IRC. One problem is that implementing audio/video p2p streaming is still super complicated. So we should probably only support text messaging as a first spec. And make separate and isolated audio/video spec!? A good start would be to take WebRTC as is and make a very simple protocol on top of it. And also make use of web push notifications. So the stack already exist and is fairly standardized. We just have to wrap it up in a very simple abstraction/protocol ontop.

mariorossi666 7y ago

> for working with XMPP on another platform out of curiosity: what platform? I think I've never seen a platform where XMPP is not supported, even AtheOS, BeOS, GNU/Hurd, PalmOS and QNX have libraries for it. > IMO we need something simpler, websocket and JSON based nothing is stopping you to build a layer of compatibility

ponyous 7y ago
> what platform? React Native - iOS JavaScript runtime + Android JSC runtime. > nothing is stopping you to build a layer of compatibility I don't have 10 engineers. It's already super complex. Adding extra layer will just make things worse. I reckon custom solution would be simpler for majority of use cases.
- mariorossi666 7y ago
  > React Native - iOS JavaScript runtime + Android JSC runtime. there are Java, Javascript and Swift libraries for XMPP > I don't have 10 engineers. It's already super complex The point is XMPP is a solved problem, you can simply use what you need of it, making it json over websocket won't make it anyway easier, you would use a library anyway Creating protocols just for the sake of it, it's the reason why this comic exists https://xkcd.com/927/ https://xkcd.com/927/ p.s.: Movim, afaik, solves that problem for you When you use Movim, it acts as an intermediary between the user's browser and an XMPP server. All the data that is sent and received by these two parties are managed by the Movim core, some of them are also saved in a database (for cache purposes). From the browser perspective, all communication with Movim is done using WebSockets (except for the "default" page loading). These sockets are proxied through your web-server to the Movim daemon. On the XMPP side Movim connects using pure TCP connections (like any XMPP client).
  - ponyous 7y ago
    Link me a JavaScript library that works cross platform on both iOS and Android with unified interface in React Native. Ideally it's maintained and if you are asking me why I wrote it, it's also because there was nothing available 2 years ago. Majority of JS XMPP libraries depend on the DOM for xml parsing - see strophe.js for example. This won't work in all JSC runtimes. > The point is XMPP is a solved problem Ye, which problem exactly? All of them are solved partially. Let me give you example, imagine you have a platform where users can chat in chatrooms (as simple as it gets really). On your platform you have a username and you are supposed to communicate with others with your username. You'd think xmpp is perfect! Nope, you'll have to fork the xmpp server for this use case. Why? Well, because XMPP standard supports nickname changing, which means in a context of a platform it would allow nickname spoofing. So you need to modify and add some security rules on top of it. "Solved problem" of course...
    - jcbrand 7y ago
      because XMPP standard supports nickname changing, which means in a context of a platform it would allow nickname spoofing Nicknames can be registered against a MUC so that other users can't use them. See here: https://xmpp.org/extensions/xep-0045.html#register https://xmpp.org/extensions/xep-0045.html#register This has been part of the MUC standard for years and there are XMPP servers which support this, so you don't need to fork. If you want to support nickname changing and still know whether it's the same user, you can use the newer XEP-0421: https://xmpp.org/extensions/xep-0421.html https://xmpp.org/extensions/xep-0421.html
    - jcbrand 7y ago
      Link me a JavaScript library that works cross platform on both iOS and Android with unified interface in React Native. https://github.com/xmppjs/xmpp.js https://github.com/xmppjs/xmpp.js
    - mariorossi666 7y ago
      as other have already said, Xmpp.js works quite well If it's Javascript it's already cross platform > Ye, which problem exactly? communicating via XMPP in a standardized way > All of them are solved partially And a new protocol based on half backed technologies would change that, how exactly? > On your platform you have a username and you are supposed to communicate with others with your username. On any forum or BBS I've been part of in my life, I've always used a nick, that changed over time. > Well, because XMPP standard supports nickname changing, which means in a context of a platform it would allow nickname spoofing. That's a feature, not a bug. In 1995 I could change my nick on IRC, in 1997 I could change my nick on ICQ, I still can change nick on Skype today (my artists friends do it on facebook all the times) Anyway, nick spoofing on XMPP is hardly a problem and it's not an XMPP fault. Have you ever tried to search for "someone has been impersonating me with FB messenger" on a search engine? > "Solved problem" of course. XMPP it's a solved problem, your chat where nick cannot be changed is your problem. Every implementation of standard protocols requires work, HTTP is a solved problem, but edge cases still exist. Name one standard federated protocol that could help you with that and make it simpler, please. Because I don't know any.

Leace 7y ago

> IMO we need something simpler, websocket and JSON based. Why JSON? JSON is the packaging format of this decade but remember when XMPP was conceived XML was the packaging format of that decade. Maybe CBOR would be more appropriate. No need to encode binary data (signatures, encryption) in base64 wrappers and more efficient encoding of frequently used stuff (no need for Whatsapp-stype FunXMPP).

ponyous 7y ago
For the sake of simplicity. Because JSON is native to web. And web is the biggest platform you have imo. It's annoying that you have to bring in XML parsing libraries if you want to implement XMPP in javascript environment.
- shantly 7y ago
  > web > annoying that you have to bring in XML parsing libraries Uhhhhhh... https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_and_serializing_XML https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_a...
  - ponyous 7y ago
    Ok yeah, if you target web exclusively this will work. But if you target Android JSC runtime for example it won't, because you have no access to DOM. When I said web I should really say javascript. If you replace it my point still stands.
- ktosobcy 7y ago
  > And web is the biggest platform you have imo. I thought we are in "mobile first" era already...
xellisx 7y ago
https://cbor.io/ https://cbor.io/

Flowdalic 7y ago

> Less standards, less use-cases - for example I don't think xmpp should take care of vcards, nickname and tons You mean you just want to use RFC 6120/6121? That's fine, just do it then.

z3t4 7y ago

This is my experience as well. Compared to for example IRC where you can just open a TCP socket and send ascii as it. I think a more simple protocol would lead to more integrations. It doesn't have to be as simple as IRC. One problem is that implementing audio/video p2p streaming is still super complicated. So we should probably only support text messaging as a first spec. And make separate and isolated audio/video spec!? A good start would be to take WebRTC as is and make a very simple protocol on top of it. And also make use of web push notifications. So the stack already exist and is fairly standardized. We just have to wrap it up in a very simple abstraction/protocol ontop.