robn_fastmail

> I wonder if other FastMail staff will have their own thoughts :)

Ok, thanks for the nice soapbox, boss :)

I've been at FastMail for ~2.5 years. The first 1.5 was as Opera. I haven't noticed a substantial difference between the two owners. Under Opera there was a very small amount of bureaucratic tension in a couple of places but that's to be expected given the amount of freedom we had. There's some decisions we've been able to make more quickly now we're on our own, but I don't think there's anything in particular we would have done differently had we not left Opera. I do miss the occasional trips to Norway though...

What I love the most about FastMail is the trust. Competent technical people can recognise other competent technical people, and though some days I feel like bit of a fraud because everyone at the company is crazy smart, I know I'm good enough to pass most of the time. They obviously agreed, because on my first day I was given complete, unrestricted access to everything - keys to the kingdom. Along with that I got told "do cool stuff and don't fk it up".

It probably took me 18 months to really understand that they actually meant that. If I have an idea I can run with it and don't need to ask for permission. If its complicated and I don't understand something, I'm expected to get help. If I screw it up, then I'm expected to get up at 3am and fix it, and deal with the support calls and the PR fallout, and the general embarrassment around the office.

The flip side is that I have to take complete responsibility for my actions. If we agree to as team to do something, we're all responsible for driving it, and we're all expected to hold each other to account. If I promise to deliver something, then it has to be delivered. No one will get fired for a mistake - fear doesn't exist in our dojo - but if you screw up someone is going to pull you aside and ask what happened and how we can avoid it next time. Though that's kind of cool too because you learn pretty quick that if you screw up its easier to just write an email to the team telling them so and explaining what needs to change to stop it happening again.

All of this only works if everyone is really passionate about the service and is happy to get their hands into whatever thing is important that day and take responsibility for everything. We've had staff in the past that were good at what they did, but didn't deeply care about the service. So they had a tendency to not completely polish everything, or overengineer, or not step outside of their area of interest, and it didn't work as well.

A possible downside of all this is that none of us seem to have a strong distinction between "work" and "home". We work wherever there's network, from all over the world, at all hours. Its pretty normal for me to get home (assuming I didn't arbitrarily decide to work from home or a coffee shop or whatever that day), spend a couple of hours with my family, and then get straight back into it. But that's only because most days I sit back down at my desk and can't think of anything else I'd rather be doing!

I'm not actually one of these owner-staff people, but "just" an employee, but really that only seems to be make any difference when we're talking about financial or legal stuff. On technical matters, we're all equal. I've pulled up one or more of the owners before on stupid technical decisions. I've walked in and said "you've got too much on your plate, I'm taking this and this". I will defer to them on stuff related to financials and legals because ultimately its their money and necks on the line, but that's fine because my opinion is always heard and valued.

Yeah, this sounds like an impossible magical fairy land. I still don't quite believe it some days, but it really is this great. That's the culture RobM and others have built over the life of the company. I don't know how deliberate it was, but I'm going to work hard to make sure it stays that way because every day I'm excited to get up and go to work, and a little disappointed to have to leave and go home and/or go to bed.

> That's odd. I remember the K9 email client working on a phone with CyanogenMod and without Google Play or the other Google services and I was getting notifications on new emails.

On Android platform notifications and push notifications are different things. Any app can drop a notification into the notification area, and that's what most mail clients do in response to IMAP traffic.

A push notification is a small chunk of data sent by a server to Google's push channel with a target device/app identifier, which Google then sends on to the device. The target application wakes up and receives the data, and can do whatever it likes in response (or nothing at all). The FastMail app responds to pushes by calling back to the FastMail servers to find out what changed and update the platform notification accordingly).

Without the push channel, there's nothing that can trigger this, so you don't get notifications. We could wake up and poll regularly, but that's going to be pretty horrible for your battery.

There are other push channels around (eg Amazon have one) but they have different interfaces and its not at all clear there's enough demand to make it worth the time and effort to develop, test and maintain.

Until then, the app without notification support is almost identical to the regular web app in Firefox or Chrome, so you might as well just use it that way.

> And as a suggestion, given that this is just a packaged web interface, it would be awesome to see it published for Firefox Mobile / Firefox OS.

I did look into it briefly, mostly to make sure we weren't making any architectural choices that would prevent it in the future. Right now though there's basically no demand for Firefox OS. If it becomes worth the time and effort to do it, we'll reconsider it.

Not yet. We're working on a small server and client to act as a reference implementation, and there are longer-term plans to build it directly into Cyrus. We're also planning to do a proxy that you can put in front of any IMAP server to make it talk JMAP.

It won't be this year. We hadn't even considered this feature before so it needs to be investigated and then if we want to do it, designed, implemented and tested. That doesn't have to take a lot of time, but we have other priorities first.

Protocol and implementation complexity, the need for patent licensing and our desire to use standard protocol wherever possible.

> 1. Does your app have a passcode to open?

No. We'll look into it.

> 2. Can I move mails from spam to inbox and from inbox to Spam?

Yes, tap the message while open and use the "report spam" or "not spam" button (the shield icon).

The application gets cached but the data does not. We're looking at ways to improve the initial load time.

If you tap the message area when reading, a row of action buttons will appear. You can archive, delete, report spam, move to folder and mark from here.

At this point, there are no new laws. Its still being debated in Parliament and submissions are still being reviewed, so its not clear what the final act is going to look like, assuming it passes. So we can't really comment on its impact until we know what's actually in it. We just don't know yet how this is going to play out.

> We have notification actions, extensibility, file sharing, and a Pebble SDK too, y'know.

Apart from the Pebble SDK, most of those landed in iOS 8. We were already in testing at the time it came out and our lead developer was preparing to travel, so we decided it was better to release rather than wait a few more months.

Of course there will be updates. We want to do lots more with the app; this is just the beginning :)

Haha. Yeah, they're in New York. Our offices are in Australia though, so its in our best interests to make sure things go fast! I can only imagine what it must be like for people actually in the US :)

Please contact support. That's definitely not right.

> Is the code on: http://jmap.io/server.html actual code?

No, just pseudo-code.

Right now we don't have a lot of real JMAP code. FastMail's implementation technically isn't JMAP. To write JMAP we took our current protocol and filed off a lot of the pointy edges. We're working to update our own implementation, and we're also working on open-source reference servers and clients.

There's a mailing list just starting here:

  https://groups.google.com/forum/#!forum/jmap-discuss

You might like to sign up and lurk there. I'll be posting to it soon (maybe tonight) to get the ball rolling on a few things.

Its being developed.

Any CalDAV connector for Android will do the job. We recommend CalDAV-Sync: https://play.google.com/store/apps/details?id=org.dmfs.calda...

Once we have CardDAV available, then we'll be recommending CardDAV-Sync.

No, and it won't happen unless Apple open up their IMAP push channel.

Now that our app is released we're unlikely to pursue this further.

> That's great to hear. Regarding the Android app having just checked it out, my first request, if you're taking them, is multiple account support. I can only log into one fastmail.com account at a time with what is here now. The reason I have two accounts is because I have two domains that get emails.

Yep, its high on the todo list for a future update.

> http://jmap.io/ seems pretty awesome, I guess I can use that to build my own fastmail app integration?

That's the intent, though we're not there yet.

We're hoping to overhaul our authentication system next year. App-specific passwords is on our list.

Thanks for the feedback. We'll look into it for a future update.

My point was more that this is a thread about the new apps, not about our privacy policies. If you want to start a new thread somewhere I'd be happy to comment on it.

The main feature of the Android app is push notifications, which requires Google Play Services. A version of the app without push notifications is pretty much identical to just using the regular web app in Chrome Android, so there didn't seem to be a lot of point doing distribution via other means (with the extra maintenance overhead that brings).

If there's enough demand for something else then we'll be happy to revisit this.

Ahh yes, I can see why that would happen. I'll file an internal dev ticket, thanks.

There are no new laws (yet). But lets not get into this discussion here. Contact privacy@fastmail.com with your questions and we'll be happy to respond to them.

There's more in there than just the webview: all the push channel and notification stuff, a JMAP client, a Gravatar client and cache, sharing stuff, smartwatch hooks, etc. That said, none of it is particularly interesting or difficult.

No plans to open source it at the moment, but we might if there was sufficient demand.

Fair enough, we love IMAP too, and there's no way its going anywhere. We've always cared about standards compliance and client choice, so use what you like and be happy! :)

It _should_ have an unread message count on the icon. But yes, the iOS version's only significant feature over the regular web app is the addition of realtime push notifications.

The Android app has a lot more right now, mostly because the web app experience has been pretty terrible in the stock Android browser so there was a lot more work needed to get it up to scratch.

Of course we'll keep working on it; we've got loads more plans :)

It was actually a really interesting development process. We already had the web app, and our main UI developer is an Apple guy, so he took on the iOS version. Meanwhile I'm primarily a Linux guy and work on FastMail's backend services, but also an Android user, so I did the Android version.

What it meant is that the other guy could make supporting UI tweaks as he needed, and I could make supporting backend tweaks as needed (eg push system integration), but we had to come together a lot to find the similarities and differences between the two platforms and do changes for each other.

It became a bit of a competition and we both were working very fast. We had something we could use every day in less than a month and we each learned a huge amount about the other person's area of speciality.

I'm fairly confident if we did just one app first we would have gone much slower and made some bad architectural decisions that would have hurt when we got onto the next platform. If we ever do a third platform client it'll be really easy.

> Your comment here strongly suggests the padlock was the primary reason for this change.

It was the initial motivator. The privacy advantages however are still real. Ultimately it all goes to our customers being able to have confidence that when they're using the service their security and privacy are being taken care of.

> I'm surprised you weren't aware of GMail rolling this feature out. It was big news at the time.

Honestly, I can't remember if I noticed when GMail rolled it out. Looking back on the press from the time, I imagine that if I thought anything it was "oh, you too" because I strongly remember Github rolling out a similar feature in 2010.

https://github.com/blog/743-sidejack-prevention-phase-3-ssl-...

And sure, its not exactly the same thing, but close enough that it might not have stood out to me.

Did others at FastMail notice? Maybe. I certainly don't have a record of a conversation about it, and the first discussion we had about implementing our own image proxy was in May, and Gmail was not mentioned until much later once we decided what we wanted to do and starting shopping around for an off-the-shelf package.

I'm not sure what point you're trying to make. Or are these just observations?

Actually the reason is that we're planning to roll out an EV cert later this year, and we hated the idea that an arbitrary email can remove the green badge.

Once we decided we wanted to do this, then we looked around to see what other places were doing. That's when we noticed Gmail, but it was actually Github's Camo proxy that we thought of first (and ended up cloning).

I have edited that sentence to say "where the request came from" rather than "who has actually requested it".

Overall though, its still an improvement. A key in the URL does verify that the email address is deliverable, which isn't nothing, but still can't be directly correlated with an IP address or other tracking data.

We're actually testing bitcoin payments at the moment. If you want to take the time to contact support, we can tell you how to use it.