Show HN: Open-Sourcing InboxSDK (YC S11) – Build Apps in Gmail
Over 1.8B users spend their days in Gmail! Having your app built into the Gmail workflow is a better user experience and gives you great user retention. InboxSDK gives you a high-level, declarative API to insert your UI into Gmail without having to directly manipulate the DOM yourself. End users install a browser extension to use your app.
The SDK can add UI to multiple areas of Gmail. For example, adding a button is as simple as:
composeView.addButton({
title: "My Nifty Button!",
iconUrl: 'https://example.com/foo.png',
onClick: function(event) {
event.composeView.insertTextIntoBodyAtCursor('Hello World!');
},
});
Hubspot, Dropbox, Giphy, Clickup, Loom, Todoist, Clearbit and our own Streak have all built apps using the InboxSDK. The InboxSDK is open source dual-licensed under the MIT and Apache 2.0 licenses for maximum flexibility.
Why use the InboxSDK over rolling it yourself? Several reasons: (1) it’s hard to do DOM manipulation in a performant way; (2) you need to handle all the different configurations of Gmail—there are a lot, and they change often: e.g. conversation view on/off, multiple inboxes, chat left/right, personal vs Workspace accounts; (3) You have to maintain compatibility with tons of other Gmail extensions so you don’t stomp over each other.
On a technical level, the InboxSDK handles all the DOM watching and manipulation, XHR interception, multiple extension coordination, and exposes a high level API to developers. We make use of page-parser-tree, another package we open sourced that helps detect elements on the page performantly. The trickiest bit we handle is intercepting and modifying network requests that Gmail makes in order to support several of the APIs we expose.
We’ve been building this SDK for years - it’s what powers Streak (www.streak.com), an 8 figure ARR SaaS business. We built the InboxSDK for ourselves because we wanted to separate our logic for wrangling Gmail from that of our app. Several years ago we let developers use a hosted version of our SDK. We didn’t want anyone else to go through the same pain to integrate deeply with Gmail. There were two unexpected benefits:
It vastly increased the number of end users (20M+) using apps built on our SDK. This gave us significant leverage with Google. They are super supportive of the SDK and give us early access to several builds to ensure the SDK doesn’t break when they make updates to Gmail.
We spent an ungodly amount of time maintaining compatibility with other Gmail extensions. Once the InboxSDK became a defacto standard, all the apps (currently >1000) that used it were instantly compatible (the InboxSDK operates under the model that there will be several extensions running at the same time and it elects a leader to route all modification through).
Why open source it now? First, several companies were nervous about us hosting the SDK. We mainly did this so that every extension was running the same version of the SDK, but with the recent Chrome manifest V3 changes, remote code execution is no longer supported. Not hosting the SDK removed the primary reason why the project needed to be closed source. We do need to figure out a new way of keeping all developers relatively up to date on the latest version of the SDK, any ideas?
We’d love feedback! The repo is [1] Inserting buttons into the compose toolbar <https://uploads-ssl.webflow.com/5ff703387b4e84030da35e5e/600...> [2] Adding indicators to threads in a list <https://uploads-ssl.webflow.com/5ff703387b4e84030da35e5e/600...> [3] Adding a sidebar to a thread <https://uploads-ssl.webflow.com/5ff703387b4e84030da35e5e/600...> [4] Adding buttons to a thread toolbar <https://uploads-ssl.webflow.com/5ff703387b4e84030da35e5e/600...> [5] Adding autocomplete search results <https://uploads-ssl.webflow.com/5ff703387b4e84030da35e5e/600...> [6] Adding sections to the left nav <https://uploads-ssl.webflow.com/5ff703387b4e84030da35e5e/600...> [7] Defining full page routes with custom content <https://uploads-ssl.webflow.com/5ff703387b4e84030da35e5e/600...> [8] Adding entire sections to the inbox <https://uploads-ssl.webflow.com/5ff703387b4e84030da35e5e/600...> [9] Adding keyboard shortcuts <https://uploads-ssl.webflow.com/5ff703387b4e84030da35e5e/600...> This is amazing guys, hoping to contribute with the platform soon. Cheers from DragApp I think the reason it isn't an issue is because Gmail (the client/server) doesn't really know that there are extensions running Didnt check the source code fully for a while. 1. hello-world example gives you a warning right into the face: InboxSDK Developer Warning: Invalid AppId
You've loaded the InboxSDK with an unregistered appId. Registration is free but necessary to load the SDK. https://github.com/InboxSDK/hello-world It would be great to see it truly open source without YOUR_APP_ID_HERE hustle 2. source code looks a bit old
search /* @flow */ 3. https://github.com/InboxSDK/InboxSDK/blob/main/package.json
dev dependencies mixed with everything else Overall it's still a very valuable project. Hacking into gmail or any other big SaaS service UI is multiyear unpleasant journey. Did it for LinkedIn myself. Lot of respect in InboxSDK team anyway. The app id's are used to reach out to developers who may be on too old of a version of the SDK. All that being said, seems like we could make this opt in. Another idea might be to post warnings in the dev console (in dev mode) if the version of the SDK you are using is too old. We'll explore all of these but have other ideas? You're welcome to make the app id opaque. Also feel free to file an issue for making a setting to disable the app id - definitely not opposed to adding it as an option given interest. -Fred Eng @ Streak >2. source code looks a bit old search /* @flow */ The codebase is in a hybrid setup of Flow and Typescript right now as we've been incrementally moving to Typescript. We've been opportunistically updating code to Typescript as we go. Both parts are still typechecked and we still see either system as a massive improvement over untyped Javascript. There is some awkwardness at the boundaries requiring some types to be specified again in the other system, but neither has any real concepts the other doesn't so it's not as painful as one might think. We do expect to get the codebase to pure Typescript in the future; we've recently finished a large conversion of an internal non-InboxSDK codebase of ours. >3. https://github.com/InboxSDK/InboxSDK/blob/main/package.json dev dependencies mixed with everything else That package.json isn't actually part of the published npm package. Only the files in packages/core/ are published in the npm package. The project wasn't originally set up to be published on npm and when we started publishing to npm, we wanted the package to have a separate readme and directory structure from the main then-private repo so we set up that separate directory for publishing it. There may be some room to streamline that setup, especially since now there's no public/private split. It would be awesome if someone can turn Gmail into a collaboration hub like https://missiveapp.com/ or Front with this SDK. Would love to know how Streak can do better at the collaboration use case for you though But, Missive is full of design flaws. They seem to add feature after feature without taking the relation between different features into account, nor do they seem to have a UX designer on the team. The Snooze shortcut for example opens a different snooze selector in a private email compared to a team email. The list of quirks goes on. I fear that we will eventually switch to Front because Missive is unintuitive or (please someone build that) Gmail with collaboration features. It was a breath of fresh air, but not having access to source code meant that when we went outside of the supported interfaces and needed to do some reverse engineering ourselves, we were working with a hand tied behind our back, and couldn't easily contribute any of our findings upstream. Now, it's the perfect solution, and I hope an open community sprouts up around this! Regarding the updates, it might be a good idea to put together a status page just for the SDK - similar to https://status.streak.com/ but perhaps a product that doesn't track historical uptime :) and provides more granular subscription capabilities. That way, any project using this can subscribe to "Gmail made a change, if you're affected you'll need to bump your InboxSDK version and re-publish to the Chrome store" in a Slack thread or even write a webhook-creates-a-Github-PR integration and - in cases where there are business users of their extension - ensure that any resulting outage is triaged appropriately. And perhaps subscribe to more minor releases in a separate more-asynchronous Slack channel. I imagine this might be helpful for Streak as a consumer of the SDK as well :) We're shifting away from browser extensions to TamperMonkey scripts because of the futility of trying to get everyone in the company to use the same browser. Would your SDK be usable with TamperMonkey? From a user perspective, we used to get asked all the time to support Firefox for Streak. Those requests have mostly disappeared more recently - seems like our user base is predominantly Chrome and Edge. Could it be because Firefox users have given up? I wonder what percentage of your user base would be Firefox users if it were supported. Of course I don't have an answer to that, but I don't think lack of requests necessarily translates to lack of interest. But at the time it was closed-source so we went with the open-source Gmail.js[1] instead. Now that InboxSDK is open-source too, how do you guys feel they compare? Do they have their different strengths or niches? My team built the first version of the Pipedrive Gmail extension [1] and Inbox SDK was [2] instrumental to getting it to work we wanted to: among other things we used the routing mechanism heavily to give contextual views depending on where the user was within gmail. Thanks for your work, and thanks for making it open-source! [1] https://www.pipedrive.com/en/blog/pipedrive-gmail-extension [2] I don't work in Pipedrive anymore and I don't know whether Inbox SDK is still used at this point in time. Streak was one of the app I recommended most to indie entrepreneurs.
Glad to hear you're still standing ! Looking at the docs this isnt possible so far but happy to be corrected. Great product and also very nice of you to OSS it. I've even seen an article or two about how to get Fastmail to do something similar, which I imagine would work for Gmail too, e.g. https://www.joshuawood.net/make-fastmail-work-like-hey Way to absolutely depress me one paragraph in. It's really unfortunate to see a whole ecosystem trying to ossify this problem with even more dependence on a monopoly. Even if this tool is open source, it's an open source tool to lock you into a proprietary one, rather than using open standards to create strong mail-enabled applications people can run where they choose. In terms of competition amongst email providers, it seems pretty healthy - Hey (www.hey.com) would be an example I point to of being able to start a new email service. Def can't say the same about social networking protocols... And pretzelbox.cc (mine)! It’s an inbox for your domain. Can’t believe you didn’t mention this super niche tool used by me and my four alt accounts! It let us focus on our core user experience, without worrying about all the DOM hacking, Gmail variants, constant version updates, etc. If you want to build cool experiences in Gmail, highly recommended. It seems more robust than Gmail JS Would this allow me to change the labels (in the NavMenu I guess)? For example, I'd like to add an icon to each label, and the icon's onClick event will be used to alter the text in the search box.55 comments
[ 2.7 ms ] story [ 115 ms ] thread