Show HN: InboxSDK by Streak (YC S11) – Build Apps inside Gmail(inboxsdk.com)
inboxsdk.com
Show HN: InboxSDK by Streak (YC S11) – Build Apps inside Gmail
https://www.inboxsdk.com
62 comments
This is pretty cool!
What I am really dying/desperate for is a group chat feature within Gmail where the chat rooms are permanent. I thought it was the biggest opportunity for years. Slack built a billion $ plus business of group chat outside of gmail. I am sure there is a reasonable sized opportunity for group chat within Gmail!
What I am really dying/desperate for is a group chat feature within Gmail where the chat rooms are permanent. I thought it was the biggest opportunity for years. Slack built a billion $ plus business of group chat outside of gmail. I am sure there is a reasonable sized opportunity for group chat within Gmail!
We rebuilt the Gmail integration portion of our Screenleap extension using InboxSDK and reduced the size of our implementation from a bunch of files to 120 lines of code (the InboxSDK integration portion is only 10 lines). Would've saved a month of work if this was available the first time around!
Besides not having to keep up with breaking changes in Gmail, another really nice benefit of using InboxSDK is that you don't have to keep updating your extension to make sure that it plays nice with other extensions. This was an unexpected and on-going source of development work for us previously.
Looking forward to the Google Calendar integration :)
Besides not having to keep up with breaking changes in Gmail, another really nice benefit of using InboxSDK is that you don't have to keep updating your extension to make sure that it plays nice with other extensions. This was an unexpected and on-going source of development work for us previously.
Looking forward to the Google Calendar integration :)
You give the code in a .js file that you include in a browser plugin but, you don't state clearly whether this is or is not an open source project. The .js file has no license in it either.
File: https://www.inboxsdk.com/build/inboxsdk.js
Then I see the github page: https://github.com/InboxSDK/
There is no InboxSDK project but, just two example chrome plugins using the inboxSDK.
All the trappings and mechanics of open source without the actual source and an actual open source license. Are you guys just testing this to see if you can productize it? Or are you going to go all the way and open source this?
File: https://www.inboxsdk.com/build/inboxsdk.js
Then I see the github page: https://github.com/InboxSDK/
There is no InboxSDK project but, just two example chrome plugins using the inboxSDK.
All the trappings and mechanics of open source without the actual source and an actual open source license. Are you guys just testing this to see if you can productize it? Or are you going to go all the way and open source this?
Thanks for this.
We're adding licenses to our examples that we have on GitHub and we're also adding a pointer from our inboxsdk.js file to our terms of service.
Over a longer time horizon, we plan on open sourcing the entire implementation of the InboxSDK but just not yet.
We're adding licenses to our examples that we have on GitHub and we're also adding a pointer from our inboxsdk.js file to our terms of service.
Over a longer time horizon, we plan on open sourcing the entire implementation of the InboxSDK but just not yet.
You do realize that any client-side code – especially with the universal right to decompile and adapt code in the EU – is essentially open source anyway?
I can't comment on EU law but the ability to redistribute the (modified) code is also a defining characteristic of open source http://en.wikipedia.org/wiki/Open_source
Yes, but reverse engineered code is NOT subject to copyright of the original author by law (there is an EuGH decision about this). IANAL.
Therefore it is, essentially, open source.
Therefore it is, essentially, open source.
I understand why this view point can be wrong. But instead of just downvoting him. Why not give a link or two, to correct him?
I guess you don't care to provide a link or two either?
(I don't know what you're talking about.)
(I don't know what you're talking about.)
some more info on this here https://www.inboxsdk.com/terms
Founder of Streak (YC S11) here - we built the InboxSDK using all of the work we've put into making Streak work great inside of Gmail.
Happy to answer any questions about the SDK.
Happy to answer any questions about the SDK.
Wow, this is amazing! Thank you for doing this! I honestly believe this is could be the most impactful innovation to come to the email space in years.
InboxSDK was obviously a ton of work. What is your business model for it?
InboxSDK was obviously a ton of work. What is your business model for it?
Well the great part about us working on the InboxSDK is that we need it ourselves for Streak. We were already doing a lot of the work and we wanted to more cleanly separate our business logic from our Gmail wrangling. As we add support to the SDK for Google's Inbox client, Streak and other apps built on the SDK will run inside of Google's Inbox for free and automatically.
As for business model, we aren't really thinking about that too much, we just knew how much pain ppl went through making gmail apps and just knew that the SDK needed to exist. We don't plan on charging for it.
We've talked a lot about doing an appstore inside gmail. The idea being that apps could opt in to be in the appstore. If you opt-in then your app automatically adds the appstore to your users gmail experience. That would help drive traffic to apps. Once a user installs any one of the apps, they have access to all the other apps in the appstore.
As for business model, we aren't really thinking about that too much, we just knew how much pain ppl went through making gmail apps and just knew that the SDK needed to exist. We don't plan on charging for it.
We've talked a lot about doing an appstore inside gmail. The idea being that apps could opt in to be in the appstore. If you opt-in then your app automatically adds the appstore to your users gmail experience. That would help drive traffic to apps. Once a user installs any one of the apps, they have access to all the other apps in the appstore.
Great job and initiative! Gmelius Founder here. A few questions:
i) Are you planning to make the whole implementation Open Source?
ii) Say I wish to adopt and use your SDK in my current Gmail/Inbox extensions (>100K daily users), may I expect the implementation of a fixed upper limit on the number of transmissions in the coming months (which could endanger the reliability of my service for my users)?
iii) While the SDK currently only focuses on the UI, are you planning to add more "complex" interactions, such as Gmail filters/Gmail preferences ? If yes, feel free to get in touch. I will be happy to help.
Congrats, again.
i) Are you planning to make the whole implementation Open Source?
ii) Say I wish to adopt and use your SDK in my current Gmail/Inbox extensions (>100K daily users), may I expect the implementation of a fixed upper limit on the number of transmissions in the coming months (which could endanger the reliability of my service for my users)?
iii) While the SDK currently only focuses on the UI, are you planning to add more "complex" interactions, such as Gmail filters/Gmail preferences ? If yes, feel free to get in touch. I will be happy to help.
Congrats, again.
i) Our long term plan is to do so, but not in the immediate term.
ii) The SDK loads a static JS file so we aren't really worried about having a lot of users requesting that. We're hosting the SDK on appengine so I wouldn't expect any caps on users or anything like that. Dropbox has a ~500K weekly actives (as you can see from the chrome webstore: https://chrome.google.com/webstore/detail/dropbox-for-gmail-...) using it and I expect that to grow.
iii) can you describe the use case a bit more? Specifically are you looking to get the set of filters or add new ones or both? On the preferences side, are you looking to add your own? We have this functionality in Streak but haven't yet ported it over to the SDK (but will soon)
ii) The SDK loads a static JS file so we aren't really worried about having a lot of users requesting that. We're hosting the SDK on appengine so I wouldn't expect any caps on users or anything like that. Dropbox has a ~500K weekly actives (as you can see from the chrome webstore: https://chrome.google.com/webstore/detail/dropbox-for-gmail-...) using it and I expect that to grow.
iii) can you describe the use case a bit more? Specifically are you looking to get the set of filters or add new ones or both? On the preferences side, are you looking to add your own? We have this functionality in Streak but haven't yet ported it over to the SDK (but will soon)
What prevents Google closing the door on this?
Well, nothing really. But thats true for almost anything.
We think you can trust the platform because we're fundamentally making Gmail better and more valuable to Google's users. There are a handful of successful businesses (like Streak and others) already built on top of gmail and have been for years. These venture backed companies already trust their business to be on top of Gmail. We're just making the process of building these apps waaaay easier.
We take security and performance really really seriously. Because our SDK helps you build Chrome extensions for Gmail, Google can (and has) shut down shady apps from the Chrome Webstore, so they don't have to shutdown the entire platform to get rid of a bad actors.
We think you can trust the platform because we're fundamentally making Gmail better and more valuable to Google's users. There are a handful of successful businesses (like Streak and others) already built on top of gmail and have been for years. These venture backed companies already trust their business to be on top of Gmail. We're just making the process of building these apps waaaay easier.
We take security and performance really really seriously. Because our SDK helps you build Chrome extensions for Gmail, Google can (and has) shut down shady apps from the Chrome Webstore, so they don't have to shutdown the entire platform to get rid of a bad actors.
A well rounded answer, but I'll pass for now. If Google really believed in your ethos of making the software more valuable via third parties, their platform wouldn't require dom hacks that could break without notice. i.e. they'd open up their own APIs to make building these sorts of apps themselves.
I absolutely commend you for what you are doing, I just wouldn't be willing as a developer to dip my toes in that particular water to spend the time developing something they could rip apart and break.
As a side note, the documentation page is broken on Mac Safari 8 on OSX Javascript error:
TypeError: undefined is not a function (evaluating 'reference.endsWith('()')')
I absolutely commend you for what you are doing, I just wouldn't be willing as a developer to dip my toes in that particular water to spend the time developing something they could rip apart and break.
As a side note, the documentation page is broken on Mac Safari 8 on OSX Javascript error:
TypeError: undefined is not a function (evaluating 'reference.endsWith('()')')
Sure Google could break this (maliciously or otherwise), but would you rather have to keep up with their changes on your own, or build something that works on InboxSDK, and let them play cat-and-mouse with the Inbox DOM? Worst case in the latter scenario is that a feature is down for as long as it takes for a fix to be released.
I'd rather target open standards, like client-side SMTP/IMAP.
Thanks for the safari bug. fixing...
I'm sure you guys have already figured this out by now, but you just need to add a polyfill for `endsWith` since Safari doesn't implement the ECMAScript 6 spec.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I think they(infosdk) are offering an easy way to create browser extensions to interact with Gmail.
Google will need to do something really intrusive to break their SDK
Google will need to do something really intrusive to break their SDK
Very cool wrappers, I've used Streak off and on for a while and definitely appreciate how well it integrates with gmail.
Do you have any notion of how fragile things are when dom-hacking? Do you have to constantly keep up with google's updates or are things fairly stable? i.e. how often will I need to update and/or patch an extension to maintain support (in your experience so far)?
Do you have any notion of how fragile things are when dom-hacking? Do you have to constantly keep up with google's updates or are things fairly stable? i.e. how often will I need to update and/or patch an extension to maintain support (in your experience so far)?
We have systems in place to make sure we catch any changes to the DOM. We usually see these changes before 99% of gmail users and can make any necessary changes within minutes usually.
In the last 6 months we've seen 0 breaking changes, 1 in the 6 months before that (it was fixed before the change even reached users), and 2 in the prior 12 months (where our fix reached product in sub 10 minutes).
In the last 6 months we've seen 0 breaking changes, 1 in the 6 months before that (it was fixed before the change even reached users), and 2 in the prior 12 months (where our fix reached product in sub 10 minutes).
> where our fix reached product in sub 10 minutes
Wow. Nicely done!
Wow. Nicely done!
Why don't you host the source code on GitHub?
If anyone wants to go a different route, Gmail has a fairly complete REST API [1].
[1] https://developers.google.com/gmail/api/
[1] https://developers.google.com/gmail/api/
Yup - this is great for getting at some of the backend data in gmail, the InboxSDK is designed to let you build apps inside the Gmail frontend experience.
We've been building our Gmail app over at http://CloseFox.com with InboxSDK and have really been enjoying it!
Definitely a lot better than using gmail.js
Definitely a lot better than using gmail.js
Creator of gmail.js here. Can confirm
Gmail.js is pretty great too.
We're trying to take a slightly more higher level approach but there's def still a few things we're missing that gmail.js does have.
We're trying to take a slightly more higher level approach but there's def still a few things we're missing that gmail.js does have.
Any chance of collaboration between the two projects?
Your intro video is waaaay too long, and after looking at it I am not even sure it was an intro video. The email written in the beginning, it never came back to it.
Lost interest halfway through, I think (there are no controls).
Lost interest halfway through, I think (there are no controls).
Streak's InboxSDK is the missing link to augmenting gmail's functionality. Gmail is a rich product that always seems to be changing silently. The Streak team does a fantastic job maintaining the SDK so that their changes automatically get pulled in, no need for us to release a new version of the extension.
We used InboxSDK to create part of our DocSend Chrome extension. Our power users who are in gmail 24/7 can't live without it. Thanks to Streak for helping us enable our user base and keep happy customers happy! :)
We used InboxSDK to create part of our DocSend Chrome extension. Our power users who are in gmail 24/7 can't live without it. Thanks to Streak for helping us enable our user base and keep happy customers happy! :)
Can anyone explain how this is different from Google's Gmail Contextual Gadgerts? https://developers.google.com/gmail/contextual_gadgets#what_...
I'm looking to build a plugin that can automatically send a mail back under specific conditions and allows follow-ups, but I'm not sure what tech I should use.
I'm looking to build a plugin that can automatically send a mail back under specific conditions and allows follow-ups, but I'm not sure what tech I should use.
In my experience (I've built a gadget for our internal use, to create tickets on our software from emails), the gadgets are fairly limited, both in terms of the content they can access (only the first 1000 characters, and no attachments) and in terms of UI (you get a small bar below the email - no integration with the rest of the interface).
Even for our simple use case, which is essentially a button that makes an HTTP request to a web service with the email fields, it felt limited.
It also suffers from poor debugging tools. They made some changes that broke our gadget (I think it was the deactivation of OAuth 1.0) and there's no way of knowing why it isn't loading, it just doesn't.
Even for our simple use case, which is essentially a button that makes an HTTP request to a web service with the email fields, it felt limited.
It also suffers from poor debugging tools. They made some changes that broke our gadget (I think it was the deactivation of OAuth 1.0) and there's no way of knowing why it isn't loading, it just doesn't.
Reading https://www.inboxsdk.com/terms it says this SDK is royalty-free. Is there any additional important licensing issue to take into account before using it?
How does this compare with Nylas (https://nylas.com), who claims they're the "next generation email platform"?
Nylas is really cool.
If I remember correctly they are building a base email application that can be extended with plugins (like the atom editor). This does require people to adopt their email client.
The InboxSDK takes a different approach in that it lets you extend Gmails functionality and write apps for Gmail. End users don't have to switch their email client (assuming their using the gmail web client)
If I remember correctly they are building a base email application that can be extended with plugins (like the atom editor). This does require people to adopt their email client.
The InboxSDK takes a different approach in that it lets you extend Gmails functionality and write apps for Gmail. End users don't have to switch their email client (assuming their using the gmail web client)
Well done! I just hope that proper alternatives to customer support services take the chance to surface. It's insane to see how they replicate 3/4 of gmail/another-email-ui functionality just because they add 10% extra functionality to streamline communication with customers (e.g. multi-language canned responses, etc).
Build on top, reuse, don't copy-paste!
Build on top, reuse, don't copy-paste!
If you are interested in this kind of hacks you can't miss Add-In-Express [1] and my company's Windows Live Mail, Windows Mail, and Outlook Express APIs that created SDKs around closed source products for more than 10 years.
[1] https://www.add-in-express.com/
[1] https://www.add-in-express.com/
Neat idea but I don't get how it works with feature rollouts. If Gmail is updated which changes the DOM and breaks the API how does the SDK handle being updated when it's rarely a change that's rolled out instantly for all users (usually takes some time maybe even weeks). I mean you either have a TON of feature testing to figure it out or you let it break; neither of which seems very maintainable to me.
What's going to happen with the rumored update? I've been hearing rumors for over a year now that gmail, calendar, contacts and even tasks are being majorly overhauled; is there any collaboration with Google to make sure when (or if) these rumors come true that it won't simply break everything day one?
Trying not to be a nay sayer; this is a great idea if you want to quickly add something to Gmail without messing with the Gmail DOM yourself but it doesn't seem to be a good long term bet to me.
What's going to happen with the rumored update? I've been hearing rumors for over a year now that gmail, calendar, contacts and even tasks are being majorly overhauled; is there any collaboration with Google to make sure when (or if) these rumors come true that it won't simply break everything day one?
Trying not to be a nay sayer; this is a great idea if you want to quickly add something to Gmail without messing with the Gmail DOM yourself but it doesn't seem to be a good long term bet to me.
Serious question: How would this handle changes in Gmail?
Google is the platform owner and may change it without prior notice. My interest is in understanding how would someone using this sdk would be impacted.
Google is the platform owner and may change it without prior notice. My interest is in understanding how would someone using this sdk would be impacted.
We (streak) keep the SDK up to date. The JavaScript you put in your extension remotely loads the actual implementation of the SDK. If gmail changes, we change the implementation (fast) and your users get the change automatically. You the app developer dont need to do anything or even update your extension.
Any blog post that explains this a but further? It should be an interesting read, given that I assume you track changes and update programatically (to a degree).
I've had an idea for a Gmail app I've been wanting to build for a while now. Super easy but I need some help getting it built. This is pretty much a layup in my opinion.
Any tips on how to integrate this with FE frameworks like Angular? Unit/e2e testing?
Thanks for making this.
Thanks for making this.
Cofounder of Streak and helped write a lot of the InboxSDK. I can't give a definitive answer right now because we don't use Angular and thus don't have much experience with it. If you're able to specify a DOM node as the root of an Angular instance then you should be able to make it work.
If you try to make the top html tag as your root you'll probably run into a bad time particularly if other extensions make the same assumption. One major difference between writing an app for Gmail vs your own app is that multiple apps can and usually are running at the same time. This was one of the main motivations behind the SDK since many of our bug reports were a result from extension compatibility issues.
We do e2e testing with selenium/webdriver - so it's definitely doable. Tip for e2e testing is to pay for some extra Google Apps accounts so you can run your tests in parallel.
If you try to make the top html tag as your root you'll probably run into a bad time particularly if other extensions make the same assumption. One major difference between writing an app for Gmail vs your own app is that multiple apps can and usually are running at the same time. This was one of the main motivations behind the SDK since many of our bug reports were a result from extension compatibility issues.
We do e2e testing with selenium/webdriver - so it's definitely doable. Tip for e2e testing is to pay for some extra Google Apps accounts so you can run your tests in parallel.
Does this mean I can have a SIGNATURE in Inbox now? If so, how? (I'm using Safari, so there hasn't been any way that I know of to use a signature, which is the one dealbreaker for me to use Inbox, which I love)
I would love for such and SDK for Google Maps. It's ubiquitous and I'm always trying to catch up with API breakage. Is there something like that?
Nice! Was thinking about building a Gmail counterpart for Donald in the future, looks like this will simplify/speed up development for that.
Dear Gmail Team: Why haven't you acquired this team yet (Streak)?
Any plans to support exchange in future?
Sorry not at the moment. Actually Outlook has a really great API to write JS/HTML based apps for their desktop client, web client and mobile client. See https://dev.outlook.com/MailAppsGettingStarted/GetStarted
Some marketing: We are actually providing a Javascript wrapper for most of the official Outlook API, much more fully featured (incl. ribbons):
http://developer.yasoon.com/
I'm confused why people see this as "revolutionary". At the core of it, this is just an abstraction around DOM-hacking. Anyone could have done this, and it is foolish to call such an "innovation" revolutionary.
It's a well maintained schlep of a DOM hacking API that makes complex interaction in a hugely important installed base of 1 billion users (previously nearly impossible) possible. Just because you understand the mechanism doesn't mean you should demean the herculean efforts of other good hackers.
Also innovation isn't the idea. Innovation is actually implementing it.
Also innovation isn't the idea. Innovation is actually implementing it.
I have a hard time following this reasoning. Of course almost anything new could have been done by anyone. The nature of invention and innovation is that someone figured something out. People could have (and did) say the same thing about Facebook, Dropbox, and a number of other "revolutionary" companies/products. What matters is that someone did it and is packaging it in a way to solve problems and improve the lives of others.
Perhaps "revolutionary" is just marketing fluff, but why get hung up on subjective semantics?
Perhaps "revolutionary" is just marketing fluff, but why get hung up on subjective semantics?
This is a total game-changer. Very excited to see what the inbox will become thanks to the Streak team.
Cheers!
And of course you can check out the DocSend extension here to get insight into page-by-page engagement with your document attachments :) https://chrome.google.com/webstore/detail/docsend-extension-...