4 ms·

> But the larger goal with Inbox is not just to offer a suite of developer tools, but to create a new email standard. That means, Grinich says, the company has

> But the larger goal with Inbox is not just to offer a suite of developer tools, but to create a new email standard. That means, Grinich says, the company has to provide the fundamental infrastructure as an open source package. I really am at a loss to think of something that email as a standard (and SMTP as a protocol) is lacking that requires a replacement. There are a lot of things that I would like from an email client, but almost all of that can be done over IMAP using an MUA, and that would allow interoperability with literally every other email server out there, no matter how old the software is. Replacing e-mail (and/or SMTP) as we know it would be a change on the order of magnitude of IPv4 → IPv6, in terms of how disruptive it would be to daily operations and how much extra work it would require just to handle the changeover seamlessly. Unfortunately they don't go into too much detail with what they hope to do[0], so I'm left with no understanding of what they want to do that's so advanced that it requires a new standard altogether. [0] At first glance, everything they talk about can be done using IMAP and makes more sense to implement client-side than server-side/embedded into the protocol.

GrinningFool 12y ago
At first glance, everything they talk about can be done using IMAP and makes more sense to implement client-side than server-side/embedded into the protocol Take a stab at building an unicode-enabled email client that works using 90% of available client features across any one major email provider and any one imap OSS server. After a few months when the flow of edge-case bugs slows to a medium roar, take a stab at allowing customers to connect to a different OSS imap server. Then try adding support for exchange's imap. The standards exist, but they are open to a lot of interpretation in key areas. As a result, there are a lot of interpretations. It's a painful thing.
- grinich 12y ago
  This is exactly why we built the Inbox API.
  - XorNot 12y ago
    So we can have yet another standard with weird quirks and edge cases, but also that's proprietary and promises to change in breaking ways to existing email? The world in which Inbox succeeds at anything is just a world where we have some more webmail competitors and that's about it.
VLM 12y ago
"I really am at a loss to think of something that email as a standard (and SMTP as a protocol) is lacking that requires a replacement." Scrap push and go pull, every destination I send to is just a personalized RSS feed I create and you can poll it or not. You want to connect with unknown people, post to a mailing list. Or people can push you a pull request which you're free to ignore. If you want something a little less ambitious, how about mandatory cryptographic authentication as a 100% requirement, no downgrading and not optional. You wanna be in the new network you will have a real (not self signed) CA issued key and you will have a keyserver with all your users valid keys in them or we aren't accepting any mail from you or your supposed users. This isn't so much new tech with new code as issuing whips and chains to the sysadmins to enforce common sense. Want something even simpler, I assume the only reason gmail doesn't do locale / charset filtering is a patent, but if not, it seems blindingly obvious that if I don't read Korean you could filter out anything containing more than 10% Korean glyphs or entire words. This is so obvious, the reason gmail doesn't provide it today must be a patent. It would be funny if "inbox" means literal inbox as in a remake of that "scan and email" postal mail provider but they get around postal regulations by living in a civilized .gov or by not handling mail (they eat interoffice paper spam, which is admittedly a dying product, I haven't gotten a genuine paper memo in many years) Perhaps if you recall the anecdote from snow crash where the fedgov employee had her email reading habits tracked in detail, they could sell this to HR for sending HR-spam.
jfb 12y ago
I really am at a loss to think of something that email as a standard (and SMTP as a protocol) is lacking that requires a replacement. Postage. Solve the spam problem with economics. Can't be done with SMTP.

GrinningFool 12y ago

At first glance, everything they talk about can be done using IMAP and makes more sense to implement client-side than server-side/embedded into the protocol Take a stab at building an unicode-enabled email client that works using 90% of available client features across any one major email provider and any one imap OSS server. After a few months when the flow of edge-case bugs slows to a medium roar, take a stab at allowing customers to connect to a different OSS imap server. Then try adding support for exchange's imap. The standards exist, but they are open to a lot of interpretation in key areas. As a result, there are a lot of interpretations. It's a painful thing.

grinich 12y ago
This is exactly why we built the Inbox API.
- XorNot 12y ago
  So we can have yet another standard with weird quirks and edge cases, but also that's proprietary and promises to change in breaking ways to existing email? The world in which Inbox succeeds at anything is just a world where we have some more webmail competitors and that's about it.

VLM 12y ago

"I really am at a loss to think of something that email as a standard (and SMTP as a protocol) is lacking that requires a replacement." Scrap push and go pull, every destination I send to is just a personalized RSS feed I create and you can poll it or not. You want to connect with unknown people, post to a mailing list. Or people can push you a pull request which you're free to ignore. If you want something a little less ambitious, how about mandatory cryptographic authentication as a 100% requirement, no downgrading and not optional. You wanna be in the new network you will have a real (not self signed) CA issued key and you will have a keyserver with all your users valid keys in them or we aren't accepting any mail from you or your supposed users. This isn't so much new tech with new code as issuing whips and chains to the sysadmins to enforce common sense. Want something even simpler, I assume the only reason gmail doesn't do locale / charset filtering is a patent, but if not, it seems blindingly obvious that if I don't read Korean you could filter out anything containing more than 10% Korean glyphs or entire words. This is so obvious, the reason gmail doesn't provide it today must be a patent. It would be funny if "inbox" means literal inbox as in a remake of that "scan and email" postal mail provider but they get around postal regulations by living in a civilized .gov or by not handling mail (they eat interoffice paper spam, which is admittedly a dying product, I haven't gotten a genuine paper memo in many years) Perhaps if you recall the anecdote from snow crash where the fedgov employee had her email reading habits tracked in detail, they could sell this to HR for sending HR-spam.

jfb 12y ago

I really am at a loss to think of something that email as a standard (and SMTP as a protocol) is lacking that requires a replacement. Postage. Solve the spam problem with economics. Can't be done with SMTP.