[hackuser]

Why are messages separated by transport? That is, why are messages sent to/from me via one transport (e.g., SMTP) read and composed in one application, and those sent via another transport (e.g., SMS, Twitter) read and composed in another? Why, as a user, do I give %#@%! what the underlying transport is?

I think the focus on a particular technology (SMTP) rather than a service (messaging) is why email clients don't advance. Bizarrely, three other transports often are integrated into email clients: NNTP, voicemail, and fax. I can only guess that it's because of a completely arbitrary reason: They are older.

Probably chat clients should also be integrated. I should be able to send my contacts an instant or time-shifted message.

[aetherson]

Because the different transports have vastly different abilities and limitations that are a source of frustration if you attempt to obfuscate the differences between them and aren't served by a unified UI?

[hackuser]

Could you be more specific? For example, comparing SMS and SMTP, the two most prominent transports?

[zombition]

SMS is used to send tiny chunks of text, and SMTP can be used to send message content in HTML format and rich text in addition to plaintext. I haven't worked much with rich text format, but HTML format for sure would be relatively impractical via SMS (XML adds a lot of characters, so you would have a lot of little chunks to send if you wanted to send HTML over SMS).

[hackuser]

I agree with that. I don't mean that I want to send my email messages visa SMS. I mean that I want all my messages sent/received and read in one messaging client, whether they are transported via SMS, SMTP, etc. If the HTML message should go via SMTP, I expect my software to deal with that. I want the content; the transport is an obscure detail for developers to worry about (speaking as a typical end user).

[toomuchtodo]

You're asking for a magic genie content router that does not exist. It does not exist because its a hard problem. Not only would you need to interoperate with open standards, you'd have to attempt to integrate with unwilling participants (Facebook, Google Hangouts). Are you prepared for that level of pain?

[Ntrails]

You also have to consider that facebook already do this. They tried to wrap up email, messages and an SMS replacement on your phone into a single package where they own the whole thing.

I look at iMessage and I think it works pretty perfectly, SMS when no internet or to a non apple user, iMessage whenever possible. What I want is for whatsapp (and I suppose facebook and plausibly email) to do the same all in my single messenger application.

But. Ignoring the need to get the tech owners to consent to this new "trillian", I'd also have to trust the app itself. Good luck making money on that.

[zAy0LfpBZLC8mAC]

Well, if you want that, then you should support open protocols. The business goal of twitter, facebook, etc. is to lock you into their communication system, so if you expect developers to integrate those, you really expect them to invest into integrating with those who want to destroy the open ecosystem that they rely on and who will do whatever they can to hinder the integration.

[marssaxman]

I'm really glad email doesn't change quickly. It works, and there's nothing really wrong with it.

[drumdance]

Sending is easy. Receiving and sorting and filtering is harder.

[hackuser]

> Sending is easy. Receiving and sorting and filtering is harder.

I don't understand: Receiving messages on any of the transports is done every day and billions of platforms. After receiving, loading the messages into a common database, including mapping metadata such as sender, date, etc., seems relatively simple. Once in the database, sorting and filtering are simple.

What am I missing?

[zombition]

> Why, as a user, do I give %#@%! what the underlying transport is? > I don't understand: Receiving messages on any of the transports is done every day and billions of platforms. After receiving, loading the messages into a common database, including mapping metadata such as sender, date, etc., seems relatively simple. Once in the database, sorting and filtering are simple.

I agree with this completely--so much so that I decided to make my own communication protocol (and client-server implementation) that would do whatever I wanted and still be backwards compatible with email. You can see the results here: https://github.com/Zombition/nsmtp-monolith. So clearly it's not impossible.

> What am I missing?

The biggest difficulty isn't from pulling out metadata and mapping it to whatever you store locally. The specifications of different protocols determine the user behaviors that are possible with each protocol, and mapping behaviors between different protocols in a way that makes sense to end users is much more difficult if you want to retain quality communication with users who are not using your software to pull everything into one place. What I found from implementing a new protocol that aimed to be backwards compatible with SMTP was that maintaining backwards compatibility with SMTP guided 99% of my decisions for making the new protocol. If I wanted to add a feature, but it would be confusing for end users who might be trying to communicate with regular SMTP users (or the SMTP users that they were trying to communicate with), the only practical solution is to axe the feature or rehash it in a way that would be less confusing for communication between the two.

In practice this is quite difficult, because you have to balance awareness of both protocols with awareness of how data sent through one can be meaningfully translated to the other, and while you're considering those things, you also have to consider what the user experience is going to be like for people on both ends of the software. If you're trying to maintain compatibility with a widespread protocol like SMTP, there may be an enormous number of different client interfaces that can add a significant amount of variation to the user experience. It's a bit like unfolding a fractal.

[baudehlo]

Spam, generally.

Because email uniquely among communication protocols allows sending a message without any previous agreement from the recipient, will always be susceptible to spam (and getting rid of that feature would destroy emails benefits).

Plus people want to filter differently. People deal with their inboxes uniquely.

[hackuser]

Why can't the universal mail client I propose have a spam filter? More likely, my incoming mail server will have the spam filter; the client will have the spam folder. What does it matter if only SMTP messages end up in that folder?

> Plus people want to filter differently. People deal with their inboxes uniquely.

That issue affects every messaging client's filtering. How does it affect a client any differently if it combines, for example, SMTP and SMS?

[baudehlo]

Oh you absolutely can, but there are a mix of problems some of which makes spam filtering better on the server (knowing bad sources of email, like infected desktop machines), some of which makes filtering better on the client (like knowing your users' preferences for what they consider spam).

There's a huge long history of very smart people (not even including myself in that list - I've worked with some people MUCH smarter than myself on this) working on this problem, including the very creator of this site, pg himself, and even he doesn't consider this a solved problem. People are still paid well to combat spam every day on behalf of demanding customers (and I'm grateful I'm not one of them any more) and it will always require new techniques and new input. Hopefully you will contribute too.

[baudehlo]

Oh and in terms of the other question: how many people get enough SMS messages that they want to filter them? Filtering is uniquely suited to a non realtime messaging system. Like email. I don't want to filter Slack/IRC messages either. I just ignore what I didn't read.