It's missing the one killer feature that would fix the spam problem: approved senders. If you had a "friends" list like Facebook where only people you've approved may send messages to you, we'd cut down on 90% of spam immediately. Between that and the lack of mandatory encryption this is just another tedious protocol to implement.
JMAP – a better way to email
21–30 of 116 posts
Re: JMAP – a better way to email
#22This looks fantastic and is a huge, long-overdue breath of fresh air in the protocol space. But realistically, what will it take for major vendors like Apple and Google to start adding support for it?
Re: JMAP – a better way to email
#23It's missing the one killer feature that would fix the spam problem: approved senders. If you had a "friends" list like Facebook where only people you've approved may send messages to you, we'd cut down on 90% of spam immediately. Between that and the lack of mandatory encryption this is just another tedious protocol to implement.
That's not a practical feature in the real world. Sometimes you need email from unapproved senders. Spam filtering is better accomplished before or after delivery, not during.
Re: JMAP – a better way to email
#24Wasn't there a startup recently that pivoted from being a mail client into building a generalized API for interfacing with mail services like gmail/yahoo/outlook? I forgot the name but I'm super interested in efforts like this. I have the feeling the next big social network disruption is going to be leveraging e-mail in a big way. E-mail is the established quasi-p2p (it's a network of centralized services) platform t…
IMHO the big outstanding problems with email are spam and the difficulty of using public-key cryptography (both key distribution and mail client support). Write a dead-sexy mail client that makes the crypto completely invisible and uses either a public key directory or some kind of OAuth-ish thing, and you'd solve the latter. Better, if you made finding someone's public key take time and/or money, and simply refused to deliver unsigned mail, you'd take a big step toward killing spam.
Re: JMAP – a better way to email
#25It's missing the one killer feature that would fix the spam problem: approved senders. If you had a "friends" list like Facebook where only people you've approved may send messages to you, we'd cut down on 90% of spam immediately. Between that and the lack of mandatory encryption this is just another tedious protocol to implement.
That's not a practical feature in the real world. Sometimes you need email from unapproved senders. Spam filtering is better accomplished before or after delivery, not during.
There's nothing preventing an unapproved sender from requesting contact privileges, but once denied, their messages and further requests would be ignored by default.
Each server and user would have their own identity management concerns.
Basically someone can send a "friend request" and if approved by a human (the recipient) they may communicate freely from that point.
Re: JMAP – a better way to email
#26> By using the platform push channels, JMAP avoids having to hold its own connection open. Can anyone explain what they mean by "platform push channels"? I don't understand how you can have realtime updates without leaving a connection open or periodically polling. Do they mean that they use the same mode of transport as Push Notifications?
Android, iOS, (Windows Phone, Blackberry, etc) have services where a server application can push a small data packet to a specific device. That device wakes an application in response which can then do things.
We use this right now in our mobile apps. The apps respond by calling back to FastMail to check for updates.
More info:
http://blog.fastmail.com/2014/12/02/dec-3-push-it-real-good/
https://developer.android.com/google/gcm/index.html
https://developer.apple.com/library/ios/documentation/Networ...
Re: JMAP – a better way to email
#27It's missing the one killer feature that would fix the spam problem: approved senders. If you had a "friends" list like Facebook where only people you've approved may send messages to you, we'd cut down on 90% of spam immediately. Between that and the lack of mandatory encryption this is just another tedious protocol to implement.
There's heaps of problems to solve in the email world for sure. JMAP isn't trying to solve all of them. It's trying to make one very well defined part - the communication between end-user device and server - a whole lot better.
Re: JMAP – a better way to email
#28Great job guys! Things like this together with CalDAV and CardDAV are reasons why I pay you guys for service.
I just tried the following experiments with my Gmail and FastMail account. There's a reason why FastMail just feels faster!
Try this:
1) While having the Gmail iOS app open, mark an email as read on the web
2) See how long it takes for Gmail to reflect the change
3) Now try with FastMail iOS app, see that it's faster
Try this too:
1) While having the Gmail iOS app open, delete an email on the web
2) See that Gmail app never updates until you manually refresh
3) Now try with FastMail iOS app, see that it happens instantly
How about the other direction?
1) Read an email on your phone
2) See that Gmail on the web never updates until manual refresh
3) Now try with FastMail... Instant update!Re: JMAP – a better way to email
#29For the well acquainted -- how does this relate to Inbox (https://www.inboxapp.com/)? I have not spent enough time with either to make a comparison
Re: JMAP – a better way to email
#30Earlier quoted context omitted.
That's not a practical feature in the real world. Sometimes you need email from unapproved senders. Spam filtering is better accomplished before or after delivery, not during.
There's nothing preventing an unapproved sender from requesting contact privileges, but once denied, their messages and further requests would be ignored by default. Each server and user would have their own identity management concerns. Basically someone can send a "friend request" and if approved by a human (the recipient) they may communicate freely from that point.
How is this different from adding an address to your blacklist after the first message?