If you're able to build the solution using Twilio (or anything else), then I'm pretty sure Authy isn't for you. I think it's clear that their eventual product is going to be a simple, drop-in that enables two-factor on your mom's knitting forum.
Unless my mom's knitting forum also is an online trading platform, why do they need two factor auth? And how likely is it that their software of choice doesn't have a Twilio plugin?
Of course the forum can't control that and neither can your bank, but out of the two, only the bank should care and implement two-factor auth. It doesn't matter if your knitting forum account is hacked into, so two-factor auth is overkill.
Now, sure the password on that knitting forum might be the same as your bank online account. But the point is that only websites where your account is sensitive needs to add two-factor authentication.
I should have phrased my comment above another way: the solution to password re-use is not to add two-factor auth to a knitting forum, but to add it to the bank website, email provider, etc. anywhere your account's safety matters.
(I was thinking more from the point of view of the user: if they start to get worried about their accounts getting hacked, two-factor auth on the forum is not the solution, a password manager is)
I'd think the biggest draw would be not developer ease as much as end-user ease. This way, an end user with an Authy account would only have to give their phone number out once, to Authy, or install one app from Authy, and automatically be able to use two-factor authentication on any site that supports it. It's like OpenID for the second half of two-factor auth.
Totally agree... site specific TFA apps is already starting to get a big silly. Battle.net, Google, my Bank... three is already starting to be a pain to manage and install.
Why? If that's necessary, Authy is doing it wrong. A client app ought to be able to request an auth token that Authy sends to the user without ever having to reveal the user's number to the client app.
