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.
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.
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.
Yes，I did fix a few. However, there are two places I am uncomfortable with gmail.js (again, that's a few years ago):
1. I remember it greatly depend on hijack of a global variable in Gmail.com, but occasionally the value is not available (depend on where the user refreshed the page and network speed of the user)
2. it try to send network requests to Gmail.com directly (on behalf of logged in Gmail user) and get the query result, but those API are supposed to be used only by Gmail.com internally. So once the API format changes, some data could not be collected.
In general I think this approach raised too much dependency on misc aspects of Gmail.com. Now customized DOM parsing also depend on Gmail UI, but that should be the ONLY thing that would break the system.
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
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...
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.
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.
"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)."
I've read this sentence a couple times and have no clue what you're trying to say. By this logic anyone who uses AWS is working in a "shit" market, which is not the case.
"it's a lot of risk for something you could probably do with one or two people"
Have you ever tried to do this? It is harder than you might think. In addition, one or two people will cost ~300k/year which is a lot.
Your comment is ridiculously dismissive and poorly argued.
let's see if it lasts. their product is great, i tried it out, but the value it brought me was not worth the money i spent + my email being on their servers
Companies who want to be integrated everywhere often have to write a lot of product-specific integrations.
Outlook, Office365 etc... And Gmail because Gmail is big.
> screw the fact GMail hasn't been responsible for breaking changes
As someone contributing to Gmail.js, allow me to absolutely counter this claim.
The change to “new” Gmail took months of effort to properly reverse-engineer, and there’s been small changes in behaviour since launch which breaks stuff some of the time.
While there are people that would stay away from G, there are even more that choose G because "nobody ever got fired for chosing G". It is much easier to sell to those ppl if your offering runs on G.
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.
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.
Founder of Streak (author of the InboxSDK) here - and yes we 100% maintain it. We should update the release notes more frequently but we add functionality/fix bugs in the SDK weekly.
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?
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?
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:
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.
> 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.
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.
That's already here and called JMAP, created by the Fastmail team: 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.
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.