[jasonzemos]

> messaging apps are all the same, making them easy targets for standardization and interoperability.

This is patently false. Look no further than the other comments in this thread. Nobody can agree on what they want out of the messaging experience. Some want a rich experience like telegram and others want a minimal one like IRC. Should this protocol's features maintain parity with the proprietary and centralized services? Better develop them rapidly to keep up. Should they stagnate to maintain interoperability across an ecosystem? Good luck being competitive. We haven't even gotten to the features themselves and I promise you there will be irreconcilable differences. Does the protocol maintain message history or is it ephemeral? What is the privacy model? Can we delete messages on other servers due to GDPR? When you spend time at the business end of the messaging space, these dichotomies flow endlessly, without consensus, and they cover the entire horizon of the space.

If you think you know the answers to these questions, you don't, because you're solving the wrong problem. If you want to decentralize messaging you have to solve the problem of how to agree to disagree while maintaining interoperability for a shared experience. Let me just make that last point clear: you cannot design a messaging protocol where one party sees emojis and the other doesn't. That doesn't work because you can't lose social information.

Matrix has failed to solve this problem. We need a new approach. What will emerge to finally conquer this space?

[johnmorrison]

I feel like you're overestimating the differentiation and not accounting for the fact that 99% of the population basically just uses the minimal subset of features (sending plain text and images)

Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability, if you can send most of your messages across platforms, that's still pretty good.

> Let me just make that last point clear: you cannot design a messaging protocol where one party sees emojis and the other doesn't.

Which service doesn't show emojis? Literally every mainstream mobile operating system and desktop browser supports emojis as regular text.

[jasonzemos]

> the fact that 99% of the population basically just uses the minimal subset of features

The tendency is for people to invoke features situationally. If you are communicating with someone who is using rich-replies there is a tendency to also invoke that feature yourself. If people are using emojicons there is a tendency for others to play along rather than use plaintext characters. Feature invocation is situational and relative.

> Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability, if you can send most of your messages across platforms, that's still pretty good.

This has proven to result in an unacceptable user experience throughout the history of messaging. When a system loses social information from the environment it is no longer an effective communication tool. Worse, it is dangerous. If you send me a message and I respond to your message with some thumbs-up emoji, and your platform doesn't support it (e.g. a text-based IRC client) that information gets lost. You believe I have disregarded your message. You may assume I have been rude when the opposite is true. This is absolutely unacceptable UX.

[johnmorrison]

> This has proven to result in an unacceptable user experience... Worse, it is dangerous. If you send me a message and I respond to your message with some thumbs-up emoji, and your platform doesn't support it ... that information gets lost. You believe I have disregarded your message. You may assume I have been rude when the opposite is true. This is absolutely unacceptable UX.

This is an assumption that bad implementation is the only possible implementation, and it is wrong.

Obviously omitting content from missing features is bad UX - but it's absolutely not necessary to interoperate. It's easy (and should be expected) to avoid this by simply telling the user something from a missing feature has been sent - they can then inquire and get back the lost information / clear up the confusion.

Furthermore if interoperability is implemented on both ends, the sender's client should know to alert the sender before they attempt to use features missing on the receiver's end.

None of this is a difficult issue.