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.
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...
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.
[+] [-] walty8|6 years ago|reply
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|6 years ago|reply
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.
[+] [-] josteink|6 years ago|reply
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?
[+] [-] kalehrishi|6 years ago|reply
[1] https://www.vshsolutions.com/
[+] [-] rubyn00bie|6 years ago|reply
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|6 years ago|reply
[+] [-] joelrunyon|6 years ago|reply
[+] [-] josteink|6 years ago|reply
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.
[+] [-] z3t4|6 years ago|reply
[+] [-] Alex3917|6 years ago|reply
You realize it's mostly for enterprise companies building internal tools, right?
[+] [-] etaioinshrdlu|6 years ago|reply
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|6 years ago|reply
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|6 years ago|reply
[+] [-] biot|6 years ago|reply
[+] [-] alooPotato|6 years ago|reply
[+] [-] beders|6 years ago|reply
The true question is: when is GMail changing its CSS class names ;)
[+] [-] adambatkin|6 years ago|reply
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|6 years ago|reply
Also, we don't officially support Firefox yet.
[+] [-] raynguyen|6 years ago|reply
[+] [-] dominotw|6 years ago|reply
https://docs.microsoft.com/en-us/office/dev/add-ins/overview...
[+] [-] juped|6 years ago|reply
Since Google's fans ironically can't Google, docs below:
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...
[+] [-] ledovi|6 years ago|reply
[+] [-] foreigner|6 years ago|reply
[+] [-] arjun27|6 years ago|reply
[+] [-] alooPotato|6 years ago|reply
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.
[+] [-] dominotw|6 years ago|reply
[+] [-] admax88q|6 years ago|reply
[+] [-] alooPotato|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] monadic2|6 years ago|reply
[+] [-] alooPotato|6 years ago|reply