Twilio Drupal Bridge - a voice web browser

Twilio Drupal Bridge - a voice web browser  - a modest proposal

The application is a website that contains an interface to the the Drupal API and a request handler for Twilio. Sometimes called "headless Drupal", examples can be found here. Additional info here. It is called headless because it never returns a web page and only talks TwiML to Twilio. It connects to the database of a public Internet facing Drupal website providing the same functionality. A sample Twilio script can be found here. The public site also provides administrative access for moderators and account management.

A session starts with a phone call to the number connected to a Twilio account. Twilio sends a request to an associated URL. The request contains the phone number of the caller. A blacklist is consulted  then if that phone number matches a user profile in Drupal, the user is  asked to key in a numeric PIN. If the PIN matches the user is authenticated. If not, the user is allowed to retry twice after which he/she is asked to leave a voice message which is routed to staff email. The Drupal database is consulted to see if the user should be "authorized".

If the phone number does not match, the user is invited to register or continue as anonymous. Some of the demographics can obtained from the Twilio request. The rest of the profile may be difficult for some users to key in and the user has the option of sending a voice mail to staff.. At this point the user is authenticated but not authorized. Staff reviews the registration and makes a decision to "authorize". Staff may call back for more information.

At this point we have three user states - anonymous, authenicated and authorized - which correspond to three menus in Drupal and the appropriate menu is played to the user. Anoymous is permitted general navigation which includes news, ads and register. Authenticated users get a menu which includes additional options to deposit funds, and request escalation to authorized. They may also send posts to staff for moderation.

Authorized users can make posts and transfer credit. Voice posts are forwarded to staff for classification and tagging.

We can now identify several classes of people:

  1. users which are vendors, buyers or both
  2. evangelists who  negotiate vendor agreements and promote public participation
  3. moderators who review voice messages titling, classifying, tagging and routing
  4. administrators who review user accounts and handle requests for authorization
  5. webmasters who maintain the public website
  6. developers who maintain this bridge and the Drupal backend.
  7. advisors to address financial public relations issues

The hosting organization should have tax exemption, its own bank account and fund transfer mechanism - Paypal or merchant account. Operations should be supervised by a board with representatives from each of the above classes.

Security is a major concern. Unfortunately many issues will be revealed only after the system is deployed.

The bridge will be released under the GPL. The developers will provide paid support. Operations will be underwritten by donations and external and internal transfer fees. We expect those fees to be comparable to merchant fees.