[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.

[endisneigh]

My point is that email basically hasn't evolved meaningfully from the 80s and other than the main feature of sending text all of the functionality is locked between specific providers. Tags vs. folders vs. labels, chat without email, encryption, etc. Nothing other than the baseline functionality is standardized.

[t-3]

Nothing other than baseline functionality should be standardized. Client features are totally irrelevant to the goal of sending and receiving messages.