Ha! :) I work at Twilio. In a comparison between the 2: I think are orchestrations are more sophisticated than WUPHF, but we are lacking fax support...
I wonder how this works. Currently there's only a landing page that asks you to request access so I have no idea.
Do developers integrate Twilio SDK into their apps (similar to Fabric, etc.)? If so, sounds like a way different model than what they used to do (Basically you could integrate just by calling their REST endpoint since it was SMS based and required no installation of any app, but with APNS the only way I can see this work is if you tightly integrate with Twilio API by using their SDK)
How do they figure out a number is associated with an account? Does this assume that users will enter their phone numbers when signing up to a service?
Twilio's problem is that they keep growing in features while being forced to maintain stalwart backwards-compatibility WHILE maintaining documentation AND a ~dozen client libraries for all their developers. While they've made a concentrated effort to improve their documentation / interface over the past year, it's not uncommon for documentation to be out-of-date or incorrect or libraries to be confusing (client.messages.new might call the 2009 endpoint and client.newMessage might call the 2014 endpoint, with only the later endpoint accepting SMS bodies <= 1600 characters for example).
With new offerings like Copilot and presumably this, they get a chance at a fresher start BUT unless you want to handle interacting with Twilio's endpoints directly you're going to have to wait for your client libraries to catch up, which might not be a problem with NodeJS, but for instance my company uses a third-party Golang library that's two years old and has only received minor tweaks in the past 6 months. It will probably not be updated with new features soon or ever, and should I want to utilize these new features I would have to extend or re-write the library myself.
Finally Twilio provides no ways of including metadata in an SMS submission (which is a huge freaking oversight) and makes it very difficult to associate a number with an account. The most accepted answer for that problem currently is to use the Twilio number as a foreign key for an account, which a) does not work with Copilot as you have no control over which number will send the message and b) requires each account to have its own ($1) number, which does not scale.
Hi Ben,
I work at Twilio with Notify. Thank you for the feedback. We recently started auto-generating our helper libraries (before it was a manual process.) This let's us ship new products and new features into all of our supported languages very quickly. It also opens up the opportunity to add additional languages. I'd love to hear more about languages you'd like to see (sounds like Go is important, others?) and hear more about how you are using Twilio to see if we have a better solution for you. Drop me an email: bchia [at] twilio [dot] com
Hi, I work at Twilio and can answer questions about Notify. Notify is predominantly a REST API you could access through server-side helper libraries in your favorite language. We have SDKs for Notify as well that provide additional functionality (like the ability to notify the user on the device they were last active one.)
To associate a number (or push registration) with a user you create a "binding"
Maybe i'm missing something but isn't this just like Urban Airship? Basically you need to have an app already in production, and you push through Twilio instead of directly hitting APNS. I do understand the benefits of having a 3rd party manage expired device tokens and sending broadcast push, etc. but having a hard time understanding what's novel about this.
Notify has two unique components compared to other tools in the market. First it is multi-channel- you can send push yes, but also global SMS and notifications into messaging apps like Facebook Messenger, Viber, and WeChat. Second, Notify provides orchestrations- fan out, fall back (push first then SMS if not received), notify on last active or current active device, etc.
The fact that Twilio acts as a registrar is something that was highly requested from our customer base.
I need to build a notifications service for our application, and it would be nice if one of my existing tools like Intercom provided the service instead. I want to be able to send messages of varying levels of urgency - e.g. "send password reset now" vs. "this message should arrive within an hour and can be bundled." The service already has communication details - email, phone, push notification info, maybe even facebook auth. I wish it would intelligently route to the correct notification method based on each user's responsiveness (did they open the email?), cost (can I save money by using push vs. sms?) and available methods (e.g. I don't have a twilio number in their country). An API for marking messages as read via a UI notification center would be cool too.
Message spam is the worst, and building intelligent routing across communication methods is becoming a pain.
> Here is the scenario [Twilio CEO Jeff Lawson] envisions: maybe a user signs up to get SMS from a company (in exchange for a coupon, for example). Then, over time, that user also installs the company’s app on two devices. Now, push notifications allow you to give that user a far better experience, but you don’t want to send both SMS and push notifications to every device the user has the app installed on (that would be annoying, after all). With the new API, you simply set up a rule to send a push notification to the device the user last used (or the one that is currently active) and then fall back on SMS if that doesn’t work.
From the article: "We want customers to reply to messages because we send billions of notifications per month and every one of those should be an opportunity to start a conversation with a customer."
Billions of notifications per month. That's spam.
Now to figure out some way to reroute them all to the CEO's phone.
i think you got downvoted, but... why does it have to be 'spam'?
I get dozens of notifications from various services every day, and I absolutely gave permission or requested them in every case. I get spam email and sms, yes, but of the notifications I get... none are spam.
APN (apple push notify service): Apple lets you route a push notification to a cell phone
FCM (firebase cloud messenger): Google will let you push notifications to either android devices or iOS through APN, transparently abstracting device differences away from you
Twilio Notify: Twilio will send either over SMS or FCM, abstracting the presence of the app install away from you
I know this is a good thing as software gets easier, and I'm aware that all software works through abstraction, but for web services in particular this seems like crazy nested service glue.
20 comments
[ 2.3 ms ] story [ 65.5 ms ] threadhttps://www.google.com/cloudprint/
Do developers integrate Twilio SDK into their apps (similar to Fabric, etc.)? If so, sounds like a way different model than what they used to do (Basically you could integrate just by calling their REST endpoint since it was SMS based and required no installation of any app, but with APNS the only way I can see this work is if you tightly integrate with Twilio API by using their SDK)
How do they figure out a number is associated with an account? Does this assume that users will enter their phone numbers when signing up to a service?
With new offerings like Copilot and presumably this, they get a chance at a fresher start BUT unless you want to handle interacting with Twilio's endpoints directly you're going to have to wait for your client libraries to catch up, which might not be a problem with NodeJS, but for instance my company uses a third-party Golang library that's two years old and has only received minor tweaks in the past 6 months. It will probably not be updated with new features soon or ever, and should I want to utilize these new features I would have to extend or re-write the library myself.
Finally Twilio provides no ways of including metadata in an SMS submission (which is a huge freaking oversight) and makes it very difficult to associate a number with an account. The most accepted answer for that problem currently is to use the Twilio number as a foreign key for an account, which a) does not work with Copilot as you have no control over which number will send the message and b) requires each account to have its own ($1) number, which does not scale.
To associate a number (or push registration) with a user you create a "binding"
More info here: https://www.twilio.com/notify/api
Message spam is the worst, and building intelligent routing across communication methods is becoming a pain.
> Here is the scenario [Twilio CEO Jeff Lawson] envisions: maybe a user signs up to get SMS from a company (in exchange for a coupon, for example). Then, over time, that user also installs the company’s app on two devices. Now, push notifications allow you to give that user a far better experience, but you don’t want to send both SMS and push notifications to every device the user has the app installed on (that would be annoying, after all). With the new API, you simply set up a rule to send a push notification to the device the user last used (or the one that is currently active) and then fall back on SMS if that doesn’t work.
Billions of notifications per month. That's spam.
Now to figure out some way to reroute them all to the CEO's phone.
I get dozens of notifications from various services every day, and I absolutely gave permission or requested them in every case. I get spam email and sms, yes, but of the notifications I get... none are spam.
FCM (firebase cloud messenger): Google will let you push notifications to either android devices or iOS through APN, transparently abstracting device differences away from you
Twilio Notify: Twilio will send either over SMS or FCM, abstracting the presence of the app install away from you
I know this is a good thing as software gets easier, and I'm aware that all software works through abstraction, but for web services in particular this seems like crazy nested service glue.