8 ms·

InboxSDK – Build apps inside Gmail

109 points by aloukissas 7y ago

echan00 7y ago
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.
- beders 7y ago
  So far they haven't and it's been a few years. The true question is: when is GMail changing its CSS class names ;)
- biot 7y ago
  Streak is 100% built on top of this (source: I work at Streak), so maintaining this is essential to staying in business.
- alooPotato 7y ago
  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.
arjun27 7y ago
Seems to be closed source?
- alooPotato 7y ago
  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 7y ago
    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-extensions/hQeJzPbG-js/U8DSIl6IDAAJ https://groups.google.com/a/chromium.org/d/msg/chromium-exte.... More up-to-date guide here https://developer.chrome.com/extensions/migrating_to_manifest_v3 https://developer.chrome.com/extensions/migrating_to_manifes..., 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 7y ago
      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.
rubyn00bie 7y ago
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 7y ago
  People use Gmail. They don't care about portability as long as it just works.
  - Kaze404 7y ago
    Considering how long it takes to become interactive on anything that's not Chrome, I'd hardly call it a working product.
    - vntok 7y ago
      Use the right tool for the right job.
      - Kaze404 7y ago
        Chrome is not the right tool because it was specifically built for Gmail. It's the right tool because Google hates competition.
  - rubyn00bie 7y ago
    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.
admax88q 7y ago
Yay! Another platform Google can abandon after I invest a bunch if work into it!
- alooPotato 7y ago
  To be clear, this is not made by Google, its made by us, Streak
kalehrishi 7y ago
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/
monadic2 7y ago
What’s wrong with a normal API?
- alooPotato 7y ago
  The gmail api is a backend API, this SDK lets you integrate into the frontend.
  - monadic2 7y ago
    Dam one day we will have an improvement to imap.... not today it looks like :(
    - manigandham 7y ago
      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.
etaioinshrdlu 7y ago
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 7y ago
  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.
walty8 7y ago
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.
- josteink 7y ago
  > I then tried to use Gmail.js for a while, but it seems not that stable Unlike InboxSDK, Gmail.js is open source. You actually do have the power to fix things if you like. I think that’s an important difference. I’ve fixed things in Gmail.js when I needed them fixed. Have you?
  - walty8 7y ago
    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.
- 7y ago
deleted 7y ago
[deleted]
foreigner 7y ago
I want something like this for Facebook!
adambatkin 7y ago
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 7y ago
  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 7y ago
    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
ledovi 7y ago
People are comfortable about installing third party extensions that have complete access to their emails' DOM.
raynguyen 7y ago
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 7y ago
  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-vsto-add-ins-for-office-by-using-visual-studio https://docs.microsoft.com/en-us/visualstudio/vsto/create-vs...
  - davidcbc 7y ago
    https://developers.google.com/gmail/api/v1/reference https://developers.google.com/gmail/api/v1/reference
    - juped 7y ago
      Thanks for linking a completely irrelevant API.
- dominotw 7y ago
  they seem to have this https://docs.microsoft.com/en-us/office/dev/add-ins/overview/office-add-ins https://docs.microsoft.com/en-us/office/dev/add-ins/overview...
dominotw 7y ago
anyone know if something similar is available for outlook.office.com

109 points by aloukissas 7y ago

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.

beders 7y ago
So far they haven't and it's been a few years. The true question is: when is GMail changing its CSS class names ;)
biot 7y ago
Streak is 100% built on top of this (source: I work at Streak), so maintaining this is essential to staying in business.
alooPotato 7y ago
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.

arjun27 7y ago

Seems to be closed source?

alooPotato 7y ago
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 7y ago
  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-extensions/hQeJzPbG-js/U8DSIl6IDAAJ https://groups.google.com/a/chromium.org/d/msg/chromium-exte.... More up-to-date guide here https://developer.chrome.com/extensions/migrating_to_manifest_v3 https://developer.chrome.com/extensions/migrating_to_manifes..., 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 7y ago
    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.

rubyn00bie 7y ago

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 7y ago
People use Gmail. They don't care about portability as long as it just works.
- Kaze404 7y ago
  Considering how long it takes to become interactive on anything that's not Chrome, I'd hardly call it a working product.
  - vntok 7y ago
    Use the right tool for the right job.
    - Kaze404 7y ago
      Chrome is not the right tool because it was specifically built for Gmail. It's the right tool because Google hates competition.
- rubyn00bie 7y ago
  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.

admax88q 7y ago

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

alooPotato 7y ago
To be clear, this is not made by Google, its made by us, Streak

kalehrishi 7y ago

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/

monadic2 7y ago

What’s wrong with a normal API?

alooPotato 7y ago
The gmail api is a backend API, this SDK lets you integrate into the frontend.
- monadic2 7y ago
  Dam one day we will have an improvement to imap.... not today it looks like :(
  - manigandham 7y ago
    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.

etaioinshrdlu 7y ago

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

walty8 7y ago

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.

josteink 7y ago
> I then tried to use Gmail.js for a while, but it seems not that stable Unlike InboxSDK, Gmail.js is open source. You actually do have the power to fix things if you like. I think that’s an important difference. I’ve fixed things in Gmail.js when I needed them fixed. Have you?
- walty8 7y ago
  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.
7y ago

deleted 7y ago

[deleted]

foreigner 7y ago

I want something like this for Facebook!

adambatkin 7y ago

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 7y ago
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 7y ago
  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

ledovi 7y ago

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

raynguyen 7y ago

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 7y ago
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-vsto-add-ins-for-office-by-using-visual-studio https://docs.microsoft.com/en-us/visualstudio/vsto/create-vs...
- davidcbc 7y ago
  https://developers.google.com/gmail/api/v1/reference https://developers.google.com/gmail/api/v1/reference
  - juped 7y ago
    Thanks for linking a completely irrelevant API.
dominotw 7y ago
they seem to have this https://docs.microsoft.com/en-us/office/dev/add-ins/overview/office-add-ins https://docs.microsoft.com/en-us/office/dev/add-ins/overview...

dominotw 7y ago

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