Does sms_capable imply user permission to text or do we need another...

[joshco]

post-beta... Should we break out into two attributes: 1 sms_capable: this number can accept text messages 2 sms_permission: the user has given us permission to send sms updates at this number

[walker]

Should we break out into two attributes

Absolutely. Though, in this case, I would specify that sms_permission (maybe just in the positive) cannot be transmitted between organizations and/or systems.

[raysuelzer]

I currently update our SMS subscriptions through our API so this would be useful. We should make it an array though so that we can see what list or organization people are subscribed to receive messages from. So, if I am running a sync on our membership list I can figure out which people are subscribed to our main UFCW text list and which are also opted-in to our Change Walmart text list. This would also allow for data swaps with other organizations without risking overwriting their SMS data.

sms_subscriptions: [ { name: "UFCW" opted_in: true, opt_in_date: 10/12/12, opt_in_method: ?? }, { name: "Change Walmart" opted_in: false opt_in_date: null, opt_in_method: null }, ]

Ray Suelzer Mobile: (202) 714-8676

On Thu, Dec 5, 2013 at 6:27 PM, Walker Hamilton notifications@github.comwrote:

Should we break out into two attributes

Absolutely. Though, in this case, I would specify that sms_permission (maybe just in the positive) cannot be transmitted between organizations and/or systems.

— Reply to this email directly or view it on GitHubhttps://github.com/wufm/osdi-docs/issues/68#issuecomment-29958758 .

[raysuelzer]

At UFCW we have about 4 different text message opt-in lists all living on the same database, so it's important that we are able to distinguish which lists someone has opted in to if we were to use an API.

Another good use case scenario for making this field an array would be if two organizations wanted to send a text about a common thing, for example a save social security event, but the organizations didn't want to send to the same people due to risking an opt out of their list. For example let's say that the AFLCIO and UFCW are both pushing their subscribers to attend an event, and we know many of our subscribers overlap. We could write a script to determine the unique subscribers on our lists and coordinate on a text plan.

This would also be useful internally within the UFCW so that we aren't sending them same text to the same person who happens to be on all of our different lists.

Ray

Ray Suelzer Mobile: (202) 714-8676

On Thu, Dec 5, 2013 at 6:46 PM, Raymond Suelzer rsuelzer@gmail.com wrote:

I currently update our SMS subscriptions through our API so this would be useful. We should make it an array though so that we can see what list or organization people are subscribed to receive messages from. So, if I am running a sync on our membership list I can figure out which people are subscribed to our main UFCW text list and which are also opted-in to our Change Walmart text list. This would also allow for data swaps with other organizations without risking overwriting their SMS data.

sms_subscriptions: [ { name: "UFCW" opted_in: true, opt_in_date: 10/12/12, opt_in_method: ?? }, { name: "Change Walmart" opted_in: false opt_in_date: null, opt_in_method: null }, ]

Ray Suelzer Mobile: (202) 714-8676

On Thu, Dec 5, 2013 at 6:27 PM, Walker Hamilton notifications@github.comwrote:

Should we break out into two attributes

Absolutely. Though, in this case, I would specify that sms_permission (maybe just in the positive) cannot be transmitted between organizations and/or systems.

— Reply to this email directly or view it on GitHubhttps://github.com/wufm/osdi-docs/issues/68#issuecomment-29958758 .

[walker]

Another good use case scenario for making this field an array would be if two organizations wanted to send a text about a common thing, for example a save social security event, but the organizations didn't want to send to the same people due to risking an opt out of their list. For example let's say that the AFLCIO and UFCW are both pushing their subscribers to attend an event, and we know many of our subscribers overlap. We could write a script to determine the unique subscribers on our lists and coordinate on a text plan.

Internal to an organization, this makes sense as-stated. From an external standpoint this sounds awesome, but it would likely need to be a hashed list. Many orgs won't swap actual info between them without a monetary exchange.

[walker]

I also wanted to note that, internal to UFCW, doing the check stated above isn't necessary so long as the three lists are selected as the recipient of a single outbound message. The system won't send that single message to the same phone twice, even if it appears in two separate lists that were selected.

So, perhaps just the external hashed comparison could be the option?

[richranallo]

Short answer to the first question: no, assuming permission to send SMS is a gateway into a world of pain from industry regulators and potentially the FCC. Marking a number as being capable of receiving SMS is still valuable even if there's no permission given, so tracking the two separately is a good idea.

Long answer, there are a few caveats to keep in mind with SMS messaging even beyond that. With shortcode messaging, a proper opt in means the organization running the campaign has permission to broadcast to that person from that shortcode. This means not only that a third party can't broadcast to them, but in the strictest interpretation, that organization can't just move their list to another code and start sending even to people who already opted in. So any attribute we put in that indicates there's on has opted in should also specify what they've opted into and from whom.

The rules are different on long code messaging, and I'm far from an expert there, though I'd be careful if the presentation of the data here might imply to someone that the capacity to text a number carries with it implicit permission.