It's actually really funny, because before I saw a lot of this hitting the news, I was working on my own home automation system, and trying to figure out a quick temporary solution to reach it from the outside world, without developing client apps.

And I thought of email. A well standardized message queuing platform that could easily implement a basic text command interface. So I ended up with a rudimentary chat bot. (I could've done SMS, but didn't want to find and pay for a service for that.)

And a few weeks before this announcement, I'd been thinking about how to handle queries to my chat bot my software didn't understand, and I was thinking "Hey, I wonder if I could have my bot ask Cortana stuff if it doesn't know". And Microsoft's picked up and really ran with this model with Bot Framework.

Obviously they've been working on this behind the scenes for a while, I'm not trying to take credit for the concept by any stretch, but I thought it was funny that I had been thinking along those lines myself before I heard about this.

Good UI isn't hard. Generally, it's simple and universally understood. I instantly understood where Microsoft was going here because I had the same thoughts. That being said, I want my system running mostly locally/self-hosted, so an Azure-based platform like Bot Framework probably won't work for my own system, though I might very well send requests to other bots using it.

Had the same thought of using email as a queue, but for playing asynchronous games. Basically play-by-email, but you give the game login access to an email account and each email has a game id and an order id and it basically treats the email like a pipe.

I felt this was one of the few ways you could insure the game could still be played in perpetuity after a company had gone away and their servers shut down, without requiring people to host a dedicated server.

Obviously this wouldn't work with real time games, and players could potentially abuse the data being sent if you're not careful and/or don't encrypt the data, but I prefer making turn-based games anyway.

Having worked for several small companies that have shut down, that's a concern to me (although you can't even download most of those games anymore since they were taken off their respective app stores).

Exactly. If you need a way to send data across a network, queue it if your partner is unavailable, ideally make sure it works on a large number of platforms out of the box... Email is already there and it works.

I found it interesting Microsoft Garage made an "IM client" that uses email in the backend recently. In some cases, I think all these new protocols we invented was reinventing the wheel, when we already had something that worked fine.

Using it for games is a really neat idea. In a plaintext format, you could even space out things like a Scrabble board, using @ and & symbols for special blanks or such, and one user could be lower case letters, and the other could use capital letters. Dots for normal blanks.

I love simple formats.

Do you really know email protocols? I don't consider them simple.

For example take a look at the RFC 5322 and try to determine what is or isn't a valid address. You have a lot of weird edge cases to take in account and it's not always obvious how you are supposed to handle them.

https://tools.ietf.org/html/rfc5322#section-3.4

If you need to support every possible way email can be sent and received (aka, you are building a generic email client), there is a lot of work you have to do.

However, if you are building a piece of software that simply communicates over email, you only have to support a relatively straightforward format for email that everyone else inherently supports.

Depending on the platform you're building on, a lot of the basics of actual email sending and receiving may be handled by the platform directly as well. I didn't have to write the SMTP handling for my code, for example, because the platform I was building my app on pretty much did it for me.

Also, the great thing about figuring out weird edge cases with email, is that email is such a widely used and universal protocol, there are literally millions of places on the Internet that have code for it or talk about it. There's a lot of resources out there.

Assuming I used python, I'd just import a library for sending email, or if using C# just import System.Net.Mail. Then it should be pretty simple. I would have made sure it worked for a major email provider (like gmail) and then work on edge cases when/if they came up.

Since the game would need your email password in order to load incoming messages I would advise them to create a new email just for game communication purposes anyway, and tell them not to use certain characters if for some reason I couldn't get them to work (although the libraries should be able to handle it anyway).

In fact, that's what I did for my SMTP. :) Though sadly, System.Net.Mail has no code for :receiving: mail, which is annoying. Also, System.Net.Mail doesn't work with Outlook.com, though it does work with Gmail (weird, right?).

> Good UI isn't hard. Generally, it's simple and universally understood.

I have to strongly disagree with that, it might be easy to spot good UI but it is not normally easy to make a good UI.

As for SMS Twilio is dirt cheap $0.0075/message + $1/mo for a number also combining it with something like Wit.ai [0] to parse your text and you can get pretty far.

[0] https://wit.ai/docs/http/20141022

That's a monthly fee and a per message fee I don't have to pay because I'm using email. :) Also, I get to use a open standard, which is another big plus.