9 ms·

More Instant Messaging Interoperability

141 points by zaik 4y ago

paxys 4y ago
Obligatory – https://xkcd.com/927/ https://xkcd.com/927/ There are a lot of problems in the IM space, but lack of standards isn't one of them.
edhelas 4y ago
XMPP & SIP There you are :)
- josteink 4y ago
  XMPP doesn't (to my knowledge) have any good, standardized way of dealing with offline communications and catching up with messages. SIP tried to do too much, was overly complex, XML-based and ended up doing nothing well enough to establish itself as a market/community favourite. "Nobody" outside telecoms does SIP, and I think that tells all one needs to know wrt market-penetration. These days I'm rooting for matrix[1]. Matrix seems to solve the issues people want IM to solve, it federates, and supports bridging to other types of networks which aren't matrix-based. It's not perfect. It may not be the final IM-solution to rule them all. But for me at least, it's a good, working solution for a federated, decentralized platform (in the original sense, not crypto hog-wash sense) for the IM needs I have. It might "just" be one step towards a better solution, but I'm sure the experiences people have with using and developing matrix is crucial in forming the solution-space in the right direction. We're not going to get to a decentralized and "good enough" solution unless someone is willing to walk down this road and take the first bumps for the team. I got my own instance, my own users, my own federated channels, serving my communities. Are you? [1] https://matrix.org/ https://matrix.org/
  - edhelas 4y ago
    > XMPP doesn't (to my knowledge) have any good, standardized way of dealing with offline communications and catching up with messages. XEP-0313: Message Archive Management https://xmpp.org/extensions/xep-0313.html https://xmpp.org/extensions/xep-0313.html > This document defines a protocol to query and control an archive of messages stored on a server. Since 2012. Implemented in all the major servers and clients for at least 5 to 10 years now.
    - kitkat_new 4y ago
      > XEP-0313: Message Archive Management https://xmpp.org/extensions/xep-0313.html https://xmpp.org/extensions/xep-0313.html" he said "good" MAM does not work with encryption and multiple devices, it relies on potentially different servers for each room -> other server goes down -> part of your history is lost, it is only for MUCs
      - MattJ100 4y ago
        > MAM does not work with encryption and multiple devices False. MAM is explicitly designed for use with multiple devices. OMEMO is fully compatible with MAM and multiple devices too. > it relies on potentially different servers for each room In XMPP, as deployed on the public network, each group is responsible for hosting its own data. That is, they do not replicate the group data and state between all federating servers that are part of the group in the way Matrix does. If the group goes down permanently and you do not have the history from the group saved locally in your client, you are correct that the data for that group is lost. Most XMPP clients default to keeping history on the user's device, rather than treating the server as a permanently available source of history. My experience is that this is good enough for most people, and the extra complexity of fully replicating groups is not necessary for the average person. That's not to say it doesn't have some uses (for which XMPP does have solutions, such as FMUC, they just aren't usually implemented or deployed on the public network - https://www.isode.com/whitepapers/federated-muc.html https://www.isode.com/whitepapers/federated-muc.html ). > it is only for MUCs This is also false, as you can see from even a cursory reading of the spec.
        kitkat_new 4y ago
        > False. MAM is explicitly designed for use with multiple devices. OMEMO is fully compatible with MAM and multiple devices too. please expand on how OMEMO encrypted messages land readable on other devices of you through MAM > If the group goes down permanently = certain single server in the group > My experience is that this is good enough for most people In mine it isn't when virtually anyone is (supposed to be) able to run a server, which he might abandon due to lost interest or might fail due to unprofessional maintenance. > This is also false, as you can see from even a cursory reading of the spec. you take that point
  - edhelas 4y ago
    > and supports bridging to other types of networks which aren't matrix-based https://sr.ht/~nicoco/slidge/ https://sr.ht/~nicoco/slidge/ Turn any XMPP client into that fancy multiprotocol chat app that every cool kid want. > Signal, Telegram, Discord, Steam, Mattermost, Facebook, Skype https://spectrum.im/ https://spectrum.im/ Spectrum is an open source instant messaging transport. It allows users to chat together even when they are using different IM networks. https://github.com/louiz/biboumi https://github.com/louiz/biboumi Biboumi is an XMPP gateway that connects to IRC servers and translates between the two protocols. It can be used to access IRC channels using any XMPP client as if these channels were XMPP MUCs. ------ I'm using all of those daily to connect to all my other accounts, Slidge is the most modern one and is having lots of features ported to the modern XMPP extensions.
    - jrepinc 4y ago
      > https://sr.ht/~nicoco/slidge/ https://sr.ht/~nicoco/slidge/ Turn any XMPP client into that fancy multiprotocol chat app that every cool kid want. Nice, didn't know this exists. Thanks for the link.
      - Semaphor 4y ago
        Here’s the HN discussion thread for the beta announcement: https://news.ycombinator.com/item?id=32713750 https://news.ycombinator.com/item?id=32713750 I was planning to install it, but still didn’t find the time yet :/
  - zamadatix 4y ago
    XMPP and SIP are decentralized, federated, and self hostable as well and they had bridges before matrix was a thing. The main draw for matrix for me is it has the most modern bridges. Not because the protocol allows it but because it’s where people have been making them lately. The main downside I’ve noticed is large rooms take an inordinate amount of time to join and sync. I still enjoy matrix I just don’t think it’s as unique as this pitch makes it out to be.
    - zaik 4y ago
      People make bridges for XMPP (see https://news.ycombinator.com/item?id=33420784 https://news.ycombinator.com/item?id=33420784 ) but bridges are just band-aids anyways: Most important they don't support e2e encryption. If we want to have messenger interoperability we need standardization. Matrix should focus on compliance with the existing XMPP internet standard instead of inventing yet another set of incompatible primitives.
    - mnot 4y ago
      The IETF has given up on XMPP for its own chat service.
      - MattJ100 4y ago
        What the IETF (or any organization in a similar position) sought for its discussions was an existing off-the-shelf product, not a protocol. They chose Zulip, because it is a product that has various features that are attractive for the IETF's use cases. The protocol it uses internally is pretty irrelevant from the IETF's perspective, as a user. If the IETF had developed its own chat tool and did not use XMPP for that, your comment would have more weight.
  - MattJ100 4y ago
    > XMPP doesn't (to my knowledge) have any good, standardized way of dealing with offline communications and catching up with messages. It does. Incoming and outgoing messages are synchronized across all your devices. Work on that feature began in 2012 (before Matrix was born), and is specified in XEP-0313: https://xmpp.org/extensions/xep-0313.html https://xmpp.org/extensions/xep-0313.html Due to people having multiple devices, and those devices having unreliable connections, it's obviously an essential part of any XMPP-based IM client these days. It's been required for full XMPP IM compliance since at least 2018.
  - mxuribe 4y ago
    I have to agree with @josteink ...while i have used xmpp for a few years quite happily, i am very much a matrix fanboy for the last few years. And, maybe sure, matrix might not represent the only/last/ultimate solution here...maybe its only half-way there...but i do favor its direction. So, for now, matrix (for me anyway) is the best direction forward. The more federated, interoperable, adoptable, and freedom-able that we have as a protocol, i think all the better. ....until we have intermingled both into the next, new best protocol: XMPatrix lol :-)
  - userbinator 4y ago
    SIP is not XML-based, as far as I know. It looks more like HTTP.
- Spivak 4y ago
  XMPP with a frozen set of extensions could work but without that you’ll end up creating iMessage where leaving the bubble has to fall back to the lowest common denominator or the Chrome problem where one large vendor will go buck wild and force everyone to play catch-up forever.
  - upofadown 4y ago
    XMPP without a frozen set of extensions seems to work quite well in practice. If a client doesn't support something then that something just doesn't work. The "X" in XMPP stands to extensible... How well that actually works is XMPP's killer feature...
    - samus 4y ago
      The problem is that the core feature set might not contain everything that people nowadays expect from a chat application. At the very least, an updated profile would have to be defined. Ma lot of the extensions have been published a long time ago.
    - PaulHoule 4y ago
      XMPP is popular among soldiers and cops. A solider with a sporadic internet connection can fill out a form about what their unit did today and it gets posted to a server when the connection up. In Baltimore cops communicate with XMPP and the messages get loaded into Lotus Notes.
  - jeroenhd 4y ago
    XMPP has compliance suites (https://xmpp.org/extensions/xep-0459.html https://xmpp.org/extensions/xep-0459.html is the most recent version) that lists XEP requirements which a client or server can fulfill. Based on "core" or "advanced" compliance in a certain area, you could pretty easily communicate the level of support. That said, basic things like "user avatars" are categorized as "advanced client" support so whatever "core" functionality is listed is pretty useless to me.
- guenthert 4y ago
  Is this the right time to ask for a good^Wyour favorite XMPP client on Android and iOS?
  - genpfault 4y ago
    > a good XMPP client on Android Conversations[1]? [1]: https://github.com/iNPUTmice/Conversations https://github.com/iNPUTmice/Conversations
aliqot 4y ago
which set of RFC's is "xmpp"
- matthews2 4y ago
  Only the core of XMPP are IETF RFCs (e.g. RFCs 6120, 6121, 7622). Most of the fun stuff is specified in XEPs, like XEP 0045 (multi-user chatrooms) and XEP 0384 (OMEMO encryption).
  - aliqot 4y ago
    See? It's stone soup.
    - zaik 4y ago
      That's probably also the reason TCP failed to catch on: https://en.m.wikipedia.org/wiki/Transmission_Control_Protocol#RFC_documents https://en.m.wikipedia.org/wiki/Transmission_Control_Protoco...
      - cdaringe 4y ago
        I don’t get it. Is this a zing!
hpfr 4y ago
There’s a proposal for Matrix on the associated mailing list from Element people: https://mailarchive.ietf.org/arch/msg/mimi/jvyvyJwgUhNgFyNYmAO3SrQBSeg/ https://mailarchive.ietf.org/arch/msg/mimi/jvyvyJwgUhNgFyNYm...
kitkat_new 4y ago
> Any protocols or practices that already exist in this space: I wonder why they haven't mentioned the Matrix protocol there.
- zaik 4y ago
  Maybe the organization behind Matrix wants to retain control over the protocol instead of standardizing it? XMPP covers the use-case of Matrix anyways.
  - feanaro 4y ago
    matrix.org is interested in standardising, see https://mailarchive.ietf.org/arch/msg/mimi/jvyvyJwgUhNgFyNYmAO3SrQBSeg/ https://mailarchive.ietf.org/arch/msg/mimi/jvyvyJwgUhNgFyNYm...
  - kitkat_new 4y ago
    It is already standardized: https://spec.matrix.org/latest/ https://spec.matrix.org/latest/
    - deleted 4y ago
      [deleted]
A4ET8a8uTh0 4y ago
I am just happy there is at least some interest in that space again. I am becoming increasingly tired of companies making their own implementations, reinventing the wheel and locking their 'community' behind their particular app. I miss IRC, I miss pidgin. I get that it is an uphill battle, because there is money to be lost by various corporate interests, but this would likely be one of the first steps to maybe allow hope that it could happen.
- krono 4y ago
  The EU's Digital Markets Act[0] will require interoperability for various kinds of services between what they call "gatekeeper" entities. You might be thinking "sounds to good to be true" or "no such thing as a free lunch", and if so - you have just won a prize: the EU's Digital Services Act[1]! This second balancing act includes such wonderful requirements for hosting providers and data processors to pro-actively scan for and report illegal data (leave no bit unturned!), to identify and keep verifiable records of their customers' identities (match those bits!), external auditing and "trusted flaggers" (sell those bits!), full-access no-limits and thus decrypted sharing of customer data with authorities during crises (to ensure the security and continuing stability of the Galactic Republic!). Hopefully this attempt at bringing the news in a comedic manner has helped to soften any feelings of hopelessness and impending doom :D https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/digital-markets-act-ensuring-fair-and-open-digital-markets_en https://ec.europa.eu/info/strategy/priorities-2019-2024/euro... https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/digital-services-act-ensuring-safe-and-accountable-online-environment_en https://ec.europa.eu/info/strategy/priorities-2019-2024/euro...
  - jsmith45 4y ago
    Some of what you say is either worse case interpretations, or only applies to very large platforms (>45 million monthly active users). The DSA also has good parts like preventing sites from doing the following: Site: We have suspended you account and hidden all content you posted because our buggy AI thinks some content you posted violates a law or term of service. This is a final decision and cannot be appealed. You: What content? What law or term of service? Site: we don't have to tell you, and we don't have to tell you. We said this was final with no appeal so you are lucky we are even replying in the first place. You: now you must attempt to make a big enough shitstorm on twitter that the company might actually get a human to look at things and notice their shitty AI made a mistake. Instead the law requires identifying the content with specificity, identity which law or term of service they think was violated with specificity, they must have a human powered appeals process. It provides a non-binding out of court dispute settlement process, as an alternative to suing the company to force them to comply with the law. For reference, the act as enacted: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2065 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A...
userbinator 4y ago
I personally think an early version of MSNP would make a good base to build upon; it's relatively simple to write a client for, is extensible in a reasonably straightforward way, and already has a lot of the functionality that one would expect for IM. Interestingly, Microsoft actually submitted an old draft of it to the IETF: https://www.ietf.org/archive/id/draft-movva-msn-messenger-protocol-00.txt https://www.ietf.org/archive/id/draft-movva-msn-messenger-pr...
- HeckFeck 4y ago
  There's an open source server for it too: https://escargot.chat/ https://escargot.chat/
  - _chu1 4y ago
    Which will be rewritten very soon in C# and not open-sourced, however an agreement to obtain the source could be made and you might could even discuss it being open-sourced (they saw no benefit in it), contact the development team in their Discord.
    - HeckFeck 4y ago
      It seems that things changed since I last looked. The public repo hasn't been updated in a year: https://gitlab.com/escargot-chat/server https://gitlab.com/escargot-chat/server I wonder why they closed the source. Even if there is no 'benefit' to the team, sharing the source guarantees the longevity and preservation of MSN Messenger. That benefits the future, as well as everyone interested in MSN now.
  - userbinator 4y ago
    A quick search of GitHub reveals a few other implementations in varying degrees of completeness.
bullen 4y ago
Just use SMTP.
- zaik 4y ago
  Thus DeltaChat was born.
  - bullen 4y ago
    Yes, but not on your existing e-mail... jezuz christ! They obviously need their own SMTP servers, I'm not giving a third party my e-mail login?
    - zaik 4y ago
      It's an email client that looks like a messenger. It's like saying "I'm not giving Thunderbird my e-mail login".
      - bullen 4y ago
        Sure, but yes I'm not giving Thunderbird my login. SMTP and HTTP... everything else is crap.
asim 4y ago
Alright, let me throw my hat into this ring with a totally unfinished idea. I started working on a design for something called the Micro Communication Protocol (MUCP) [1]. It's a header based protocol that's transport agnostic and focuses on service-to-service communication. An early prototype existed in Micro [2] but I'm primarily focused on redesigning the protocol before re-implementing it. Micro was geared towards API first services but I'm looking to expand the scope and try to build a UI layer on top. Most of the protocols focused very much on communication between people but I think if you focus on service-to-service communication more broadly it opens up the avenue to all sorts of multiplayer collaboration. - [1] https://github.com/micro/network/blob/main/PROTOCOL.md https://github.com/micro/network/blob/main/PROTOCOL.md - [2] https://github.com/micro/micro https://github.com/micro/micro
zokier 4y ago
What is the point of this wg? Looking at the participants it is extremely unlikely that this will have any impact on the services that people actually use. The first point of action should be to get the right stakeholders around the same table, only then there is any chance of real progress. Otherwise I anticipate just lot of hamdwaving and fancy manifestos and little action.
- walterbell 4y ago
  Several large messenger service vendors have been at the table for several years, in the IETF MLS project, ratified in September 2022, as a precursor to this effort, https://datatracker.ietf.org/wg/mls/about/ https://datatracker.ietf.org/wg/mls/about/
tschellenbach 4y ago
We don't need messaging apps to interoperate. We need the notification center in your phone around push notifications to be amazing and centralize everything.
- nicoco 4y ago
  And have supercomputers in our pockets because you need 554 different apps that serve the same purpose? No thanks.
jmole 4y ago
It seems like the protocol question is adjacent to the actual problems that messaging apps solve for users: mapping a particular device to a trusted identifier within some namespace. iMessage has a unique mapping between iMessage account and phone number. Signal has another. WhatsApp has another. If you want to message 650-867-5309, who should receive the message?
- 2Gkashmiri 4y ago
  Uh, 6508675309@whatsapp or @signal If there is no account on that service, just like email, there would be a failure message but it should work. This is how mastodon or matrix does local handles vs federated handles. Simple @user for local and @local@server for outside.
  - nerdponx 4y ago
    How about a URI? whatsapp:5551234567, signal:5551234567, etc.
    - 2Gkashmiri 4y ago
      works fine
- deleted 4y ago
  [deleted]
walterbell 4y ago
Kudos to Wire architects and leadership for spending years to bring IETF MLS (encrypted group messaging) to fruition, pulling together a coalition that included input from Cisco, Facebook, Google, INRIA, Matrix/Element, MIT, Mozilla and Twitter. Haven't seen any public statements from Signal about MLS. The founders of Wire previously contributed to the Opus HD audio code that laid the groundwork for WebRTC, now ubiquitous in remote/WFH conferencing products. With the IETF MLS protocol for encrypted group messages now defined, interoperability between messenger services is the next step. This IETF MIMI group may be small, but they are not starting from scratch, as interoperability was often discussed, and deferred to this anticipated project, during IETF MLS protocol design.

141 points by zaik 4y ago

Obligatory – https://xkcd.com/927/ https://xkcd.com/927/ There are a lot of problems in the IM space, but lack of standards isn't one of them.

edhelas 4y ago

XMPP & SIP There you are :)

josteink 4y ago
XMPP doesn't (to my knowledge) have any good, standardized way of dealing with offline communications and catching up with messages. SIP tried to do too much, was overly complex, XML-based and ended up doing nothing well enough to establish itself as a market/community favourite. "Nobody" outside telecoms does SIP, and I think that tells all one needs to know wrt market-penetration. These days I'm rooting for matrix[1]. Matrix seems to solve the issues people want IM to solve, it federates, and supports bridging to other types of networks which aren't matrix-based. It's not perfect. It may not be the final IM-solution to rule them all. But for me at least, it's a good, working solution for a federated, decentralized platform (in the original sense, not crypto hog-wash sense) for the IM needs I have. It might "just" be one step towards a better solution, but I'm sure the experiences people have with using and developing matrix is crucial in forming the solution-space in the right direction. We're not going to get to a decentralized and "good enough" solution unless someone is willing to walk down this road and take the first bumps for the team. I got my own instance, my own users, my own federated channels, serving my communities. Are you? [1] https://matrix.org/ https://matrix.org/
- edhelas 4y ago
  > XMPP doesn't (to my knowledge) have any good, standardized way of dealing with offline communications and catching up with messages. XEP-0313: Message Archive Management https://xmpp.org/extensions/xep-0313.html https://xmpp.org/extensions/xep-0313.html > This document defines a protocol to query and control an archive of messages stored on a server. Since 2012. Implemented in all the major servers and clients for at least 5 to 10 years now.
  - kitkat_new 4y ago
    > XEP-0313: Message Archive Management https://xmpp.org/extensions/xep-0313.html https://xmpp.org/extensions/xep-0313.html" he said "good" MAM does not work with encryption and multiple devices, it relies on potentially different servers for each room -> other server goes down -> part of your history is lost, it is only for MUCs
    - MattJ100 4y ago
      > MAM does not work with encryption and multiple devices False. MAM is explicitly designed for use with multiple devices. OMEMO is fully compatible with MAM and multiple devices too. > it relies on potentially different servers for each room In XMPP, as deployed on the public network, each group is responsible for hosting its own data. That is, they do not replicate the group data and state between all federating servers that are part of the group in the way Matrix does. If the group goes down permanently and you do not have the history from the group saved locally in your client, you are correct that the data for that group is lost. Most XMPP clients default to keeping history on the user's device, rather than treating the server as a permanently available source of history. My experience is that this is good enough for most people, and the extra complexity of fully replicating groups is not necessary for the average person. That's not to say it doesn't have some uses (for which XMPP does have solutions, such as FMUC, they just aren't usually implemented or deployed on the public network - https://www.isode.com/whitepapers/federated-muc.html https://www.isode.com/whitepapers/federated-muc.html ). > it is only for MUCs This is also false, as you can see from even a cursory reading of the spec.
      - kitkat_new 4y ago
        > False. MAM is explicitly designed for use with multiple devices. OMEMO is fully compatible with MAM and multiple devices too. please expand on how OMEMO encrypted messages land readable on other devices of you through MAM > If the group goes down permanently = certain single server in the group > My experience is that this is good enough for most people In mine it isn't when virtually anyone is (supposed to be) able to run a server, which he might abandon due to lost interest or might fail due to unprofessional maintenance. > This is also false, as you can see from even a cursory reading of the spec. you take that point
- edhelas 4y ago
  > and supports bridging to other types of networks which aren't matrix-based https://sr.ht/~nicoco/slidge/ https://sr.ht/~nicoco/slidge/ Turn any XMPP client into that fancy multiprotocol chat app that every cool kid want. > Signal, Telegram, Discord, Steam, Mattermost, Facebook, Skype https://spectrum.im/ https://spectrum.im/ Spectrum is an open source instant messaging transport. It allows users to chat together even when they are using different IM networks. https://github.com/louiz/biboumi https://github.com/louiz/biboumi Biboumi is an XMPP gateway that connects to IRC servers and translates between the two protocols. It can be used to access IRC channels using any XMPP client as if these channels were XMPP MUCs. ------ I'm using all of those daily to connect to all my other accounts, Slidge is the most modern one and is having lots of features ported to the modern XMPP extensions.
  - jrepinc 4y ago
    > https://sr.ht/~nicoco/slidge/ https://sr.ht/~nicoco/slidge/ Turn any XMPP client into that fancy multiprotocol chat app that every cool kid want. Nice, didn't know this exists. Thanks for the link.
    - Semaphor 4y ago
      Here’s the HN discussion thread for the beta announcement: https://news.ycombinator.com/item?id=32713750 https://news.ycombinator.com/item?id=32713750 I was planning to install it, but still didn’t find the time yet :/
- zamadatix 4y ago
  XMPP and SIP are decentralized, federated, and self hostable as well and they had bridges before matrix was a thing. The main draw for matrix for me is it has the most modern bridges. Not because the protocol allows it but because it’s where people have been making them lately. The main downside I’ve noticed is large rooms take an inordinate amount of time to join and sync. I still enjoy matrix I just don’t think it’s as unique as this pitch makes it out to be.
  - zaik 4y ago
    People make bridges for XMPP (see https://news.ycombinator.com/item?id=33420784 https://news.ycombinator.com/item?id=33420784 ) but bridges are just band-aids anyways: Most important they don't support e2e encryption. If we want to have messenger interoperability we need standardization. Matrix should focus on compliance with the existing XMPP internet standard instead of inventing yet another set of incompatible primitives.
  - mnot 4y ago
    The IETF has given up on XMPP for its own chat service.
    - MattJ100 4y ago
      What the IETF (or any organization in a similar position) sought for its discussions was an existing off-the-shelf product, not a protocol. They chose Zulip, because it is a product that has various features that are attractive for the IETF's use cases. The protocol it uses internally is pretty irrelevant from the IETF's perspective, as a user. If the IETF had developed its own chat tool and did not use XMPP for that, your comment would have more weight.
- MattJ100 4y ago
  > XMPP doesn't (to my knowledge) have any good, standardized way of dealing with offline communications and catching up with messages. It does. Incoming and outgoing messages are synchronized across all your devices. Work on that feature began in 2012 (before Matrix was born), and is specified in XEP-0313: https://xmpp.org/extensions/xep-0313.html https://xmpp.org/extensions/xep-0313.html Due to people having multiple devices, and those devices having unreliable connections, it's obviously an essential part of any XMPP-based IM client these days. It's been required for full XMPP IM compliance since at least 2018.
- mxuribe 4y ago
  I have to agree with @josteink ...while i have used xmpp for a few years quite happily, i am very much a matrix fanboy for the last few years. And, maybe sure, matrix might not represent the only/last/ultimate solution here...maybe its only half-way there...but i do favor its direction. So, for now, matrix (for me anyway) is the best direction forward. The more federated, interoperable, adoptable, and freedom-able that we have as a protocol, i think all the better. ....until we have intermingled both into the next, new best protocol: XMPatrix lol :-)
- userbinator 4y ago
  SIP is not XML-based, as far as I know. It looks more like HTTP.
Spivak 4y ago
XMPP with a frozen set of extensions could work but without that you’ll end up creating iMessage where leaving the bubble has to fall back to the lowest common denominator or the Chrome problem where one large vendor will go buck wild and force everyone to play catch-up forever.
- upofadown 4y ago
  XMPP without a frozen set of extensions seems to work quite well in practice. If a client doesn't support something then that something just doesn't work. The "X" in XMPP stands to extensible... How well that actually works is XMPP's killer feature...
  - samus 4y ago
    The problem is that the core feature set might not contain everything that people nowadays expect from a chat application. At the very least, an updated profile would have to be defined. Ma lot of the extensions have been published a long time ago.
  - PaulHoule 4y ago
    XMPP is popular among soldiers and cops. A solider with a sporadic internet connection can fill out a form about what their unit did today and it gets posted to a server when the connection up. In Baltimore cops communicate with XMPP and the messages get loaded into Lotus Notes.
- jeroenhd 4y ago
  XMPP has compliance suites (https://xmpp.org/extensions/xep-0459.html https://xmpp.org/extensions/xep-0459.html is the most recent version) that lists XEP requirements which a client or server can fulfill. Based on "core" or "advanced" compliance in a certain area, you could pretty easily communicate the level of support. That said, basic things like "user avatars" are categorized as "advanced client" support so whatever "core" functionality is listed is pretty useless to me.
guenthert 4y ago
Is this the right time to ask for a good^Wyour favorite XMPP client on Android and iOS?
- genpfault 4y ago
  > a good XMPP client on Android Conversations[1]? [1]: https://github.com/iNPUTmice/Conversations https://github.com/iNPUTmice/Conversations

aliqot 4y ago

which set of RFC's is "xmpp"

matthews2 4y ago
Only the core of XMPP are IETF RFCs (e.g. RFCs 6120, 6121, 7622). Most of the fun stuff is specified in XEPs, like XEP 0045 (multi-user chatrooms) and XEP 0384 (OMEMO encryption).
- aliqot 4y ago
  See? It's stone soup.
  - zaik 4y ago
    That's probably also the reason TCP failed to catch on: https://en.m.wikipedia.org/wiki/Transmission_Control_Protocol#RFC_documents https://en.m.wikipedia.org/wiki/Transmission_Control_Protoco...
    - cdaringe 4y ago
      I don’t get it. Is this a zing!

hpfr 4y ago

There’s a proposal for Matrix on the associated mailing list from Element people: https://mailarchive.ietf.org/arch/msg/mimi/jvyvyJwgUhNgFyNYmAO3SrQBSeg/ https://mailarchive.ietf.org/arch/msg/mimi/jvyvyJwgUhNgFyNYm...

kitkat_new 4y ago

> Any protocols or practices that already exist in this space: I wonder why they haven't mentioned the Matrix protocol there.

zaik 4y ago
Maybe the organization behind Matrix wants to retain control over the protocol instead of standardizing it? XMPP covers the use-case of Matrix anyways.
- feanaro 4y ago
  matrix.org is interested in standardising, see https://mailarchive.ietf.org/arch/msg/mimi/jvyvyJwgUhNgFyNYmAO3SrQBSeg/ https://mailarchive.ietf.org/arch/msg/mimi/jvyvyJwgUhNgFyNYm...
- kitkat_new 4y ago
  It is already standardized: https://spec.matrix.org/latest/ https://spec.matrix.org/latest/
  - deleted 4y ago
    [deleted]

A4ET8a8uTh0 4y ago

I am just happy there is at least some interest in that space again. I am becoming increasingly tired of companies making their own implementations, reinventing the wheel and locking their 'community' behind their particular app. I miss IRC, I miss pidgin. I get that it is an uphill battle, because there is money to be lost by various corporate interests, but this would likely be one of the first steps to maybe allow hope that it could happen.

krono 4y ago
The EU's Digital Markets Act[0] will require interoperability for various kinds of services between what they call "gatekeeper" entities. You might be thinking "sounds to good to be true" or "no such thing as a free lunch", and if so - you have just won a prize: the EU's Digital Services Act[1]! This second balancing act includes such wonderful requirements for hosting providers and data processors to pro-actively scan for and report illegal data (leave no bit unturned!), to identify and keep verifiable records of their customers' identities (match those bits!), external auditing and "trusted flaggers" (sell those bits!), full-access no-limits and thus decrypted sharing of customer data with authorities during crises (to ensure the security and continuing stability of the Galactic Republic!). Hopefully this attempt at bringing the news in a comedic manner has helped to soften any feelings of hopelessness and impending doom :D https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/digital-markets-act-ensuring-fair-and-open-digital-markets_en https://ec.europa.eu/info/strategy/priorities-2019-2024/euro... https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/digital-services-act-ensuring-safe-and-accountable-online-environment_en https://ec.europa.eu/info/strategy/priorities-2019-2024/euro...
- jsmith45 4y ago
  Some of what you say is either worse case interpretations, or only applies to very large platforms (>45 million monthly active users). The DSA also has good parts like preventing sites from doing the following: Site: We have suspended you account and hidden all content you posted because our buggy AI thinks some content you posted violates a law or term of service. This is a final decision and cannot be appealed. You: What content? What law or term of service? Site: we don't have to tell you, and we don't have to tell you. We said this was final with no appeal so you are lucky we are even replying in the first place. You: now you must attempt to make a big enough shitstorm on twitter that the company might actually get a human to look at things and notice their shitty AI made a mistake. Instead the law requires identifying the content with specificity, identity which law or term of service they think was violated with specificity, they must have a human powered appeals process. It provides a non-binding out of court dispute settlement process, as an alternative to suing the company to force them to comply with the law. For reference, the act as enacted: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2065 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A...

userbinator 4y ago

I personally think an early version of MSNP would make a good base to build upon; it's relatively simple to write a client for, is extensible in a reasonably straightforward way, and already has a lot of the functionality that one would expect for IM. Interestingly, Microsoft actually submitted an old draft of it to the IETF: https://www.ietf.org/archive/id/draft-movva-msn-messenger-protocol-00.txt https://www.ietf.org/archive/id/draft-movva-msn-messenger-pr...

HeckFeck 4y ago
There's an open source server for it too: https://escargot.chat/ https://escargot.chat/
- _chu1 4y ago
  Which will be rewritten very soon in C# and not open-sourced, however an agreement to obtain the source could be made and you might could even discuss it being open-sourced (they saw no benefit in it), contact the development team in their Discord.
  - HeckFeck 4y ago
    It seems that things changed since I last looked. The public repo hasn't been updated in a year: https://gitlab.com/escargot-chat/server https://gitlab.com/escargot-chat/server I wonder why they closed the source. Even if there is no 'benefit' to the team, sharing the source guarantees the longevity and preservation of MSN Messenger. That benefits the future, as well as everyone interested in MSN now.
- userbinator 4y ago
  A quick search of GitHub reveals a few other implementations in varying degrees of completeness.

bullen 4y ago

Just use SMTP.

zaik 4y ago
Thus DeltaChat was born.
- bullen 4y ago
  Yes, but not on your existing e-mail... jezuz christ! They obviously need their own SMTP servers, I'm not giving a third party my e-mail login?
  - zaik 4y ago
    It's an email client that looks like a messenger. It's like saying "I'm not giving Thunderbird my e-mail login".
    - bullen 4y ago
      Sure, but yes I'm not giving Thunderbird my login. SMTP and HTTP... everything else is crap.

asim 4y ago

Alright, let me throw my hat into this ring with a totally unfinished idea. I started working on a design for something called the Micro Communication Protocol (MUCP) [1]. It's a header based protocol that's transport agnostic and focuses on service-to-service communication. An early prototype existed in Micro [2] but I'm primarily focused on redesigning the protocol before re-implementing it. Micro was geared towards API first services but I'm looking to expand the scope and try to build a UI layer on top. Most of the protocols focused very much on communication between people but I think if you focus on service-to-service communication more broadly it opens up the avenue to all sorts of multiplayer collaboration. - [1] https://github.com/micro/network/blob/main/PROTOCOL.md https://github.com/micro/network/blob/main/PROTOCOL.md - [2] https://github.com/micro/micro https://github.com/micro/micro

zokier 4y ago

What is the point of this wg? Looking at the participants it is extremely unlikely that this will have any impact on the services that people actually use. The first point of action should be to get the right stakeholders around the same table, only then there is any chance of real progress. Otherwise I anticipate just lot of hamdwaving and fancy manifestos and little action.

walterbell 4y ago
Several large messenger service vendors have been at the table for several years, in the IETF MLS project, ratified in September 2022, as a precursor to this effort, https://datatracker.ietf.org/wg/mls/about/ https://datatracker.ietf.org/wg/mls/about/

tschellenbach 4y ago

We don't need messaging apps to interoperate. We need the notification center in your phone around push notifications to be amazing and centralize everything.

nicoco 4y ago
And have supercomputers in our pockets because you need 554 different apps that serve the same purpose? No thanks.

jmole 4y ago

It seems like the protocol question is adjacent to the actual problems that messaging apps solve for users: mapping a particular device to a trusted identifier within some namespace. iMessage has a unique mapping between iMessage account and phone number. Signal has another. WhatsApp has another. If you want to message 650-867-5309, who should receive the message?

2Gkashmiri 4y ago
Uh, 6508675309@whatsapp or @signal If there is no account on that service, just like email, there would be a failure message but it should work. This is how mastodon or matrix does local handles vs federated handles. Simple @user for local and @local@server for outside.
- nerdponx 4y ago
  How about a URI? whatsapp:5551234567, signal:5551234567, etc.
  - 2Gkashmiri 4y ago
    works fine
deleted 4y ago
[deleted]

walterbell 4y ago

Kudos to Wire architects and leadership for spending years to bring IETF MLS (encrypted group messaging) to fruition, pulling together a coalition that included input from Cisco, Facebook, Google, INRIA, Matrix/Element, MIT, Mozilla and Twitter. Haven't seen any public statements from Signal about MLS. The founders of Wire previously contributed to the Opus HD audio code that laid the groundwork for WebRTC, now ubiquitous in remote/WFH conferencing products. With the IETF MLS protocol for encrypted group messages now defined, interoperability between messenger services is the next step. This IETF MIMI group may be small, but they are not starting from scratch, as interoperability was often discussed, and deferred to this anticipated project, during IETF MLS protocol design.