My current thinking is that everyone will get an obscure email address they can post to (different for each user).
The subject of the email will be used to determine the stream to post to. If the subject matches an existing stream, the email body will be created as a new card in that stream. If the subject does not match an existing stream, a new stream will be created with that name and the email body created as the first card.
My current thinking is that the email body will still be treated as Markdown.
The biggest user-facing design question is whether cards / streams are to be published immediately or not.
This could be determined by something in the email itself. Perhaps something in the subject heading or even a different email address for "publish immediately" vs "save as draft".
Attachments would be attached to the stream and probably published as individual cards.
Multi-part emails would have each part turn into a card (so if you had three parts: text + image attachment + more text, three cards would be created)
@jtauber Autoreply to email with confirmation of draft and include a link to publish the post. Can auto-live with [publish] in subject.
— Michael D. Hopkins (@mdhopkins) February 16, 2013
My first response to this was, what problem would it solve?
Post-via-email came in handy occasionally on Tumblr and Flickr when I was using a Blackberry. There were no BB apps for those services, and the browser was way too cumbersome.
ThoughtStreams's design works very well on modern mobile browsers. I'm hard-pressed to think of a scenario where using an email client would give you a better experience than just using the browser on an iOS, Android or Windows Phone device (or any desktop environment). Legacy phone users would probably benefit the most.
On the other hand, post-via-email could give TS something like an app experience when combined with Drafts or something similar.
Biggest drawback of post-via-email: no success/failure indicators. You have to take the extra step of checking the site to actually confirm that your post made it through, and that it ended up where you wanted it to.
Without the use of an app like Drafts to help me mediate the sending of these emails, I'd probably be too concerned about leaving a typo in the subject line of one of my emails, thus unintentionally creating a new stream and leaving one of my thoughts orphaned in it.
To avoid some of the risk of accidentally creating a new stream by fat-fingering the name of an existing stream, we could simple not auto-create a stream but instead reject (or send to the inbox) emails with subjects that can't be matched to a stream.
A variant on this could be the email is rejects but the user receives an email they can reply to either fix the subject or confirm that a new stream is to be created.
The first release of this feature might just be a 'post to inbox' and then we can add stream-identification-by-subject in a second iteration.
Post to thought streams inbox from email.
Enables posting from phone or tablet without writing a custom client. Easy ubiquitous capture.