spang

We've been using Honeycomb at Nylas for 6+ months at this point and love it - the product keeps getting better and better, it's fast and reliable, and it's given us new debugging capabilities that make investigating outages and digging into system performance easier than they were before.

We've also built our own ELK cluster (three times!) and can attest that it takes very significant engineering effort to get a scalable, reliable, high performance cluster, and the ongoing cost in hardware is easily hundreds of dollars a month or more.

Three things that we can do with Honeycomb that we can't do with ELK (or at least not easily):

* Quickly iterate on questions to explore datasets. It makes a huge difference in how you approach a tool when the time between question and answer is milliseconds, not seconds. * Compare trends in data - Honeycomb can easily group data by field and display many lines on the same graph. As an example: easily break down your API traffic by endpoint to pinpoint a spike in traffic to a specific endpoint. (Or by endpoint and customer, etc.) * Calculate percentiles, averages, etc. on our data in real-time - without having to set up the calculated metrics beforehand. This makes honeycomb a better tool for performance monitoring than ELK imho.

There may be ways to do some of these things with ELK, but not out of the box and, given the indexed data store behind the stack, it's just not architected to have these same capabilities.

I suspect if you dug into some of Honeycomb's other blog posts, this difference would become more apparent. :)

For now, the encryption plugin is only available on the older version, Nylas Pro. No reason for that other than time to port and QA the plugin to the new free version, which has a completely written mail sync engine that runs locally rather than in the cloud. We're working on porting all Nylas Pro features to the new version as fast as we can!

If you want to keep up to date about the latest features, you can sign up for our newsletter at the bottom of this page: https://nylas.com/nylas-mail/

No new funding model, just better tech! In the new version, we don't sync and store all of your email on our servers, which dramatically drops the cost of running the service.

It didn't make it into this release because we wanted to focus on making the base mail experience solid first, but it should be back soon!

Not yet! You can track the issue here: https://github.com/nylas/N1/issues/96

Thanks! Glad you're enjoying it. :) (I'm part of the Nylas team)

N1 supports connecting to all the major email providers, as well as pretty much every obscure IMAP server run by your ISP! What's pointed out in the FAQ is just that it uses a cloud service component (also open source! http://github.com/nylas/sync-engine) that we developed first to make it easier to build clients.

Super sad to hear about this, as the Debian project has been hugely influential on my life. (It's the reason I went to MIT and became a software engineer.) Rest in peace, Ian.

Not yet! Totally something that we'd love to see, though.

Nylas | SRE | San Francisco, CA (ONSITE) | https://nylas.com | Full Time only

Nylas is like a race car moving at 200 MPH, and you are a member of the pit crew--swapping the tires and refueling without slowing down! We're looking for a Site Reliability Engineer to take our infrastructure to the next level, with a focus on tools, availability, performance, and scale.

Critical to this role is supporting the entire engineering org in moving quickly, which includes running our internal tooling infrastructure, creating systems that make migrations/alerts/tests easy to write and run, and further improving our continuous integration and deployment workflows. You should love measuring things, making data-driven decisions, and have excellent written communication skills. As this is an engineering role, you should also be comfortable writing substantial amounts of production-grade code (although it may not be your focus). Bonus points for a deep love for large distributed systems, a knack for creating elegant tools, and experience participating in an on-call rotation and running on AWS. Double bonus points for clear, direct communication and a call-it-like-it-is attitude.

Some technologies we use: Python, AWS, MySQL, Redis, Ansible, Elasticsearch, Kafka, ZooKeeper

If you're interested, please get in touch with spang at nylas dot com directly, or apply via https://jobs.lever.co/nylas/f6d54373-2702-4d34-b3f7-d9200308.... We welcome applicants of all backgrounds.

I don't expect that we'll have time to put this together officially very soon. If you'd like to help though, the best way would be to figure out how to get N1 building on arch from the open source repo!

You can, but remember the sync engine doesn't provide any authentication layer by default, since people use it in so many different ways. You'll want to run it proxied behind some sort of authentication service. (With AWS, you can do this with different subnets via VPC.)

You got it!

Bundling the sync engine with the client works if you're willing to download your entire mail archive onto every device that connects to your mail. An implementation of the sync engine that allowed only syncing partial mailboxes would be very difficult to implement on top of (all of) IMAP, Exchange, and Gmail. By abstracting that away into a new cloud service, clients end up being both simpler and more flexible.

We saw some folks start working on PostgreSQL support here: https://github.com/nylas/sync-engine/pull/132

It's not something we're likely to support officially in the near future since we don't run PostgreSQL and don't have the ability to test it well with production loads, but it'd be neat to see a working community fork.

I used mutt until I started this company, so I couldn't agree more. :) Reading HTML emails piped to w3m gets kind of old after a while though!

We'll consider JMAP support if it reaches widespread adoption. For now, it wouldn't add much value, and we have a lot to build!

Yep, the only reason we didn't have one for launch is a lack of time. :) You want to help? First step is making sure `script/grunt mkrpm` works from https://github.com/nylas/N1!

Hey hey, Christine here from the Nylas crew. Happy to answer any questions anyone has about this!

The main codebase is in `inbox/`, with launcher scripts and tools in `bin/`.

(Might not be totally obvious, because the package namespace is called `inbox/` for legacy reasons.)

If a beginner wants to see real production code, rather than toy examples, I think it's inevitable that there will be some points of confusion. Part of the learning process is diving in and exploring and being okay with not totally understanding everything that's going on. :)

The Nylas Sync Engine is a large Python codebase with a test suite: https://github.com/nylas/sync-engine

Lots of examples of SQLAlchemy, Flask, gevent, and pytest in action to build a REST API and sync platform for email/calendar/contacts data!

Hi there, Christine from the Nylas team here. If you have any further questions on how we're using Ansible in our infrastructure, happy to answer. :)

Hi @pikzen, thanks for the comment. One of the advantages of our platform is that you're actually paying for us to run it---so we don't have to sell user data to get by.

We don't specifically support end-to-end encryption in the base email API because a centralized holder of keys is little better than no encryption at all. End-to-end encryption is something we'd love to see built on top of the platform though.

Hi there, Christine from Nilas here. No RFC, but we do have API docs[1] and source code[2]. :)

1. https://nilas.com/docs 2. https://github.com/inboxapp/inbox

Inbox | https://www.inboxapp.com/ | San Francisco, CA (Mission) | Frontend (JS), Design, Backend (Systems+Ops)

Hi! We're "The Company Formerly Known As Inbox,"[0] and we're looking for help building the next generation email platform. We're building a missing piece of Internet infrastructure and are looking for frontend engineers and designers and backend systems and infrastructure/operations engineers to join us.

Companies are building their core businesses around our email API right now, and that means we have to be reliable, up all the time, and fast. We have more data for a single user than in most startups' entire database. That means big technical challenges to solve as we scale out our fledgling distributed backend. If you have experience with automated deployments, debugging running systems, release engineering, and on-call schedules, but are still comfortable writing code, this job[1] might be for you. :)

Many people spend their entire days buried in mail clients which haven't significantly changed in years. That means many opportunities to tackle UX challenges as we build out our client scaffolds and create a new framework for the next generation of mail apps. (Ever meet anyone who really loves their email experience? We want to change that.) Sound exciting to you? Apply here[2].

== We're particularly looking for folks who ==

* Take personal pride in their work and value autonomy and ownership.

* Want the chance to step up and lead a team.

* Put the work before ego. We've got each others' backs, and we want you to be with us on that.

== A bit more about us ==

* Our backend is built on tools like Python, Flask, gevent, nginx, MySQL, AWS, and Debian. We've been careful to keep our architecture componentized.

* Our frontend projects use Coffeescript, React, (Re)Flux, WebSQL for offline caching, Atom Shell (NodeJS + Chromium), with a strong focus on extensibility.

* Tons of our code is open source. Check it out: https://github.com/inboxapp

* We're 40% women on our team of 13 (12 engineers), including 1 of 2 cofounders. We want to make that number 50%.

* Our sunny Mission office is more lived-in than tidy. Think art studio, not corporate.

* We're more likely to end up at the climbing gym or on a bike ride together than out drinking at the latest startup event.

* We have an open vacation policy and value personal responsibility and ownership. Benefits include full health, dental, vision, commuter, and lunch at the office every day. Some remote work / work-from-home is OK too.

Apply via Lever at https://www.inboxapp.com/jobs. Include a cover letter letting us know what draws you to the job. We welcome and encourage applications from women, LQBTQ folks, and people of colour. (We even have some already on the team!)

[0] A certain large company recently launched a product of the same name, so we're going to change ours soon. Roll with the punches, eh?

[1] https://jobs.lever.co/inbox/6c7e7186-953d-4083-8bde-37443a23...

[2] https://jobs.lever.co/inbox/54f73eb2-9094-40ab-b59e-f9df4868...

Inbox | https://www.inboxapp.com/ | San Francisco, CA (Mission) | Frontend (JS), Design, Backend (Systems+Ops)

Hi! We're "The Company Formerly Known As Inbox,"[0] and we're looking for help building the next generation email platform. We're building a missing piece of Internet infrastructure and are looking for frontend engineers, designers, and systems and infrastructure/operations engineers to join us.

Companies are building their core businesses around our email API right now, and that means we have to be reliable, up all the time, and fast. We have more data for a single user than in most startups' entire database. That means big technical challenges to solve as we scale out our fledgling distributed backend. If you have experience with automated deployments, debugging running systems, release engineering, and on-call schedules, but are still comfortable writing code, this job[1] might be for you. :)

Many people spend their entire days buried in mail clients which haven't significantly changed in years. That means an opportunity to tackle big UX challenges as we build out our client scaffolds and create a new framework for the next generation of mail apps. (Ever meet anyone who really loves their email experience? We want to change that.) Sound exciting to you? Apply here[2].

== We're particularly looking for folks who ==

* Take personal pride in their work and value autonomy and ownership.

* Want the chance to step up and lead a team.

* Put the work before ego. We've got each others' backs, and we want you to be with us on that.

== A bit more about us ==

* We're built on tools like Python, Flask, gevent, nginx, MySQL, AWS, Docker, and Debian. Go is likely to join this list soon. We've been careful to keep our architecture componentized.

* Tons of our code is open source. Check it out: https://github.com/inboxapp

* We're 40% women on our team of 11 (10 engineers), including 1 of 2 cofounders. We want to make that number 50%.

* Our sunny Mission office is more lived-in than tidy. Think art studio, not corporate.

* We're more likely to end up at the climbing gym or on a bike ride together than out drinking at the latest startup event.

* We have an open vacation policy and value personal responsibility and ownership.

Apply via Lever at https://www.inboxapp.com/jobs. Include a cover letter letting us know what draws you to the job. We welcome and encourage applications from women and people of colour.

[0] A certain large company recently launched a product of the same name, so we're going to change ours soon. Roll with the punches, eh?

[1] https://jobs.lever.co/inbox/6c7e7186-953d-4083-8bde-37443a23...

[2] https://jobs.lever.co/inbox/54f73eb2-9094-40ab-b59e-f9df4868...

Inbox | https://www.inboxapp.com/ | San Francisco, CA (Mission) or REMOTE | Backend systems + Ops

Hi! We're Inbox, and we're looking for help building the next generation email platform. We're building a missing piece of Internet infrastructure and are looking for systems and infrastructure/operations engineers to join us.

Companies are building their core businesses around our API right now, and that means we have to be reliable, up all the time, and fast. We have more data for a single user than in most startups' entire database. That means big technical challenges to solve as we scale out our fledgling distributed backend.

== We're particularly looking for folks who ==

* Take personal pride in their work and value autonomy and ownership.

* Have a experience with automated deployments, debugging running systems, release engineering, and on-call schedules, but are still comfortable writing code.

* Want the chance to step up and lead a team.

* Put the work before ego. We've got each others' backs, and we want you to be with us on that.

== A bit more about us ==

* We're built on tools like Python, Flask, gevent, nginx, MySQL, AWS, and Debian. Go and Docker are likely to join this list soon. We've been careful to keep our architecture componentized.

* Tons of our code is open source. Check it out: https://github.com/inboxapp

* We're 40% women on our team of 10 (9 engineers), including 1 of 2 cofounders. We want to make that number 50%.

* Our sunny Mission office is more cozy than tidy. Think art studio, not corporate.

* We're more likely to end up at the climbing gym or on a bike ride together than out drinking at the latest startup event.

* We have an open vacation policy and value personal responsibility and ownership.

To apply, email your resumé (+ GitHub/code links if you have) to spang@inboxapp.com. We welcome and encourage applications from women and people of colour.

More info and other open positions: https://www.inboxapp.com/jobs

Exactly.

Hi there, Christine from Inbox here.

Inbox is pretty much a superset of ContextIO. (You can also use it to send mails, and "entire mail clients" is a supported use case.)

Unlike ContextIO, we don't proxy requests directly to the backend mail store---we run a mail sync engine and query that instead. Lots faster and gives us a lot more room to make future improvements. Data just has to make it into the datastore in the right format and then it's accessible to query via the API. :)

Hi there, Christine from Inbox here.

That's why we're tackling the problem from a platform level, not building one specific product---it's obvious to us that the ways folks are using email these days are so varied that no one thing solves them all.

A better toolset allows many different solutions.