[HN Gopher] Show HN: Open-Sourcing InboxSDK (YC S11) - Build App...
___________________________________________________________________
Show HN: Open-Sourcing InboxSDK (YC S11) - Build Apps in Gmail
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
Author : alooPotato
Score : 189 points
Date : 2022-10-11 15:55 UTC (7 hours ago)
| bilalq wrote:
| 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?
| frew wrote:
| 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.
| michaelmior wrote:
| Any chance Firefox support is on the roadmap?
| alooPotato wrote:
| 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.
| kiliancs wrote:
| Understandable, but really a deal-breaker for many.
| smashah wrote:
| Great news. Will definitely be using this :)
| adeptima wrote:
| 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.
| AgentME wrote:
| (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.
| worewood wrote:
| Wow. This is bad in so many ways. Hasn't nobody made a truly
| free as in freedom fork?
| alooPotato wrote:
| 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?
| adeptima wrote:
| No necessary bad or evil. However perception of intentions
| here dont give a good feeling. Better to investigate more.
| frew wrote:
| 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
| adeptima wrote:
| Fred, your comment is greatly appreciated! Will investigate
| more
| josteink wrote:
| 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
| koolhead17 wrote:
| Same this side. We are happy user of Gmail.js[1]
|
| [1] https://github.com/KartikTalwar/gmail.js
| dekervin wrote:
| 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 !
| soco wrote:
| Is there a higher risk of the user's account being blocked by
| Google after using this?
| alooPotato wrote:
| 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
| another_devy wrote:
| Does it work with manifest V3?
| frew wrote:
| It does! That was actually one of the motivations for open-
| sourcing.
| another_devy wrote:
| Great, I think this should be in documentation, couldn't
| find it on GitHub as well
| alooPotato wrote:
| Should be right at the top of
| https://inboxsdk.github.io/inboxsdk-docs/
| btown wrote:
| 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 :)
| alooPotato wrote:
| Yeah this is a great idea. Will explore.
| tkk23 wrote:
| Can this already be called the spiritual successor of Lotus Notes
| or are important components missing?
| fillskills wrote:
| 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.
| alooPotato wrote:
| 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.
| raoulj wrote:
| Congrats to the team! Excited to see the community in full force.
| Looking forward to sending some PR's your way :)
| alooPotato wrote:
| ;)
| felipe_malara wrote:
| Thank youuu
|
| This is amazing guys, hoping to contribute with the platform
| soon.
|
| Cheers from DragApp
| xixixao wrote:
| Has Google given any guarantees about maintaining compatibility
| with browser extensions?
| jinpan wrote:
| > 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.
| alooPotato wrote:
| 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...>
| usamaejaz wrote:
| Amazing news! InboxSDK is amazing and now it's even more awesome.
| samuelstros wrote:
| 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.
| alooPotato wrote:
| Hope someone builds this with the InboxSDK!
|
| Would love to know how Streak can do better at the
| collaboration use case for you though
| samuelstros wrote:
| 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
| nip wrote:
| 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.
| alooPotato wrote:
| That's great to hear!
| sachinjain wrote:
| This is very powerful, thanks for sharing this.
___________________________________________________________________
(page generated 2022-10-11 23:00 UTC)