Right now I’m working on the email code for Pledgebank.

There are (ignoring SMS) three communications problems in Pledgebank: firstly, how does the pledge setter get to communicate with the pledge signers when the pledge is complete (so that the setter can tell the signers what to do / how to organise themselves, or whatever); secondly, how do the signers communicate amongst themselves before the pledge completes (to discuss tactics for getting more people signed up, or whatever); and thirdly, how can other people get more information or clarification on the pledge.

Ideally, we’d like to be able to do all of the above while keeping individual signers’ email addresses private.

(As an aside, I should say that the proper English words for “pledge creator” and “pledge signer” are “pledgee” and “pledger”. I fought a valiant struggle to have these adopted as the Official Pledgebank Terminology, but inevitably we all got confused as to which was which, and reluctantly abandoned them in favor of “creator” and “signer”, which sound a bit buzzword to me. Ho-hum.)

Anyway, there are lots of different ways that we could allow the creators and signers to communicate. After a long discussion we decided that we’re going to implement,

• an announcements-type mailing list for the pledge creator to use,
• an (optional to join) discussion list for signers and the pledge creator, and
• a web-log-style comments page for each pledge.

which seemed like a sufficient set of features which would avoid having too many confusing configuration options.

(Another way to look at this is to look at this from a permissions perspective:

For the first two functions we need to limit access to what’s said to particular groups of people. That means that either we have to have a login system on Pledgebank, which we’re avoiding, to keep things as simple as possible; or to use email, which is practical because creators and signers have to confirm their email addresses in order to pledge. No access restrictions are needed for comments and clarifications, and it’s useful to show comments publically — so as to avoid ever answering the same question twice — so public web comments are appropriate here.)

So, this week’s task is to get the email stuff all working. Getting email sending from web applications right can be tricky, especially if you care about reliable delivery. As you can imagine, this is a whole heap of fun….

So, my script actually decided to hassle Matthew into writing a post here, but he’s off enjoying himself at EtCon so I’m stepping into the breach myself.

One of the features PledgeBank will support is allowing users to sign up to a pledge by SMS (as well as through the traditional web form plus email confirmation route). So, that’s what I’ve been working on lately.

The idea is that the user sees a poster or flyer describing the pledge, with the instruction, “text ‘PLEDGE {name-of-pledge}’ to {number} to sign up!”. We then sign them up and send them another SMS when the pledge completes.

Now, the last time I had anything to do with SMS, making any progress required writing a giant C program which talked to an “SMS message centre” via the universal computer protocol (so called because it’s not universal and isn’t used for talking to computers — in fact, I think it’s a hangover from the days of numeric-only pagers). Since then, this stuff has become a lot easier; there are lots of companies which do the talking-to-the-phone-company stuff for you, and let you transmit and receive SMSs over HTTP. The one we’re using for testing, MX Telecom, seem pretty typical; you submit messages to send via HTTP POST, and get told about incoming messages and delivery reports via — slightly disappointingly — a GET to your own servers. (Further disappointment: while sending is authenticated — via a plaintext username and password — receiving isn’t, other than by source IP address. Ho-hum.)

For those who don’t use them, SMS messages can be regarded as being like email, but much more expensive, slower, and not as reliable. Oh, and you only get to send 160 characters in each message, unless you want to use characters outside the ISO-8859-15 code page (“Latin1 with added ‘?'”), in which case you get only 70 characters. The one feature SMS has which email doesn’t — other than cost — is delivery reports. Decent aggregators will send you a message which tells you whether a message you’ve sent has been delivered, buffered in the network waiting for the recipient’s phone to be switched on, rejected because the user pays to receive SMSs and has run out of credit, or various other rare conditions.

It’s also possible to send “premium rate” reverse-billed SMS messages, where the punter pays to receive them. Sadly you don’t get the option of sending these from your regular phone, but if you pay BIG CASH MONEY to an SMS aggregator you can do so. These messages typically cost the recipient 25p or 50p (there are a whole set of billing bands). For the cheaper messages, the telephone company keeps most of the money, the aggregator takes a bit, and eventually you get 4–6p.

Sending a normal (“bulk”) SMS message costs somewhere from 5p to 10p, in small quantities.

So so far our plan looks like this:

• User texts us, asking to be signed up
• We send them a reverse billed message containing a URL which they can use to convert their SMS subscription into an email one
• If we get a successful delivery report for that message, or if they visit the URL we sent them, we sign them up
• Later on, when the pledge completes, and if we don’t have their email address, we let the pledge creator send them another SMS telling them what to do

One obvious problem here is that, on the face of it, we lose money on every transaction here (and only letting the pledge creator send one message to the signers is pretty sucky too). Based on the estimates we’ve been given, we can break even as long as ~20% of SMS signers convert to email subscriptions. But it would be nice to be able to run these things by SMS alone, since not everybody has the web or email (or wants to use them).

Anyway, from a code point-of-view, this all now works — I could bore you for hours about all the nasty cases which occur when somebody signs up by email, and by SMS, and then tries to convert their SMS subscription to email and so forth, but anyway, we’ve solved that one and this post is already too long — so all we have to do now is get the best deal we can for SMS messages so that this becomes practically useful….

Earlier, Francis referred to an “evil plan”. So, here’s the plan:

Purely for my own entertainment, I’ve decided that the way to get us writing more updates for mySociety home page is to break the old rule that you should “never solve a social problem with a technical solution”. Here is my technical solution; let’s see how badly it breaks….