
InboxSDK – Build apps inside Gmail - aloukissas
https://www.inboxsdk.com/
======
walty8
I am the author of Simple Gmail Notes (a free extension for Chrome and FF).
When I started to develop the extension years ago, I did some research of
InboxSDK and Gmail.js. I am not sure if it's still true now, but at that time
when I use the SDK I need to load a remote and minified JS file hosted at the
Streak server, which seems not a good idea for security concerns. I don't
think Streak will try to steal the data in purpose, but still... Also, I
wonder if that might cause problems with extension verification nowadays. Both
FF and Chrome has more strict safety policies now.

I then tried to use Gmail.js for a while, but it seems not that stable, the
extension got a lot of complaints of not working from time to time (Gmail.js
cannot load email data correctly, but not every time).

After a few months, I finally decided to parse the DOM data myself, it's
actually not THAT difficult, if you are not trying to build an extremely
powerful extension.Gmail.com did change the UI from time to time, but it's not
that huge actually. For the latest big UI change on Gmail, I remember it took
me about 1MD to finish all the required code changes.

~~~
aaanotherhnfolk
We also decided not to use InboxSDK because it has to dynamically load from
Streak's servers. If you are open source hobby project this is probably okay,
but for a real business this is a potentially business-ending risk.

What do you do if Streak's servers go down? You pay them nothing and have no
priority support.

What do you do if Streak pushes a breaking change and brings down your app in
real time?

What about if Chrome Web Store continues to lock down the ecosystem and
restricts all dynamic script loading from cross origins?

We only needed a fraction of InboxSDK's API footprint so we just built our own
adapter layer similar to theirs covering what we need. Now we control our own
destiny.

I think their SDK had a better value prop when Google was maintaining both
Gmail and Inbox. But now that they've merged there's only one DOM to worry
about. And let me just say from experience that Google alters the Gmail DOM
very rarely. I think they know there are a ton of extensions leaning on it,
which is why they communicated the new UI so far in advance.

~~~
alooPotato
Hey founder of Streak (authors of the InboxSDK) - sorry the SDK didn't meet
your need. See one of my other comments about why we remote load (its so that
we can react to Gmail changes without all the extension developers needing to
update their extensions AND to guarantee compatibility between extensions).

Will try to address some of your questions:

> What do you do if Streak's servers go down? You pay them nothing and have no
> priority support.

It's a fair concern, we don't charge for the SDK. But we do charge for Streak
and have built an 8 figure business. We care a lot about the dependability of
the SDK because we care a lot about our own business. Streak loads the SDK in
the exact same way as other extension developers do and we use the exact same
APIs. We also have large organizations that depend on our uptime (Dropbox,
Hubspot, etc)

> What do you do if Streak pushes a breaking change and brings down your app
> in real time?

We are the most advanced user of the SDK (we use almost all the APIs) so we'd
be breaking ourselves too.

> What about if Chrome Web Store continues to lock down the ecosystem and
> restricts all dynamic script loading from cross origins?

Great question. It is true that they are locking down the remote loading.
InboxSDK currently has an exemption to this rule (as do some other popular and
similar libraries). However, over the long term (think years) we will move
away from remote loading. We're currently working with Google on a solution
that should retain some of the benefits of remote loading, while allowing
Google to statically analyze the SDK for security. It hasn't been finalized
but the SDK will be allowed to continue remote loading until that is in place.
Remember, we have every incentive to make this work for everyone including
ourselves.

------
kalehrishi
We[1] have been using inboxsdk to build integrations of products within gmail.
Initially we had our own system to keep check of changes in gmail DOM
structure and it was expensive to maintain such SDK. Streak has been doing
great job of maintaining it. In 2017 gmail changed complete UI and inboxsdk
seamlessly supported it with minor glitches. There are some tiny glitches on
some days but those are fixed within few hours. Other open source option is
gmail.js which is also a good alternative. However you have to write some
automation test cases to keep check on breaking changes in gmail Dom

[1] [https://www.vshsolutions.com/](https://www.vshsolutions.com/)

------
rubyn00bie
Yeah... this is gonna be a big "no" from me, dawg.

There's probably a segment of small mid-sized businesses to prey upon making
apps with this; but outside of that this has got to be the most terrifying
platform to ever build upon.

1\. It's based on a specific email provider.

2\. That provider is google.

3\. Google has zero incentive to give a shit about about anyone or anything
using its platform.

4\. Average SDK releases per week: 12 (screw the fact GMail hasn't been
responsible for breaking changes)

Focusing on a tool that does this shit, on any platform, or one that
integrates into any email provider... that'd be neat. This I am afraid of...

~~~
cercatrova
People use Gmail. They don't care about portability as long as it just works.

~~~
rubyn00bie
Not trying to be a huge ass here, but that's what I meant with this:

> probably a segment of small mid-sized businesses to prey upon making apps
> with this

There's a bunch of poorly run, but funded start ups, and mid sized businesses,
that are literally powered by excuses. Very likely anything built with this is
powering the train of excuses, not solutions. I'd go so far as to point out
that Streak made it... Meaning they're obviously trying to branch out because
their market isn't shit; which means, your potential market, is a segment of
shit... (well as far as this site's scaling model is concerned).

If you want a lifestyle business (which I think is perfectly freakin'
awesome)... sure, maybe (read: not) this is for you. But even then... it's a
lot of risk for something you could probably do with one or two people. Just
look at the fucking SDK changes; yeah GMail doesn't necessarily break shit,
but... they (streak) do. How is that any better than your own set of brittle
scripts which you have to maintain multiple times a week?

I think this is a gimmick at best, and at worst it'll completely waste
someone's time and money.

~~~
alooPotato
Founder of Streak here and, as you pointed out, we authored the InboxSDK.

Just to clarify a few things, our market is actually great, the CRM industry
is huge and we do very well in it - we're profitable!

As for why we made the SDK, we're not "branching" out - we made this for
ourselves because we needed it. We built a bunch of tech to wrangle Gmail and
the way we engineered it is we separated it from our main business logic. We
didn't want others to have to go through what we did (reverse engineering a
lot of gmail) so we made it available for anyone to use. We don't charge for
it and we maintain it for free.

Several large companies (Dropbox, HubSpot, etc) depend on this SDK to power
their Gmail integrations so it's not just small and medium sized companies.

Your comment was a bit harsh, but I guess that means we need to address this
stuff better on our website.

~~~
godzillabrennus
My startup built a chrome extension for Gmail before inboxsdk and it broke
every time there was a google change.

So glad you guys brought your solution to the world as freeware so scrappy
startups like mine could avoid having to chase all those updates.

------
etaioinshrdlu
This sounds suspiciously like a way to help developers write Chrome extensions
that steal the user's data. (While perhaps also providing other useful
functionality.)

Gmail is known to have been locking down actual front-door server-side API
access for 3rd party applications for years. Perhaps this is the natural
result. Chrome extensions that add hacks to the Gmail frontend instead.

Same user-data harvesting but with less reliability! Fun times.

~~~
aaanotherhnfolk
If you install any browser extension and give it host permission to a URL (or
God forbid, all_urls) it can see and steal anything on that page.

This goes for everything from your pop-up blocker, to your password manager,
to that silly user script doing <fun effect>. They all watch you browse in a
way that circumvents good security hygiene.

It's extremely common for extensions with successful userbases (>10k installs)
to get approached by folks asking to integrate a mining SDK for revenue share,
or sell the extension outright so they can monetize it themselves.

Consider yourself lucky if all the extension does is steal cpu cycles. It
could just as easily be exfiltrating your email bodies or watching all
password input fields.

The browser extension model is broken. Expect it to slowly die. Manifest v3 is
just the beginning. Soon Google will wonder why they're paying a team of
manual reviewers to study every extension on the Web Store when the
marketplace monetizes so poorly and doesn't contribute to the moat around
Chrome.

------
echan00
Love this. I would want to know whether this will be continued to be
maintained by streak tho. And what happens if they don't or change their mind.

~~~
biot
Streak is 100% built on top of this (source: I work at Streak), so maintaining
this is essential to staying in business.

------
adambatkin
The InboxSDK website does not work in Firefox (tons of JS errors, and visually
it looks like it vomited a bunch of oversized images all over my browser
window).

How could anyone trust a company to do a good job working with really
complicated web technologies, when they can't even do a simple website to
advertise their product?

~~~
alooPotato
Yeah sorry about that - we've got some work to do to update our docs to a
better format. We might just move to readme.io or similar.

Also, we don't officially support Firefox yet.

~~~
gkoberger
Hey! I'm the founder of ReadMe, and we'd love to have you :) We can help with
the technical docs and let you focus on the API itself

------
raynguyen
InboxSDK is a great set of tools for people looking to build on top of gmail.
Does anyone know if there anything like Inbox SDK that support
outlook/office365?

~~~
juped
Unlike Google, Microsoft actually has APIs, so you can use those. Depends on
the project, though.

Since Google's fans ironically can't Google, docs below:

[https://docs.microsoft.com/en-us/office/dev/add-
ins/](https://docs.microsoft.com/en-us/office/dev/add-ins/)

is the modern typescript/web API. It's not totally feature-complete (yet), so
you may need to develop a VSTO add-in in C# or VB, which will unfortunately
not work with the web client. Docs for that:

[https://docs.microsoft.com/en-us/visualstudio/vsto/create-
vs...](https://docs.microsoft.com/en-us/visualstudio/vsto/create-vsto-add-ins-
for-office-by-using-visual-studio)

~~~
davidcbc
[https://developers.google.com/gmail/api/v1/reference](https://developers.google.com/gmail/api/v1/reference)

~~~
juped
Thanks for linking a completely irrelevant API.

------
ledovi
People are comfortable about installing third party extensions that have
complete access to their emails' DOM.

------
foreigner
I want something like this for Facebook!

------
arjun27
Seems to be closed source?

~~~
alooPotato
Founder of Streak (author of the InboxSDK) here. Yes we made the difficult
choice to close source this. One of the big value props of the SDK is that it
automatically maintains compatibility with Gmail _and_ all other extensions
using the SDK.

The way we ensure this is by remote loading most of the SDK from our servers
to ensure users are on the latest version of the SDK.

One thing we wanted to prevent was developers including the stock SDK directly
in the extension or even forking their own version and including it in their
extension because then we can't guarantee it will always be compatible with
other extensions or Gmail. We'd have to rely on developers constantly
upgrading their dependency on us and submitting an extension update to the
chrome store.

There are ways where we can still host the SDK but open source it so people
can contribute/inspect the code - we just haven't gotten there yet but it is
part of our plans.

~~~
wearhere
Folks should know that this approach will not accommodate upcoming changes to
Chrome extensions, which will disallow all remotely-hosted code:
[https://groups.google.com/a/chromium.org/d/msg/chromium-
exte...](https://groups.google.com/a/chromium.org/d/msg/chromium-
extensions/hQeJzPbG-js/U8DSIl6IDAAJ). More up-to-date guide here
[https://developer.chrome.com/extensions/migrating_to_manifes...](https://developer.chrome.com/extensions/migrating_to_manifest_v3),
with a timeline of 2020. I understand why

> one thing we wanted to prevent was developers including the stock SDK
> directly in the extension

(and I feel for Streak, having worked on a Gmail extension (Mixmax) until
recently), but this seems to be exactly what manifest v3 will require. Curious
if you have another strategy, @alooPotato.

~~~
alooPotato
Cross posting from another comment:

It is true that they are locking down the remote loading. InboxSDK currently
has an exemption to this rule (as do some other popular and similar
libraries). However, over the long term (think years) we will move away from
remote loading. We're currently working with Google on a solution that should
retain some of the benefits of remote loading, while allowing Google to
statically analyze the SDK for security. It hasn't been finalized but the SDK
will be allowed to continue remote loading until that is in place. Remember,
we have every incentive to make this work for everyone including ourselves.

------
dominotw
anyone know if something similar is available for outlook.office.com

------
admax88q
Yay! Another platform Google can abandon after I invest a bunch if work into
it!

~~~
alooPotato
To be clear, this is not made by Google, its made by us, Streak

------
monadic2
What’s wrong with a normal API?

~~~
alooPotato
The gmail api is a backend API, this SDK lets you integrate into the frontend.

~~~
monadic2
Dam one day we will have an improvement to imap.... not today it looks like :(

~~~
manigandham
That's already here and called JMAP, created by the Fastmail team:
[https://jmap.io/](https://jmap.io/)

Also this InboxSDK is for integrating in the Gmail webapp UI which many people
use and want to stay within when adding functionality to their email service.

