[albertzeyer]

The EU is planning to require big online messaging services to be interoperable.

https://www.theverge.com/2022/3/24/22995431/european-union-d...

This would solve it. Then you could simply use a single app.

This is a political thing. So, vote for it, talk to the politicians.

[nickjj]

Ah, history is mostly repeating itself (minus the need for government intervention ~20 years ago).

We had similar issues in the late 90s / early 2000s with ICQ, MSN Messenger, AIM, Yahoo Chat, etc..

Apps like https://www.pidgin.im/ existed to let you check everything within 1 app because all of these apps spoke the same protocol or close enough that things mostly worked.

[albertzeyer]

This is a bit different though.

It's one thing to allow independent applications to use the protocol and service, like Pidgin and others. And also many services did not like this and repeatedly changed their proprietary custom protocol to make this difficult.

It's another thing to be interoperable between services. Then you could continue to use only one service but still be able to talk to people on other services.

[nickjj]

Yeah that's true, in the Pidgin case you were still signing up for each service independently. Pidgin let you communicate through its app instead of the service provider's app. None of the service providers had data about the others.

I'm not sure how they plan to make things fully interoperable. Wouldn't that mean every chat app would need a complete chat history for every user multiplied by every chat app out there? Or instead they introduce a shared parent company / govt. entity where all chat messages are sent through, stored and pushed to users. Time to bust out the tin foil hats!

[Cerium]

I think you could make it work with only some username namespace. Eg: whatsapp.cerium vs fb.cerium. Facebook would forward messages to whatsapp usernames and vice versa.

[endisneigh]

I don't see how this is possible if you also have E2EE. Great example is email encryption via PGP. It exists, it's used (rarely) in some cases, but it's so poorly implemented to the point of being useless unless

[AndersSandvik]

It will be possible because the user will have the encryption key

[chrismorgan]

On the contrary, genuine end-to-end encryption is only possible this way. First-party end-to-end encryption is broken by design. (I’ve explained somewhat more with particular examples in a few comments: https://hn.algolia.com/?query=chrismorgan+end-to-end+encrypt....)

To be sure, interoperability requires a suitable spec for other clients to implement, but there’s absolutely nothing special about end-to-end encryption in this picture—it’s just a feature to implement like any other.

[endisneigh]

tell me then, how exactly would this work as new features are developed - do all apps have to be static in functionality indefinitely? how would it work with group chats where you can add and remove people arbitrarily?

[karpierz]

> tell me then, how exactly would this work as new features are developed - do all apps have to be static in functionality indefinitely?

Can you give an example of a "new feature" that you think would be stymied by this?

> how would it work with group chats where you can add and remove people arbitrarily?

I don't quite understand what issue you're pointing to. I'm not sure if you're unsure of how e2e encryption works or something else. Can you ask your question again with more specificity?

[endisneigh]

Sending money for example.

Haven’t kept up to date with matrix - does it even allow e2ee with group chats using a bridge?

[karpierz]

Why would requiring interoperability of messages or video calls prevent an app from implementing a "send money" feature?

Also, if you want to make a "send money" feature, why would it being interoperable preclude you from doing it? Bank transfers are already interoperable, why can't a send money feature be?

> e2ee with group chats

See: https://interoperability.news/2022/03/end-to-end-encrypted-g...

[chrismorgan]

Ah, I see the issue you’re going for now: feature evolution. Certainly that’s the trickiest part of the scheme. I still wouldn’t say end-to-end encryption is special here; certainly it’s likely to be a more intrusive update than most, but if introducing it late you’d still handle it the same way as any other, most likely as an optional feature for a certain period of time, after which incompatible clients can no longer connect.

[capableweb]

The way to achieve interoperability while still being able to innovate is to follow the model of browsers (HTML, CSS and JavaScript). The process works something like this:

1. Everyone has the same basic functionality, you can switch between browsers and (mostly) everything works the same way, renders the same way and so on

2. Browser XYZ decides they want a cool feature where they expose data from a fingerprint reader as a JS API

3. Browser XYZ implements said feature and sees if websites starts using it.

4. Standards-bodies might start noticing that the feature was implemented in Browser XYZ and keeps an eye on it

5. If a second browser implements a similar/the same feature (although slightly different API or other incompatibility), standards bodies starts working on creating a standard for said feature, together with Browser XYZ and the others who participate in the standards organization

6. Once standard is done, reviewed and published, the browsers who want to have the feature go back and adjust/add/remove things until they comply with the standard.

Obviously, it's not exactly like this, but the process is more or less like this.

It's not hard to imagine the same for messaging services. The base-layer is that everyone can send text messages to everyone. This we can all agree on, so a standard would be for that first.

Then if some messaging service wants to add a new feature, they start working on that and deploying it for their service. If a second messaging service deploys the same feature, standard bodies should work on getting a interoperable model of that feature, that then all messaging services can use and hence work across all of them.

[endisneigh]

It’s funny you mention browsers because there are a ton of sites and features that only work on chrome and not safari.

Not sure that’s the model to follow. Fundamentally though chat is different - where would the messages be stored for example? Who will guarantee deliver ability?

Email is federated and has all of these things but sucks and so everyone made their own thing. I’ve yet to see evidence this just wouldn’t regress to email again

[capableweb]

> It’s funny you mention browsers because there are a ton of sites and features that only work on chrome and not safari.

Is that because Safari doesn't implement everything decided by the standards bodies or because Chrome deploys their own features? Probably a mix of both, but eventually there is a convergence.

Things work surprisingly well in modern times. I'm not sure when you started using the web, but back in the 90s/early 00s, the situation was a lot worse then it was today, and the browser standards are probably the biggest collaborative achievement between corporate entities in the modern web-driven world.

> Not sure that’s the model to follow. Fundamentally though chat is different - where would the messages be stored for example? Who will guarantee deliver ability?

It might seem fundamentally different on the surface, but I think not. Just like the browsers doesn't handle where the resources it loads are coming from, messaging services can be the same way. Think IRC, or even your own example, email. As long as there is a user-agent where services look consistent, the situation would be drastically improved.

> Email is federated and has all of these things but sucks and so everyone made their own thing. I’ve yet to see evidence this just wouldn’t regress to email again

Email is another great example of a success when it comes to this. Yes, email has it's warts, but you can essentially sign up for any provider, or even create your own, and receive/send emails to any of the others ones.

I don't see "email" as a regression compared the IM situation we have today. Imagine you would need a gmail account to send emails to gmail users, yahoo account to send emails to yahoo users. That would be awful! But you're right that email could be a lot better, but still, I prefer it to the alternatives from the IM world.

[dingleberry420]

Why should this be an issue at all? It's my account, I should know the encryption key & algorithm. Any open source app can then implement this.

[endisneigh]

How exactly would you implement an interoperable E2EE group chat app where you can arbitrarily add and remove people like with iMessage?

The EU law linked does not actually recommend anything specifically, just vaguely states interoperability being a goal.

Certain apps will have certain functionality. Unless you're willing to constrain the functionality it's not really possible.

Right now everyone could already use email which supports encryption. They don't, though.

[vageli]

> How exactly would you implement an interoperable E2EE group chat app where you can arbitrarily add and remove people like with iMessage?

Doesn't the matrix chat app allow for this? Might be useful to learn how they do it if this is of interest.

https://matrix.org/docs/guides/end-to-end-encryption-impleme...

[dingleberry420]

The same way as they're doing it right now, just well-documented and open. Let the bigcrops create working groups to hammer out the details.

[OJFord]

How is the problem you're imagining solved by having just a single company in charge of the app?

[endisneigh]

It’s not - the company usually also has the keys, so you have to trust them.

[OJFord]

If you call that E2EE then all E is.

[t-3]

Wouldn't that basically set protocols in stone and block any future improvement or research? Standards are generally good, but I can't see legally mandated protocols as anything but guaranteed ossification.

[bhawks]

Why is this a 'political thing'?

Did I miss the campaign to define SQL? Of the one to specify the x86 ISA? Perhaps they should merge the arm and x86 architectures, they're both CPUs right?

This feels very far away from a 'political thing'.

[loudmax]

Politicians shouldn't be in charge of defining interoperability standards. But politicians can mandate that companies be interoperable.

Regulation is hard. This doesn't mean that rules shouldn't exist.

[bhawks]

Just because they can doesn't mean they should.

Should they mandate that video game platforms be interoperable? What about mandating that every company produces apps that interoperate with windows Mac Linux and mobile.

[albertzeyer]

Difficult question indeed. And that even leaving aside the technical questions.

But wouldn't it be nice? Netflix, Amazon, Apple, Disney, all together? Or always cross platform apps? Is there any real benefit for the user that they are not interoperable?

[bhawks]

Saying wouldn't it be nice without proposing how such a scheme would work without picking winners and losers is naive. The devil is in the details as they say.

Ubitiquious cross platform apps, sure! Just 3x your development team size - will your app still make sense to make with those costs? Oh don't worry - just replatform to a cross platform toolkit (and stop working on new features for 6-12months and retrain the entire team).

I just don't see why it's worth bringing the blunt hammer of government intervention here - let alone a reasonable path for regulation implementation.

[dingleberry420]

It'd be more likely they'd mandate Mac, Linux and Mobile to all support a common app format. Which they already kind of do, the web.

[brightball]

Honestly, those apps should just expose themselves via email and be done with it.