And I won't be satisfied until Emacs can run Windows 95 binaries [1], but I'm not sure that it's either on Microsoft or on Richard Stallman to make this happen.

There is no shortage of open protocols that you can use to communicate with all your friends. I don't see that you should be able to compel application vendors, that all build on top of open protocols into any interop they don't want.

[1] Emacs is, after all, an operating system with ambitions of being a text editor.

If the problem to solve is piping an emacs buffer to a Windows 95 text mode binary and replacing the buffer with the text output, the solution could be

1. Run Windows 95 in an emulator, maybe a webassembly one.

2. Generate the mouse clicks and keyboard events to run that program, probably in a full screen DOS window. It must be in the %PATH%

3. In the same way type in the buffer in the input of the program.

4. OCR the output.

5. Replace the content of the buffer.

I think it is feasible.

Step 1 is for example https://github.com/felixrieseberg/windows95

I wouldn't be surprised that steps 2 to 4 are already implemented in some form.

Step 5 should be trivial.

> Until I can chat with all... regardless of which chat app

I should remind you that your application and their application will share your messages but may have very different privacy policies.

(Some problems will persist and still require further assessment and decision and possibly division.)

? When your message is readable on the other side, on the app which we are supposing has a "problematic" privacy policy, it is unencrypted. Encryption is a matter in transmission. The data acted upon (e.g. displayed) on the other application has to be finally unencrypted, or decrypted.

Alice sends message "Hi" to Bob through app Alpha; it is encrypted during transmission; Bob receives it on his app named Beta - but Beta manages the message in fully readable form, "'H'-'i'", and does what its coders want with it.

Hannu Rajaniemi's "The Quantum Thief" had a fun take on this, in the form of the Gevulot technology. It's a great book.

While it requires some work to setup, Matrix bridges to all major messaging platforms now.

Bridges always degrade the user experience. Chats come from the bridge user, so now you need to look for some strangely formatted header to see who sent the message, there are no avatars, formatting that might be crucial to the meaning of the message gets stripped on unsupported platforms, same for certain attachments...

Services with actual APIs, like Slack, work pretty seamlessly.

Not all bridges can do this though, its true. Still almost universally a better UX than having 10 messaging apps.

> Does the solution to your problem have to be free (as in $0), or are you willing to pay?

That's a different axis.

Solutions need to be open (interoperable) standards. That means I must have the ability to sit down and implement all of it myself and it'll interoperate with everyone else.

Whether you pay or not is separate consideration. If I implement everything myself I pay nothing other than a lot of my time. Alternatively I can pay someone else to implement it for me, or buy a pre-built solution from any number of vendors, or subscribe to a SaaS solution from other vendors.

The key is interoperability between all these. Like HTTP or SMTP.

See also: LTE, UMTS, SMS, MMS, HDMI, DisplayPort and many others.

Protocols that allow any* vendor to build a device that talks with other devices instead of demanding that you can only talk to a single brand.

That exists - XMPP.