Topicbox – FastMail’s new product for teams
blog.fastmail.com
blog.fastmail.com
We're happy Fastmail email users, and can almost live with email for support, and barely use any Zendesk features other than assignments, internal notes, and various views. But those three simple ZD features we do use are critical.
Answer: we've definitely talked about how it would be great as a lightweight client management system for a freelancer or consulting firm. We're definitely looking ahead to possible integrations, too!
---
From myself - we talk a lot about "teams" with Topicbox, but it's really any group of poeple who share a common interest or responsibility. One market we've identified is homeowners' associations or "body corporates" as they're often called here in Australia. They have membership turnover as people buy and sell, and they have long running projects with a need to keep history. Finally, they consist of people who use different mail services, because unlike a business where everyone is on the same solution, a set of homeowners share nothing other than the locality in which they live. So a heterogeneous system like Topicbox with archivable topics and searchable history is ideal.
personally i think mailing-list is the most important communication tool for team work, and i think more organization need to use them
sadly the only mailing-list software for windows/exchange i found was commercial, expensive and will be a hard sell ...
Not that I am campaigning against Topicbox, but I think it's worth making clear that just because your email is hosted on Exchange, doesn't mean your mailing list solution needs to be.
You can run, and I have in fact run, mailinglists on top of Mailman / Debian / Postfix / Nginx, in a heterogenous environment where the mailservers were Exchange (and some shitty hosted Exchange run by morons to boot). You can do it without even reconfiguring Exchange if you are willing to put all the lists in a subdomain with its own MX record.
No reason why a hosted solution couldn't work this way as well. If you don't want to have your mailinglists in a subdomain, then you would need mailserver configuration to set up the aliases correctly, and that creates a certain amount of maintenance hassle every time you create a new list, but I've never been convinced that's a worthwhile tradeoff to make. Making mailinglists instantly discernible from humans' addresses isn't necessarily bad.
the only option i found for windows was listserv which cost 2K and up .. getting approval for a $2000+ .. at least where i work, needs a super solid business case ..
i would argue that at this cost, maybe i should as for a linux box, but then again, who will admin that, who will install and admin postgresql (as an example of a dependency of some of those mailing list softwares)
(https://en.wikipedia.org/wiki/List_of_mailing_list_software)
PMs unwittingly take all these roles today, but these tools will surely unlock further specialization.
Some of it was done, very satisfyingly; some of it we didn't get around to trying. Then the dotcom meltdown happened.
But fundamentally it seems to have many of the same features that Mailman et al have had for decades.
Good on them if they can make mailinglist archives great again, though. I think they're an underappreciated resource, and maybe a slick interface and some rebranding is just what they need.
It's also for Enterprise, which typically has a higher price tag.
the comparable offer from google is also $5
Sure we could half-arse things and run cheaper, but that's not the business we're in. We provide a high quality product, and we truly believe we're worth it. No apologies for that price, it's quite reasonable for the value we provide.
The rest of your post is fine, but don't say this when pitching your product because value is entirely in the eye of the customer.
We have made a conscious choice that we aren't going to chase after the really price sensitive customer.
We're OK with not having those customers. If price is your ONLY deciding factor, then FastMail isn't for you, because we'll never be the cheapest option. You can't compete with free if you don't have another funding source to subsidise the product.
And we don't: all our income comes from selling our service, so we can't compete on price alone. We have to compete on quality, features and execution.
I wound up moving this paragraph deep into the blog post because it wasn't the point of the post - but it is one of my key driving principles:
"Our goal is to solve your email needs as quickly as possible so you can get on with everything else in your life."
We don't want to keep our customers' eyeballs on our site longer than the minimum required to achieve their goals.
If you want to play the premium price game, you better be able to back it up with a good customer experience, and Fastmail does. That's why you see so many positive comments in any discussion of email.
BUT. The ongoing faff and arsing about and maintenance isn't fun. If I didn't have many, many accounts for me and other people on my servers, I'd have migrated to FastMail a long time ago.
I'm working on a guide on how to setup a replicated fault tolerant email cluster (galera/dsync) here [1] -- feedback appreciated.
This costs far more than something like fastmail, however. Depending on your situation you might value cost over peace of mind.
1: https://medium.com/@cyberpunk_networks/nsa-proof-your-email-...
Unfortunately, with Galera, you're not even a hardware failure away from losing / corrupting email.
https://aphyr.com/posts/327-jepsen-mariadb-galera-cluster
> Unfortunately, even in totally healthy clusters, with no node failures or network failures, Galera Cluster does not satisfy its claims of Snapshot Isolation.
I'll add a section on recovery, but even with a few hundred thousand email inboxes my database size is likely to be under 100mb and backing that up will cause no issues in live since I'm only doing SELECT 99.99% of the time; each of my nodes dumps the db into /var somewhere every hour.
The Mastodon instance I use is hosted at Scaleway. It's had multiple multi-day outages due to failures at Scaleway's end.
Cheap is great and all, but this experience has not been the kind that would lead me to recommend using Scaleway for any service you need to be reliable.
https://blog.fastmail.com/2016/12/13/fastmails-values/
and we unashamedly charge enough money to keep building a good service and providing a good service.
I would gladly pay quadruple that if I had to.
Fastmail looks absolutely incredible and I've never heard the slightest bad thing about them, but it'd cost me $250/month to get the same level of service I get now for free. :/
That's exactly the reason I migrated to Fastmail. Ever since Google shutdown Reader, I've been slowly replacing Google services with alternatives as much as I can.
Gmail -> Fastmail
Calendar -> Fastmail
Reader -> Self-hosted Commafeed
Drive -> Self-hosted Nextcloud
etc.
As I said here: https://blog.fastmail.com/2016/12/01/fastmail-advent-2016/
... one of the most common questions was "aren't you worried about giving away all your secrets?" Actually, we really are not. Running an email service is hard work, and providing the speed, reliability and stream of new features would not be easy to replicate. So we're happy to share our stories...
We contribute a lot to open source, and we're doing a lot in the standards space now to make sure email remains open. Topicbox is built on top of a draft of the JMAP protocol which is currently being worked on at the IETF, and will be updated to follow the standard. We have staff going to CalConnect to work on calendaring standards in a couple of weeks because we're investing in advancing the field as well. That also costs money, and we're self funded, so we can't afford to sell email accounts at a loss.
It also means we have no secret customer. Our paying customers are our actual customers, not the product we're using to pump up the valuation or collect data from. It's a simple business proposition, money for service. I'm proud to charge money for what we do.
As an actual, paying customer I just want to express just how much I appreciate that someone is actually doing this.
The internet has lots of creepy companies spying on your every move. Actually paying for a service and knowing that there's nobody looking over your shoulder feels really good. I wish there were more companies like that.
This is the hard bit about trying to sell Topicbox to you lot - you already HAVE a good interface to email, and the value of the easy-to-use archive comes later when you add another person to a group months down the track.
Thank you.
That's why we're working on JMAP! Localising comes with a ton of downsides, including the fact that of the 3 other datacentres we've installed into, none have been anywhere near the quality of services that we've had from NYI over the years.
https://blog.fastmail.com/2014/12/10/security-availability/
(and yes I see another comment in this thread that I'll reply to in a second about a 1 hour network outage we had... it's the biggest outage we've had in years. Our other datacentres have had much bigger downtimes during that period)
Particularly with the increase in mobile clients that change networks regularly, we don't see a future in old school IMAP as the preferred way to access email. Please check out the JMAP working group for what we see as the future :)
https://datatracker.ietf.org/wg/jmap/documents/
So we prefer to consolidate in a few high-quality datacentres and build protocols which work well from anywhere in the world.
[Fastmail] Services have been restored. The problem was a a network peering issue, leading to our services being unavailable to parts of the internet. We're working with our network provider to understand what happened and what improvements we can make in the future. Thank you for your patience.
An 1hr15mins of connectivity issues is quite significant imo.
Wary after the Imgix several hours of 500/504 disaster and still no technical post-mortem..
"On Saturday, August 5, 2017, there was scheduled maintenance period on a core switch in our NYC Datacenter Facility that was scheduled from 10:30PM - 2AM. Customers that were directly connected to this switch were notified that there would be a service impacting maintenance but there was no expected impact beyond these specific connections.
For some time during this maintenance, traffic from some upstream peers, including Cogent and the NYIIX Peering Exchange, experienced increased latency and intermittent loss of connectivity, due to a misconfiguration that did not effectively re-converge this traffic to other upstream providers. This incident started at approximately 11:30PM and was resolved by 12:30AM.
We have resolved the root cause of the issue, added additional monitoring and updated our notification procedures to ensure that all customers are notified in the future for such maintenance windows, even when there is no expected service impact. We are also upgrading our notification systems and customers will be contacted in the near future to confirm the contacts listed on the account to ensure that all such notifications are properly received."
This is the first time I've seen them mess something like this up in a very long time, and they're really good about fixing their proceedures afterwards.
We've been offline for similar lengths of time during the nasty run of DDOS attacks on providers a couple of years ago, but having upgraded to Fibre to the rack, 10G drops to the external bladecentres and DDOS protection services on our public IP range plus hidden private ranges for our backhaul services, we have successfully mitigated all the driveby attacks since.
... that and we haven't been a target for a bit (touch wood) - though we will write up something the DNS attacks at some point, they were a bit spectacular. Went from 200 req/sec to 100,000 req/sec for random hostnames on our servers. The engineering challenges to cope with that while still providing our powerful custom DNS options are quite interesting in retrospect. Not so much at the time!
Where I live, $5 will buy you a sort of decent loaf of bread or about 3.5 liters of gasoline or cup of coffe out on the town if you are lucky. I happily shoot Fastmail that small amount every thirty days for a neat, stable, well thought out product which saves me all the joyless hassle of running things myself.
FastMail's data collection of your email for their own use is incredibly, incredibly limited, so a lot of things other providers use won't really work for FastMail.
I don't even use Fastmail any longer, great though it is, because I have had to cut my costs absolutely to the bone in recent years. But I'm truly glad such an excellent service exists for if/when I'm again ready to pay for it, and that the engineers involved can get paid for doing a good job.