Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Open-Sourcing InboxSDK (YC S11) – Build Apps in Gmail
257 points by alooPotato on Oct 11, 2022 | hide | past | favorite | 55 comments
Hi HN! We’re Aleem, Chris, Borys, Meichen and Zach from Streak (YC S11) and today we’re open sourcing our InboxSDK https://www.inboxsdk.com, which makes it easy to build apps for 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!');
    },
  });
InboxSDK enables you to add info to the sidebar on threads, add items in the left navigation tree, insert results into the search box, navigate to full page routes, add toolbar buttons to the compose window, add label indicators to thread list views and many more. You can see some examples in my comment posted below.

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 https://github.com/inboxSDK/inboxsdk, and the docs are: https://inboxsdk.github.io/inboxsdk-docs




This is incredible! A few years ago we used InboxSDK to build a custom interface to visualize all kinds of interaction information from a corporate database, based on a currently selected or hovered email address or thread (and in a way that it could be used alongside Streak, and actively was!).

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 :)


Yeah this is a great idea. Will explore.


InboxSDK is very nice. However my personal stopper is the use of YOUR_APP_ID_HERE for broadcasting to mothership.

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 fundamental motivation for the app id concept is that part of the value that InboxSDK provides is cushioning the developer from version conflicts, both from Gmail updates and from multiple extensions that all use InboxSDK. So we use app ids + a custom error reporting mechanism to aggregate anonymized error reports in order to figure out incompatibilities + reach out to the developer as appropriate.

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


Fred, your comment is greatly appreciated! Will investigate more


(Streak and InboxSDK developer here)

>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.


Wow. This is bad in so many ways. Hasn't nobody made a truly free as in freedom fork?


See Fred's comment above - the one thing that's different about our SDK vs typical JS libraries is that Gmail is a moving target AND several extensions may be working modyifying Gmail at the same time. It's really important that developers are on the latest compatible versions of the SDK.

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?


No necessary bad or evil. However perception of intentions here dont give a good feeling. Better to investigate more.


Some links to how the InboxSDK can modify Gmail:

[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 awesome news!

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.


That's great to hear!


Congrats to the team! Excited to see the community in full force. Looking forward to sending some PR’s your way :)


;)


Will it be possible to create a 'allow/disallow list'? I have been dreaming of an inbox where I can block all incoming emails by default. A separate page shows tags of incoming domains and people (highlighting how much you have communicated with them previously). Then I can whitelist whose communication I actually want to see in my inbox.

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.


Yeah this would be a cool product. You'd have to use both the InboxSDK to build your UI in Gmail as well as using the Gmail API (https://developers.google.com/gmail/api) to make sure new incoming emails are correctly sorted by your rules.


I imagine you know this already, but hey.com has this as a key feature.

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


> Over 1.8B users spend their days in Gmail!

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.


Yes there are lots of users of Gmail. But I feel like email in general is one of the more open protocols we have. I understand it's hard to self host nowadays but at least it's possible. And Gmail isn't the only major player.

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...


> 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.

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!


Nice move open-sourcing it. At the company I work for, we considered InboxSDK when making an Gmail-integrating extension.

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?

[1] https://github.com/KartikTalwar/gmail.js


Same this side. We are happy user of Gmail.js[1]

[1] https://github.com/KartikTalwar/gmail.js


Came here to tell the exact same thing actually.


When I was a product leader at Dropbox back in 2015, we chose to build our Gmail integration on the InboxSDK and we're generally happy we did.

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.


This is actually great, we use aria labels at inboxpirates.com to extract most of the Gmail data. Saw this and Gmail Js (https://github.com/KartikTalwar/gmail.js/)

It seems more robust than Gmail JS


I have a personal app that I have been using for years that stopped working last week or the week before. I actually thought Streak was folding and started hacking a replacement for my use case.

Streak was one of the app I recommended most to indie entrepreneurs. Glad to hear you're still standing !


I love Streak for singleplayer but prefer Missive or Front for collaboration.

It would be awesome if someone can turn Gmail into a collaboration hub like https://missiveapp.com/ or Front with this SDK.


Hope someone builds this with the InboxSDK!

Would love to know how Streak can do better at the collaboration use case for you though


1) I have to add everyone to a box if I want to collaborate. 2) I want to collaborate directly in a thread. See https://missiveapp.com/features/collaborative-writing


how do missive and front compare to each other? Do you find one superior?


We choose Missive for now because Missive feels like a proper snappy desktop app and is vastly cheaper ($15 vs $50 per user). Front feels like a bloated website wrapped in Electron.

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.


Has Google given any guarantees about maintaining compatibility with browser extensions?


> 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.


This is very powerful, thanks for sharing this.


Wonderful initiative, thank you!!!

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.


Can this already be called the spiritual successor of Lotus Notes or are important components missing?


This is interesting.

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?


I don't believe so, but we target everything in the Webkit ecosystem (Chrome, Edge, Safari), so Firefox would be the only odd browser out.


Chrome left the WebKit ecosystem about a decade ago.


Any chance Firefox support is on the roadmap?


We don't officially support it but some folks have had success.

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.


> Those requests have mostly disappeared more recently

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.


Maybe. But as someone who prioritizes what we build, no one asking for it is a pretty strong signal not to build it.


I suspect there's a shift coming once Chrome forces manifest v3. TamperMonkey also gives you a unified API to build your unified API on top of.


Most of our users of Streak don't know and def don't care what Manifest V3 is.


Understandable, but really a deal-breaker for many.


Amazing news! InboxSDK is amazing and now it's even more awesome.


Thank youuu

This is amazing guys, hoping to contribute with the platform soon.

Cheers from DragApp


Great news. Will definitely be using this :)


Is there a higher risk of the user's account being blocked by Google after using this?


We haven't seen that at all. 10's of millions of users have used apps built on this SDK.

I think the reason it isn't an issue is because Gmail (the client/server) doesn't really know that there are extensions running


Does it work with manifest V3?


It does! That was actually one of the motivations for open-sourcing.


Great, I think this should be in documentation, couldn’t find it on GitHub as well


Should be right at the top of https://inboxsdk.github.io/inboxsdk-docs/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: