More Instant Messaging Interoperability

https://datatracker.ietf.org/doc/bofreq-cooper-more-instant-messaging-interoperability/

by zaik • 4 years ago

141 78 4 years ago

datatracker.ietf.org

edhelas3• 4 years ago

XMPP & SIP

There you are :)

josteink• 4 years 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/

edhelas3• 4 years 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

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.

edhelas3• 4 years ago

and supports bridging to other types of networks which aren't matrix-based

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/

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

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.

zamadatix• 4 years 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.

MattJ1004• 4 years 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

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• 4 years 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 :-)

userbinator3• 4 years ago

SIP is not XML-based, as far as I know. It looks more like HTTP.

Spivak• 4 years 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• 4 years 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...

jeroenhd• 4 years ago

XMPP has compliance suites (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• 4 years ago

Is this the right time to ask for a good^Wyour favorite XMPP client on Android and iOS?

genpfault• 4 years ago

a good XMPP client on Android

Conversations[1]?

[1] https://github.com/iNPUTmice/Conversations

aliqot2• 4 years ago

which set of RFC's is "xmpp"

matthews2• 4 years 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).

aliqot2• 4 years ago

See? It's stone soup.

hpfr• 4 years ago

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

kitkat_new9• 4 years ago

Any protocols or practices that already exist in this space:

I wonder why they haven't mentioned the Matrix protocol there.

zaik5• 4 years 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• 4 years ago

matrix.org is interested in standardising, see https://mailarchive.ietf.org/arch/msg/mimi/jvyvyJwgUhNgFyNYm...

kitkat_new9• 4 years ago

It is already standardized: https://spec.matrix.org/latest/

A4ET8a8uTh03• 4 years 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.

krono2• 4 years 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/euro...

jsmith45• 4 years 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%3A...

_23sd• 4 years ago

Some gatekeepers (i.e. Apple) will probably consider no longer offering messaging services in the EU rather than be forced to open the platform under the DMA and potentially break their E2EE under the DSA. Also, the DMA isn't requiring that services use a standardized protocol for interoperability, so in practice this probably means that integrating with a gatekeeper's service means following all their rules and keeping up with periodic changes to their API. Maybe I'm just being over-cynical but I think we'll have to wait and see how effective this is at creating widespread interoperability.

pabs32• 4 years ago

I note that IRC and pidgin still exist :)

A4ET8a8uTh03• 4 years ago

Technically true, but population that uses it is very small.

Come to think of it. You raised a very interesting point. I will need to think of it a little bit more. I want open standards to reign, but is it ok to enforce destruction of walled gardens.

userbinator3• 4 years 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-pr...

HeckFeck2• 4 years ago

There's an open source server for it too:

https://escargot.chat/

_chu1• 4 years 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.

userbinator3• 4 years ago

A quick search of GitHub reveals a few other implementations in varying degrees of completeness.

bullen3• 4 years ago

Just use SMTP.

zaik5• 4 years ago

Thus DeltaChat was born.

bullen3• 4 years 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?

asim• 4 years 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 - [2] https://github.com/micro/micro

zokier• 4 years 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.

walterbell2• 4 years 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/

tschellenbach• 4 years 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.

nicoco5• 4 years ago

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

jmole• 4 years 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?

2Gkashmiri2• 4 years 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• 4 years ago

How about a URI? whatsapp:5551234567, signal:5551234567, etc.

paxys• 4 years ago

Obligatory – https://xkcd.com/927/

There are a lot of problems in the IM space, but lack of standards isn't one of them.

walterbell2• 4 years 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.

More Instant Messaging Interoperability

Related Stories