[HN Gopher] More Instant Messaging Interoperability
___________________________________________________________________
More Instant Messaging Interoperability
Author : zaik
Score : 129 points
Date : 2022-11-01 12:11 UTC (10 hours ago)
(HTM) web link (datatracker.ietf.org)
(TXT) w3m dump (datatracker.ietf.org)
| A4ET8a8uTh0 wrote:
| 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 wrote:
| 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...
|
| https://ec.europa.eu/info/strategy/priorities-2019-2024/euro...
| resfirestar wrote:
| 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.
| A4ET8a8uTh0 wrote:
| It would be rather short-sighted in my view. While
| China/India are biggest market in terms of sheer amount of
| people, those people may not have the same levels of
| disposable income when compared to EU citizens. I
| absolutely understand that Apple could level that threat,
| but it would abandoning a major market for.. what exactly?
| jsmith45 wrote:
| 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...
| krono wrote:
| > worse case interpretations
|
| More often than not those end up not having been too far
| off.
|
| The total time to implement might get stretched out,
| components dirtied by general public resistance will be
| repackaged or repurposed, and any debate or discussion not
| in the plan's favour will be actively misdirected.
|
| It's a sound strategy, and I hate everything about it.
|
| > or only applies to very large platforms
|
| Even a single one of which is nigh impossible to avoid. At
| least some data - either by you, from you, or about you -
| will end up on AWS/GCP/Azure. A fact of life.
|
| > has good parts
|
| All of which solve problems that are easily mitigated
| today, on my own terms, for less effort, and either for
| free or for cheap.
|
| Not a very good deal at all.
| asim wrote:
| 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
| walterbell wrote:
| 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.
| jmole wrote:
| 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 wrote:
| 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 wrote:
| How about a URI? whatsapp:5551234567, signal:5551234567, etc.
| [deleted]
| userbinator wrote:
| 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...
| HeckFeck wrote:
| There's an open source server for it too:
|
| https://escargot.chat/
| bobsmith432 wrote:
| 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.
| userbinator wrote:
| A quick search of GitHub reveals a few other implementations
| in varying degrees of completeness.
| edhelas wrote:
| XMPP & SIP
|
| There you are :)
| Spivak wrote:
| 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.
| jeroenhd wrote:
| 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.
| upofadown wrote:
| 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...
| PaulHoule wrote:
| 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.
| samus wrote:
| 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.
| josteink wrote:
| 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/
| zamadatix wrote:
| 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 wrote:
| People make bridges for XMPP (see
| 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.
| userbinator wrote:
| SIP is not XML-based, as far as I know. It looks more like
| HTTP.
| MattJ100 wrote:
| > 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.
| edhelas wrote:
| > 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.
| kitkat_new wrote:
| > XEP-0313: Message Archive Management
| 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 wrote:
| > 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 ).
|
| > it is only for MUCs
|
| This is also false, as you can see from even a cursory
| reading of the spec.
| kitkat_new wrote:
| > 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
| Semaphor wrote:
| > please expand on how OMEMO encrypted messages land
| readable on other devices of you through MAM
|
| Not GP, and I don't know how it works technically, but I
| can confirm that OMEMO encrypted messages sync to other
| devices when I come back online there.
| MattJ100 wrote:
| > certain single server in the group
|
| To be clear, only the server that the group is hosted on.
| Servers are not "in groups", so your statement doesn't
| make sense.
|
| > please expand on how OMEMO encrypted messages land
| readable on other devices of you through MAM
|
| MAM is a feature of XMPP that provides a way to query all
| incoming and outgoing messages, including those received
| while the client was offline.
|
| OMEMO is a many-to-many end-to-end encryption protocol.
| Whether a message is delivered while a client is
| connected, or later via synchronization after a period of
| disconnection, doesn't have any effect on the encryption
| or ability of a client to decrypt the message.
|
| These things can all be verified by reading the specs or
| simply using any modern XMPP client and observing it work
| for yourself.
| kitkat_new wrote:
| > To be clear, only the server that the group is hosted
| on.
|
| Fullstop
|
| > Whether a message is delivered while a client is
| connected, or later via synchronization after a period of
| disconnection, doesn't have any effect on the encryption
| or ability of a client to decrypt the message.
|
| what about when a client creates a fresh connection and I
| want to read my messages on it?
| nicoco wrote:
| What you want is a bit contradictory with wanting e2ee.
| kitkat_new wrote:
| how so?
| nicoco wrote:
| It seems to me that if any new device/app that "logs to
| your IM account" gets all message history, you're kind of
| defeating the point of having E2EE in the first place. If
| I sent encrypted messages to a trusted device of yours, I
| suppose I don't really want any new device of yours to
| get these messages.
|
| I agree that this does not create the best "user
| experience", but if that is what you are looking for,
| maybe you didn't want E2EE in the first place? It could
| be possible to have a XEP that covers "history syncing
| between my devices", but what's the point of E2EE if
| encrypted information can just be transferred and
| duplicated like this?
|
| It's also possible to disable OMEMO if having history
| sync'ed _on any new device_ is what 's most important to
| you. It's not like messages are sent as plain unencrypted
| text (unlike email...), TLS is used. If you and the other
| end are on servers you trust (or own), there is little
| reason to use OMEMO anyway. Except that nice lock icon
| that supposedly means "safe" without really defining
| "safe *from what*".
| mxuribe wrote:
| 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 :-)
| edhelas wrote:
| > 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.
| jrepinc wrote:
| > 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 wrote:
| Here's the HN discussion thread for the beta
| announcement:
| https://news.ycombinator.com/item?id=32713750
|
| I was planning to install it, but still didn't find the
| time yet :/
| guenthert wrote:
| Is this the right time to ask for a good^Wyour favorite XMPP
| client on Android and iOS?
| genpfault wrote:
| > a good XMPP client on Android
|
| Conversations[1]?
|
| [1]: https://github.com/iNPUTmice/Conversations
| paxys wrote:
| Obligatory - https://xkcd.com/927/
|
| There are a lot of problems in the IM space, but lack of
| standards isn't one of them.
| hpfr wrote:
| There's a proposal for Matrix on the associated mailing list from
| Element people:
| https://mailarchive.ietf.org/arch/msg/mimi/jvyvyJwgUhNgFyNYm...
| bullen wrote:
| Just use SMTP.
| zaik wrote:
| Thus DeltaChat was born.
| bullen wrote:
| 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 wrote:
| It's an email client that looks like a messenger. It's like
| saying "I'm not giving Thunderbird my e-mail login".
| bullen wrote:
| Sure, but yes I'm not giving Thunderbird my login.
|
| SMTP and HTTP... everything else is crap.
| zokier wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| And have supercomputers in our pockets because you need 554
| different apps that serve the same purpose? No thanks.
| aliqot wrote:
| which set of RFC's is "xmpp"
| matthews2 wrote:
| 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 wrote:
| See? It's stone soup.
| zaik wrote:
| That's probably also the reason TCP failed to catch on: htt
| ps://en.m.wikipedia.org/wiki/Transmission_Control_Protoco..
| .
| cdaringe wrote:
| I don't get it. Is this a zing!
| kitkat_new wrote:
| > Any protocols or practices that already exist in this space:
|
| I wonder why they haven't mentioned the Matrix protocol there.
| zaik wrote:
| 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 wrote:
| matrix.org is interested in standardising, see https://mailar
| chive.ietf.org/arch/msg/mimi/jvyvyJwgUhNgFyNYm...
| kitkat_new wrote:
| It is already standardized: https://spec.matrix.org/latest/
___________________________________________________________________
(page generated 2022-11-01 23:02 UTC)