"Messaging isn't rocket science. After all the engineering effort, it's not like these proprietary IM networks were doing much innovating. In the end, they were all just re-inventing the same IM wheel—sending text, images and files with a new interface."



"Messaging isn't complicated. We solved this more than a decade ago. It's sending text, emojis and photos, perhaps to a group, ideally with end-to-end encryption. You have five incompatible messaging apps on your phone not from technical limitations, but because greed drives companies to ignore compatibility and optimize for vendor lock-in. Imagine having five different web browsers you had to switch between depending on which website you wanted to visit."

@alcinnz A funny and loosely related thing here: a surprising amount of (non-technical) computer users really *do* use different browsers for different websites! As far as I can tell, that's mostly meant as an ad-hoc way to have separate 'profiles'/'workspaces'.

(haven't read the article, responding only to a quote, please let me know if the author addressed it elsewhere in the article, but)

There are many design decisions not mentioned here:
1. should there be user presence/status? If so, how fine-grained?
2. should messages sent to offline users be delivered asynchronously? if so, how much of them should the server store, and for how long a time?
3. if there is an archive, where should it be kept? on the server or on the client? if on the server, how much space to allow for it?

Once you have groups, it gets even more complicated, there are more choices, and the tradeoffs are less obvious.

And I didn't even get to the "ability to send pictures is inducing non-constructive behaviour in people, and therefore they shouldn't be allowed to send pictures" type of arguments.

@Wolf480pl It didn't address these points, but I think the points it was making is entirely seperate.

It's complaints was with these being centralized services with (typically) proprietary protocols, but in making that point it understated the design space.

It would make sense to me for there to be multiple protocols which are bridged where desired, as long they're all open standards.

I think the "people want this feature but it's harmful to them" type of arguments affect the proprietary vs open standard angle too.

If such features indeed exist, obviously the proprietary IMs would be first to incorporate them. This would make it difficult for open alternatives to compete with them, because if they strive to make the best tool possible (which I think is natural for open standards / FOSS to do), they'd need to exclude such features, and people would use that as a reason to use proprietary IMs instead. OTOH, including such features would reproduce the negative effects on communication associated with proprietary IMs.

@Wolf480pl I don't have a good solution to this problem.

All I can say is that I want The Web Platform to be less "featureful", and to show people this can actually lead The Web to be MORE featureful. And as part of that IM (and certainly video chat) for example should be a seperate app that can be triggered by links on a webpage.

Sign in to participate in the conversation

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).