Dealing with A2P 10DLC regulations was my job for a while, and I can tell you, the short answer is no. The long answer is noooooo... /s
TL;DR: Use a gateway independent service provider, or register with another carrier that lets you work around the restrictions for small use-cases at the cost of slightly higher technical complexity.
In seriousness, though, what those regulations boil down to is carriers self-regulating so that congress doesn't step in and regulate for them in ways that they won't like. It is _backed_ by congress, though, so the penalties are very real and potentially disastrous; up to $10k fine per offending message, not offending company or organization. Amounts that even for hobby projects can add up to very large amounts, very quickly.
Wild over-simplification incoming:
Essentially all the hoops that twilio and others make you jump through are part cover-your-butt, and part cover-their-butt. All of it is dictated to them by The Campaign Registry (TCR) and the various Direct Carrier Aggregators (DCA's. Twilio is kind of a DCA unto themselves, and kind of not... it gets a little confusing in their case). Basically TCR makes the rules, and the DCA's interpret and implement them. Some of them don't leave a lot of room for interpretation (clear opt-out language, requiring positive confirmation of opt-ins for marketing traffic, etc.) and some of them are really fuzzy around the edges (your website needs contact information that matches EXACTLY your business registration information for some DCA's and not others. Some DCA's require very specific language on contact forms and privacy policies, some don't. Some need some language that covers the rules, but not specific language dictated to you by them. It turns into a minefield). Because the DCA's interpret the rules themselves, you get the wait-times. Almost all DCA's do manual verification of the campaign applications, and most of the time they sit in very deep queues.
Some providers, like Telgorithm and Bandwidth, allow you to act as your own campaign holder, whereas Twilio is actually the registered campaign contact. Twilio does that to lock you into their service - it makes it a pain to move your number because you have to re-apply to TCR for all new brands and campaigns. The other providers make that "easier", but you have to do more work on your end to capture and handle TCR webhooks, so there are plusses and minuses. However, one big plus of going with one of those other guys is that you don't _have_ to use the API's, you can do it all on the TCR and provider dashboards, and that lets you register special-case campaigns and brands such as conversational-only (doesn't require all the crazy opt-out language restrictions, etc.), and personal brands (can use DBA's and other low-touch business styles registered to your house address for a dollar). If you are only ever making a bot that only ever texts you personally, that can be a good way to go. However, the second it goes to someone else's phone there is a chance (low, mostly, slightly higher for Tmobile phone numbers for a big list of other reasons) that it will be auto-flagged as potentially invalid traffic. At low trust-scores that will result in not getting messages. If your trust scores continue to fall, they can turn you over to the FTC, and then... well probably best to fake your own death at that point. And before you ask, no, they don't tell you what your trust score is. You have to infer it from average delivery rates, which is just... super.
Your last option is a gateway provider. These are companies that give you a number (AWS has one with 800 numbers, for example), or have very limited behavior such as push-notifications only. Generally these work by registering as a brand of their own with TCR and creating for you an on-the-fly campaign that is configured in such a way that they are essentially sending traffic on your behalf. You'll pay a higher price per message to cover their risk, and if something looks wonky, they will cut you off way faster than anyone else, so expect weird errors and spotty delivery (especially to Tmobile numbers). They sit in a bit of a gray-area, and generally limit the kinds of traffic you can send, in some cases requiring that you pre-define the content of all messages you intend to send. So if you are doing a lot of dynamic message content generation, it might not work for you.
If you're still reading, well, congrats! I know that is a wall of text, and honestly I'm just scratching the surface and leaving a lot out. The goal of services like Twilio is to make it as simple for you as is technically possible, and honestly they do a pretty good job of it. My advice would be 1) if you are only ever sending a small number of messages, just to yourself, and of a fixed content, just use a gateway. 2) if you are generating dynamic content in the message bodies, or if you intend to send to a small number of phones, register a DBA and sign up with Twilio with your DBA (or LLC if you don't mind the extra tax work) as the business and do the wait-and-check dance. Expect that to take a month or more. 3) In any other case, or if you have a very limited use case, talk with the folks at Telgorithm and they can hook you up (I'm not affiliated with them - I just have used them in the past and really like them).
This estimate is also not taking into account carrier pass-thru fees, regulatory fees, phone number maintenance fees, etc. The idea that you can send 100K sms segments for a few hundred bucks just isn't true, even in the US. The pricing on these things gets way more complicated than what the marketing pages seem to indicate.
By way of example, my company is sending ~1.5M segments per month at a cost of a couple tens of thousands (I can't say exactly, obviously). This boils down to the fees that I mentioned, international examples that you gave, as well as the differences between SMS and MMS messaging where it's not always clear what counts as MMS (multi-byte encoding, anything with an attachment or URL, >N segments per message where N changes based on delivering carrier, etc.) It gets... Wonky.
It honestly doesn't simplify things over push notifications all that much. There are a lot of regulations if you are planning on having users in the US around A2P (Automated to Personal) messaging. You have to register a brand and transactional use campaign with TCR (The Campaign Registry - the regulatory body that manages this messaging), a process that costs money and can take months. They are capricious to say the least... So expect a lot of upkeep on your website, brand, campaign, and number usage as time goes on and they change regulations more or less on a whim.
As part of those regulations you have to deal with opt-in and opt-out formalities. It's a crime in the US to send a text message to someone in an automated way that they did not directly and concretely ask for. Doing so can result in heavy fines. Similarly if they opt out using any of a number of both standard and non-standard methods, you must comply with that even if it impacts their ability to use other parts of your system. You can work around that with multiple numbers, each attached to a different campaign of a different use-case, but do that too much and they'll get you for "snow shoeing" and it comes with more and more fines.
And on... And on... And on... This is my literal day-to-day job. I can say with relative confidence that if you are working with a small number of people, just use push notifications. It's actually easier.
Also, if you must go with SMS for whatever reason, your tier-1 providers, as you put it, will handle a lot of that regulatory guff for you (for a price of course), so don't look too far for other providers. If you want to own your own registered brand and campaign with TCR, then a good option is Telgorithm, although your integration complexity will go up pretty drastically.
Lastly, check your costs. Pricing for SMS is way more complicated than what the marketing language on provider websites seem to indicate. Talk with people doing similar things and get the real answers, and budget accordingly.
Yes, exactly. We pre-built the table with a ton of hand-picked mailing addresses copy-pasted out of a bunch of free-text and then just kept using that one.
I worked for an internet scraping/statistics gathering company some years ago, and we used this approach alongside a few others to find mailing addresses embedded in websites. Basically use LZW-type compression with entropy information only trained on known addresses, and then compress a document, looking for the section of the document with the highest compression ratio.
It worked decently well, and surprisingly better than a lot of other, more standard approaches just because of the wild non-uniformity of human-generated content on the web.
The crime has already been committed. The question of safety is now resolved; you were not safe at that time, and likely exactly as safe now as you were before the crime. However, if you speak with the cops without council, you could endanger your freedom by saying the wrong thing to the wrong guy having a bad day. In the interest of safety, you have nothing to gain and everything to lose by speaking to the police without a lawyer.
Nice idea and design. Along with what other people have said, though, turn off all the js animations. They make it nigh impossible to quickly asses content and actionable items, requiring that a person sit and stare for longer than needed without getting any new or useful information. The design is nice on its own; it doesn't need to be dressed up more, and if you feel it does than that's a sign that you don't like the design and should change that instead. Just my opinion.
Yeah. I made a ruby gem a while back that did this, but with rdoc strings instead ( I hated docs getting out if line with functionality) called "contraction". The code isn't the greatest, and I would probably do things a bit different now, but it worked. More railsy , for sure, but I don't know if that actually made it better...
The problem with that line of reasoning is that it has an inherent assumption of rightness through selective observation. You believe that if a person in the abstract, "makes good decisions" then they will do well with more money. However, you believe this because you (presumably) are yourself not poor, and a person is disinclined to think of themselves as a bad decision maker. If you do think of yourself as a poor decision maker, then we would have no reason to take your argument with any degree of seriousness; you yourself would reject the premise on the axiom that you don't think rightly.
How well a person manages money is only partly determined by their ability to observe, reason through abstractions about their observations and make rational decisions. It is mostly determined by circumstance outside of their control which oftentimes has a negative feedback loop (living paycheck to paycheck, get sick, have hospital bills, can't buy good food, get sick again, etc. etc.)
Given that, from the outside we can't say weather or not a person is poor because of choice or chance, and can't make a value judgement about their... well, judgement. Certainly even if you could in the individual, you couldn't institutionalize such judgements. So the only way to know if they will do well is to give them money and see how they do with it, or to give them nothing and see if they rise above circumstance (which if they are a candidate for free money, the answer is likely already answered.)
The efficiency of donation is almost irrelevant. They will either do well with the money and uplift themselves, or they will do poorly with it and the money will return to the economy through normal means.
A better way to think of this kind of reasoning is that some non-zero percentage of recipients of the money will have a better life for it. With a better life for them, comes a better set of circumstances for their local (and diffusely, the rest of) society through more able members. Given that, giving money to the poor is more correctly thought of as an investment in quality of life and societal health.
From that perspective, we can avoid ad-hominum value judgements of individuals and look at the social impact as a whole and see that the statement, "the best way to help the poor is to give them money" is, in fact, correct.
But it's closer to the act of exchange, divorcing it from the act of production. I commented further down on it, but it could be fun to read up on the labor theory of value vs. the subjective theory.
But in seriousness, you should read Marx's and Smith's thoughts on the labor theory. In a service industry (and by service, here I mean, "does not hand you a physical thing") it gets really interesting to think about.
I don't think that it is a "server-side solution to a front-end problem". I believe that the right-click/save-as pattern was a front-end solution to a server-side problem. The problem is developers not knowing how to properly set their content type and disposition headers.
I agree 100%. Furthermore, privacy is an issue of trust, not an issue of guilt. These very lines of reasoning (and the laws that stem from them) cause me to not trust those people and institutions, and so I won't trust them with my information, weather or not I feel that information is damning. They have shown their untrustworthiness, and so I must expect, in order to protect myself, that they are untrustworthy people who will do untrustworthy things with that data.
To your point 1 to point 1; the difference is in your argument they have a warent, and the person is already found to be breaking a law, or a judge has found there is reasonable cause to expect that they are. As apposed to the _actual_ point on issue, here, which is people saying, "I'm just going to have a look, without suspicion, peasant", and when people complain trotting out the "if you have nothing to hide..." line.
To your point 2 to their point 2; it's not an exaggeration at all. Police forces jobs are to catch and punish criminals, not to prevent future crimes. Therefore, if they are interacting with you it is in support of that job, ie to catch and punish known criminals. Therefore, if they are "just checking", it is "just checking so that we can find something to charge you with."
Given the nature of many laws being such that everyone is breaking them all the time, it creates excuses to lock up people on the whims of the power-hungry.
Right or wrong, moral/ethical or not: I like the site. It works well, looks nice, and provides a clean interface to the information one would look for using such a service.
I would like to put out there that morals and ethics are two different things. Ethics has to do with what you _think_ is right or wrong, regardless of the actions that you take. Specifically, ethics is the philosophy/study of morals, not their application.
>I barely trust Paypal, you think I'm gonna trust FB with my CC details. You gotta be kidding.
Trust isn't as big of a deal as you might think. People think it matters a lot in business because it matters in your day-to-day life with in-person interactions. The fact of the matter, however, is that many people who don't trust things still use them.
I don't trust my government, but I still pay my taxes and use the clean water they pipe to my house.
I don't trust most banks, but I still use their CC processing networks.
Plenty of people don't trust BP (and oil companies in general) but still drive internal-combustion cars.
More and more people every day don't trust Foxconn, but still buy all the gadgets they produce.
Trust matters when you are dealing with something non-ubiquitous; you don't need to use it, so if you don't trust them you don't use it. However, if something goes main-stream (like credit-cards), and the interaction is practically forced on you (like taxes) then people use it without trust. Facebook as it stands right now is testament to that. I don't trust them _at all_, but am forced to use it because friends, family, and groups I personally value use it in a way that requires me to as well.
If they launch a payment processing system that even only a quarter of their users are willing to use, that is enough market share for websites to start using it, which is free advertisement for the system, gaining more users. How long before sites that _only_ take facebook pay crop up (in the same way that some sites _only_ use paypal; a company plenty of people don't trust, but are forced to use)? How long before some site that provides a service that you depend on?
TL;DR: Use a gateway independent service provider, or register with another carrier that lets you work around the restrictions for small use-cases at the cost of slightly higher technical complexity.
In seriousness, though, what those regulations boil down to is carriers self-regulating so that congress doesn't step in and regulate for them in ways that they won't like. It is _backed_ by congress, though, so the penalties are very real and potentially disastrous; up to $10k fine per offending message, not offending company or organization. Amounts that even for hobby projects can add up to very large amounts, very quickly.
Wild over-simplification incoming: Essentially all the hoops that twilio and others make you jump through are part cover-your-butt, and part cover-their-butt. All of it is dictated to them by The Campaign Registry (TCR) and the various Direct Carrier Aggregators (DCA's. Twilio is kind of a DCA unto themselves, and kind of not... it gets a little confusing in their case). Basically TCR makes the rules, and the DCA's interpret and implement them. Some of them don't leave a lot of room for interpretation (clear opt-out language, requiring positive confirmation of opt-ins for marketing traffic, etc.) and some of them are really fuzzy around the edges (your website needs contact information that matches EXACTLY your business registration information for some DCA's and not others. Some DCA's require very specific language on contact forms and privacy policies, some don't. Some need some language that covers the rules, but not specific language dictated to you by them. It turns into a minefield). Because the DCA's interpret the rules themselves, you get the wait-times. Almost all DCA's do manual verification of the campaign applications, and most of the time they sit in very deep queues.
Some providers, like Telgorithm and Bandwidth, allow you to act as your own campaign holder, whereas Twilio is actually the registered campaign contact. Twilio does that to lock you into their service - it makes it a pain to move your number because you have to re-apply to TCR for all new brands and campaigns. The other providers make that "easier", but you have to do more work on your end to capture and handle TCR webhooks, so there are plusses and minuses. However, one big plus of going with one of those other guys is that you don't _have_ to use the API's, you can do it all on the TCR and provider dashboards, and that lets you register special-case campaigns and brands such as conversational-only (doesn't require all the crazy opt-out language restrictions, etc.), and personal brands (can use DBA's and other low-touch business styles registered to your house address for a dollar). If you are only ever making a bot that only ever texts you personally, that can be a good way to go. However, the second it goes to someone else's phone there is a chance (low, mostly, slightly higher for Tmobile phone numbers for a big list of other reasons) that it will be auto-flagged as potentially invalid traffic. At low trust-scores that will result in not getting messages. If your trust scores continue to fall, they can turn you over to the FTC, and then... well probably best to fake your own death at that point. And before you ask, no, they don't tell you what your trust score is. You have to infer it from average delivery rates, which is just... super.
Your last option is a gateway provider. These are companies that give you a number (AWS has one with 800 numbers, for example), or have very limited behavior such as push-notifications only. Generally these work by registering as a brand of their own with TCR and creating for you an on-the-fly campaign that is configured in such a way that they are essentially sending traffic on your behalf. You'll pay a higher price per message to cover their risk, and if something looks wonky, they will cut you off way faster than anyone else, so expect weird errors and spotty delivery (especially to Tmobile numbers). They sit in a bit of a gray-area, and generally limit the kinds of traffic you can send, in some cases requiring that you pre-define the content of all messages you intend to send. So if you are doing a lot of dynamic message content generation, it might not work for you.
If you're still reading, well, congrats! I know that is a wall of text, and honestly I'm just scratching the surface and leaving a lot out. The goal of services like Twilio is to make it as simple for you as is technically possible, and honestly they do a pretty good job of it. My advice would be 1) if you are only ever sending a small number of messages, just to yourself, and of a fixed content, just use a gateway. 2) if you are generating dynamic content in the message bodies, or if you intend to send to a small number of phones, register a DBA and sign up with Twilio with your DBA (or LLC if you don't mind the extra tax work) as the business and do the wait-and-check dance. Expect that to take a month or more. 3) In any other case, or if you have a very limited use case, talk with the folks at Telgorithm and they can hook you up (I'm not affiliated with them - I just have used them in the past and really like them).