This would be great. I remember using pidgin back in the day and it was really convenient to have every messaging app in one interface.
Of course, some platforms ban you for using alternate clients.
Nice!
> Of course, some platforms ban you for using alternate clients.
Less nice... Doesn't seem like that list outlines which platforms will/could ban you either, which makes the entire list a no-go for me, and I'm sure others.
I am really loving this news, i was able to convince some of my old icq contacts back then to switch to jabber this way. And why wouldnt they if its all the same interface?
https://bugs.otr.im/otrv4/otrv4
The interface for Pidgin is exactly the same as it was back then (it still uses GTK2), modern users have much different interface tastes in 2022, so you might find it difficult to convince people to use Pidgin.
Who will be decrypting WA and Signal message to pass them to Facebook Messanger?
I don't think this is to be interpreted as "from now I need to be able to send messages from a Whatsapp client to a Signal client"
Of course any such app would be able to read all the messages in the clear and would be able to store them in the clear, leak them, sell them or whatever. As with any other case in which you choose to use a chat app you have to trust the chat app to read your messages if it wants to
I imagine if that's the case whatsapp or signal, when you do a first login from a different app, will flash a warning that you're using a third party client which might not be trustworthy
Even though it may not be the EU’s overtly stated main goal, it is nevertheless a goal of many aligned politicians there, and no doubt the perception among foolish politicians and bureaucrats that it will achieve that goal can account for some of their support, and if they don’t get what they want they will “fix” it until they do.
Actually I expect the usual outrage about limiting innovation or threats to leave the EU but consider that this interoperability is also a moat especially if they agree on some complicated protocol with no previous implementation.
And if they are deliberately breaking existing third-party apps for no reason, well I'm sure EU courts would like to have a word.
Moxie is strongly against it. Although the app and protocols are open, he doesn't tolerate third party clients on Signal official servers and he doesn't want federation. Even though I disagree, he has some good arguments.
And if WhatsApp has to interoperate, why not Signal?
I'm not sure what the current market cap for Signal is, but I'm fairly sure they don't have a turnover of 7+bn in the EU.
It is also one of these weird non-profit + for-profit company mix, to which I don't know the effect it has. Anyways, the numbers are simply not there.
Ironically, if the law works as intended, making all major messaging platforms interoperable, if can make smaller players who don't want to join the club (like Signal) less attractive.
Doing it by money seems like sour grapes. You succeeded in the free market so we’re going to hamper your progress.
(a) somewhat tricky to define with legislative-grade rigour, and much more importantly:
(b) only measurable by the very same entities who would be subject to this regulation
Were it not for the problem of measurement, I would agree that it would be a better proxy for "needs regulation" than market cap.
EDIT: On second thought, I don't even think that's true. Imagine a networking app that absolutely dominates a small but highly profitable and societally / strategically important sector, such as medicine or law.
That company could have relatively few users as a % of the population, but still have enough of a warchest to hobble most potential competitors, and to have undue influence in wider society thanks to its control of critical sectors. Going by market cap doesn't measure a company's pervasiveness, but it measures its sheer economic power.
makes no sense. you can already pull all your data out of those services and import it into whatever other service you want.
I mean, that's theoretically possible, but it's not the most convenient workflow, and you run the risk that any tooling designed to automate it is frequently broken by deliberately incompatible changes made by Facebook or Twitter (or whichever other services you are using, in the general case).
Fundamentally the data belongs to the users, not to the platforms, so it is right that governments mandate that the data be able to flow according to the users' wishes. All property rights are legal fictions, especially "intellectual property" rights, but at least in this case the property right being defined is a socially beneficial one.
The way i read it, they're calling for open standards, which can be a good thing.
Sadly, open standards also slow down the development of new features, as everybody needs to be "on board" for new features to roll out. Take email (SMTP, IMAP, etc) as an example, where no major progress has been made in 25+ years, despite the platform being hopelessly insecure.
There has been some unsuccesful attempts at security, like PGP and Protonmail/Tutanota, but as they're addons they haven't seen widespread adoption.
Feel free to replace email for TCPv4/v6. The only successful open standard i can think of would be HTTP.
Open standards, once they mature, usually mean "lowest common denominator".
It's a big thing. And it's a great thing.
Already in email you have some cool features that only work Gmail to Gmail but you can still send basic emails to people outside of Gmail.
Businesses will not need business accounts on 6 different platforms just so thay can have a simple chat with all their customers.
It was my understanding that we already have a (fairly old) standard that does just that, which also currently works as a lowest common denominator for texting between at least android and iOS.
In GSM it’s a IMEI ID / phone number, in TCP/IP it’s a MAC/IP address. Internet also requires a subscription, subscriber and more.
And how would you implement a messaging service with “anonymous” endpoints ? Can’t send messages without a unique identifier for the recipient.
Only some "2fa" and notification systems use them. Actual people don't.
On one hand, that is not right: open standards mean no walled garden, rather than each garden equally ugly.
On the other hand, that is exactly the point: no new feature can be used to buy the users' freedom to interact with customers of other services.
The problems were that:
- unlike modern compiled code for the web - WASM and transpiled JavaScript - Java and ActiveX got executed with host privileges which made both an incredible entry point for malware such as "dialers" and early viruses.
- many corporations and governments (e.g. Korea [1]) built their stuff in ActiveX or mandated its use in actual laws and regulations, while only MS Internet Explorer ever implemented ActiveX out of said security reasons.
- many corporations and governments only ever coded and tested against IE6 which meant that their sites and products were dependent on IE6-specific quirks
[1] https://www.forbes.com/sites/elaineramirez/2016/11/30/south-...
so the point is a degraded experience? how can that be the point?
Nothing prevents people from releasing a new RFC describing their feature and how to implement it. See: EMail attachments (RFC 1521) which came after the original EMail definition (in RFC 822). And what you describe as "email insecurity" is just a common disagreement which encryption method to use in your MIME attachment (defined in RFC 989) - your argument sounds a bit like protesting that not everyone is using Word files when sending text attachments.
(Note: EMail metadata is deeply "insecure" and can theoretically be used to glean information about communication - but if that's your concern, maybe email is just the wrong format for you and something like encrypted messages over a network of Kafka-style message streams, ideally with lots of noise in it, would be better suited).
How long before the instant message formats of today becomes “the wrong format” ?
Email is an open standard, and as such it should be easy to push out a new RFC that secures metadata, yet that hasn’t happened in 25+ years.
I essentially agree that communication should be done over open, secure standards, but I’m not sure legislation is the right way of getting there. We will see how it all plays out.
Capability negotiation is a thing. It's perfectly fine to support some baseline feature set (one-to-one text messages) and build more optional features on top of it. But, yes, it's important that the protocol is designed to be extensible in the first place.
So keep the status quo (SMS/MMS) and build more features on top of that ?
There are countries that aren't the US. I honestly don't remember when was the last time I've actually sent an SMS. 99% of SMS messages I receive are notifications and 2fa codes. If anything, "status quo" over here is Telegram and VKontakte.
Besides, the issue with SMS/MMS is that it's a closed system tightly controlled by carriers. The internet is an open system.
what you are describing can be called "iMessage" :)
and this is just one small reason why the industry decided against moving forward with this decades ago. it simply didn't make any sense then, certainly doesn't make sense now.
Uhhh yes? That's the point? The alternative to this degraded experience is no experience at all.
so basically it's either degraded experience but w/ interoperability or great experience but w/o interoperability?
that doesn't really make sense. why not a third way with great experience and great interoperability?
i'm asking because i can guarantee that no one will use clients that provide a degraded experience when you've got the established players providing a great experience.
Somehow, ICQ worked wonderfully despite everyone I knew using an unofficial client. The official client (at least Windows one) was a terrible mess. It had ads and all those features no one ever asked for, like games and and news and an entire picture-based language (I'm not joking). But QIP, the client I used, only did the things I needed an ICQ client to do, and nothing more. It also had no ads.
The answer to that is: It depends.
For example, HTTP2 is basically an invisible upgrade which is faster (sometimes). If either end doesn't support it, falling back to a prior version is transparent to the user.
On the other hand, if you want to update IRC to be more like Slack/Discord, with features like oauth2 login? Well then clients that don't support it won't be able to connect.
--------
This is what my group chats look like when texting with iMessage users.
Group chats over SMS? What kind of madness is that?
Other than that, it can be death by a thousand cuts. If the rendering of a particular phrase relies on a specific custom feature, the other side might not see it properly. That can be multiplied by many times and make people frustrated, and worse, misunderstand each other.
A more successful example of open standards would be the various standards that browsers use. Would you say that browser innovation has slowed down? The model adopted there is less "Wait for everyone to adopt this new standard we wrote" and more "If you have a feature you found many people are using, suggest it as a standard and we'll get all browsers to implement it".
This model could be replicated to messaging solutions as well, without slowing down any innovation as companies can add new features, as long as they get standardized over time.
For a long time it was, everyone was stuck on HTML4 while W3C was playing with XHTML. That only really changed when browser vendors came together and collectively decided to ignore start ignoring W3C and made WhatWG. Although IE6 was also a major factor here.
Messaging apps have evolved in very pro-user ways over the years. Reactions, threads, voice/video/screenshare, and more are all popular with users. Stuff that we didn't have at all in the AIM era, or maybe only had on one chat platform.
And under the hood, I read that an important reason everyone left XMPP is it fundamentally requires an active connection, but that means your phone's radio can never enter low power mode, hurting battery life.
I miss Pidgin. I really liked having all my chats in one place. I sort of have that now with Beeper.
But it's also clear that we're not done evolving the medium, and standardized protocols, for all their upsides, often crystalize a platform in whatever state it's in when the standard is written.
This problem has been solved by https://xmpp.org/extensions/xep-0352.html
Glad to see it's being addressed, but:
- The proposal is stable, but not finalized
- 13 years is a long time to wait for a solution (iPhone debuted in 2007, got apps in 2008)
- Plus however long it takes for implementations to adopt this
- Plus whether they adopt it at all, since this is a protocol extension and not a protocol requirement. The XEP requires client-server cooperation, which means the clients and all servers the user connects to have to implement this to see the benefit.
Is "stable" now a negative thing? I don't understand. If you are referring to the "document lifecycle" at the side of the XEP, and the "Final" status there... "Stable" is the "widespread adoption" stage. "Final" is a dead-end status that means the extension is frozen. It's rarely used for extensions that are actively in use until they are beyond updating.
> "13 years is a long time to wait for a solution (iPhone debuted in 2007, got apps in 2008)"
This extension was created in 2014, and implementations were already performing traffic optimizations (using other non-standard methods) before then (which is why we decided to standardize it).
> "Plus however long it takes for implementations to adopt this"
It's already adopted, implemented and deployed. You can see deployment stats at https://compliance.conversations.im/test/xep0352 - as for the handful of servers there that don't implement it, on investigation these tend to be private, abandoned or special-purpose servers.
> "Plus whether they adopt it at all, since this is a protocol extension and not a protocol requirement. The XEP requires client-server cooperation, which means the clients and all servers the user connects to have to implement this to see the benefit."
As I said, it's already implemented and adopted in clients and servers. It has been a requirement in the XMPP compliance suites for years (for reference, latest is here: https://xmpp.org/extensions/xep-0459.html#mobile ).
All in all, your comment seems to contain a lot of unfounded scepticism and negativity. This problem is solved, since a long time :)
The XEP page indicates the proposal is still subject to change ("some changes to the protocol are possible before it becomes a Final Standard.)". That kind of thing sometimes holds up adoption of standards, creates incompatible implementations. But you've demonstrated it clearly doesn't in this case.
> This problem is solved, since a long time :)
I stand corrected! Thank you for your instructive reply.
Email is a totally different problem because it's a suite of a multitude of different standards used across countless different platforms. At least with proprietary messaging services Facebook et al will still be the implementation standard that most people will use (given that habit has already been well established) but lesser used 3rd party clients wont have to worry as much about Facebook breaking the protocol to intentionally break support for 3rd party clients. However I'd wager you will still see new proprietary features added that will not function in 3rd party clients if just to convince users that the 1st party app is the better client.
Btw, does anyone here remember off hand what happened to the "concern" the banking industry had with TLS 1.3?
My understanding is someone just came in at the last moment and basically wanted to change the entire design of TLS 1.3 because their workflow would no longer work because of forward secrecy.
So if I'm whatsapp I have to allow third party clients, but I can also change my API as needs change, as long as I don't lock it.
Close standards is not inherently different (people who work in telecom can likely attest to that), but closed standards has a higher probability to be owned by a single entity. A single entity has a much easier time to coordinated a switch with themselves, or align their own incentives with their own incentives. If you are alone or don't need to work with others, cooperation is trivial. Obviously, having everything owned by the same entity also has its drawback. If you don't like the new price, features, tracking and forced advertisements, well tough luck. While spam is an issue with email, I am not forced to wait 3 seconds and click "skip add" every time I read an email. I also don't need to pay per email, in contrast to sms. Email could had been much worse if it was a closed standard owned by a single entity.
The usual answer for avoiding the need for everybody being "on board" with the changes is capability negotiation. Unfortunately, that doesn't work for email since it's a unidirectional, store-and-forward protocol: the sender has no way to negotiate capabilities with the recipient (or recipients, in case of a mailing list). If for instance I invent a new rich-text format for email, I have to include a fallback format on every message, since I cannot know whether the recipient can read my new format.
> Feel free to replace email for TCPv4/v6.
With TCP, there's another issue: middleboxes. While TCP does have working capability negotiation, unrelated third parties (which were not part of the negotiation) interfere with things they don't understand. If for instance I introduce a new TCP option which when negotiated changes the meaning of the sequence number field, a stateful firewall would drop the data packets even though they're valid for both endpoints. Due to the large amount of middleboxes in the wild, the design of TCP has been effectively "frozen", in that any enhancement will break unexpectedly for a large subset of users.
> The only successful open standard i can think of would be HTTP.
What saved HTTP was SSL/TLS. By making it hard for middleboxes to interfere without actually acting as an endpoint (with negotiation), it allowed the protocol to evolve. The best example is HTTP2: while there is a cleartext version of HTTP2, nobody uses it because it would get broken by middleboxes.
No. They are asking for endpoints and public APIs. Nobody is forced to adopt a standard, that is a fallacy you have just built (and has powered a tangential thread of 20 messages and counting.. debating something that is not in the topic).
Services will be forced to provide public endpoints and public APIs. Nobody is forcing them to shape them in any way. Consumers can decide to interface with them, or not. The onus on implementing and interfacing with them lays on the consumers. You don't need an agreement between everybody.
But lets say you are right, and all that the affected messaging services have to do is provide an API- will the regulators require them to document this API (and if so, what standards will the documentation have to follow?) Will they complain if the API changes too rapidly? Will the API have to support tall of the same features as the messaging service?
As they say, the devils in the details, and right now I'm not seeing any details.
How will they interface with the different APIs ? Or is it a single API defined by a standard ?
The first one means that most clients will play “whack a mole” with 20 APIs, trying to keep up with features. The second will be the lowest common denominator, limiting what can be sent between different clients. It would be the new “green bubble”.
Next, how do you identify people uniquely across different networks ? Phone number ? Email ? What happens if you’ve registered your Id in multiple places ? Or is it up to the sender to specify which network they wish to target ? Like someone@gmail.com@imessage ? The last one solves nothing. In case of multiple id registrations, should the network just keep trying round robin until it successfully delivers ? Or can I as a recipient register my preferred delivery network in case I never want Meta or Google to see my data ? Who maintains this central registry ? Will they do it for free ?
Now that we’ve established how to pass messages between networks, how do we secure them ? Do we use the iMessage model and use a central key repository ? Or do we implement a protocol (potentially per API) on how to acquire encryption keys ? Or do we simply skip encryption because security is hard ?
What about attachments ? Since most secure platforms use “per device” encryption, do we just send a 500GB attachment X times, one per device ? Do we limit the size of attachments ? iMessage solves this by encrypting it with a temporary key, and the attachment is then uploaded to Apples servers, and the temporary key is exchanged using normal messaging. Is that the way forward ? Will whoever handles it do it for free ? Do we trust them ?
What about Memoji/whatever the kids use ?
All of the above, and more, needs to be agreed on by all involved parties, which sets the lowest common denominator, either by a shared standard, or by reducing functionality for cross network messages. If it ends up complex enough to support all the features of modern instant messaging, it sets the bar rather high for new players. If it ends up simple, we have gained almost nothing over using SMS/MMS.
Things are never as simple as just exposing an API.
If you want to solve all those problems, you can use and push for Matrix for example.
It applying only to ~7 billion capitalization only increases the chance that somebody uses their network, and as is already evident today, that is where the majority of conversations happen. It also increases the risk that my messages will be routed to somebody I don’t want poking through my messages, even if it’s metadata only, like Meta and Google.
It also increases the risk that I have registered the same ID with multiple providers.
I am not interested in solving the problem, and especially not interested in using Matrix. My only interest in this is I want to have functional instant messaging between people I know. Matrix does not solve that (for me).
My point was/is, that either the legislation solves nothing (open APIs, native “own network only” clients), or it creates a lot of problems (unified API, shared standard, cross platform messaging for all).
Also, imagine the spam you’ll receive if every email you’ve ever registered with some ~7 billion provider suddenly routes messages.
Stop repeating this talking point of big tech. This is FUD. Sure, developing the standard further requires more work and is slower if just one person alone developed it, but the upsides clearly overweigh.
Furthemore, everonye is free to build their own features in their own app that are not part of an open protocol (good examples are snooze or send later features in email).
PS: As a sister comment pointed out, open standard is not even in the scope of this new EU act. It's only about opening up their APIs. They are not foced to use an open protocol.