Come up with new business claiming strategy with some field we can verify

[dwertheimer]

email does not exist in the google results. how will we verify?

[Ilnicki010]

Right now I can't see another way then move to the phone numbers verification using SMS API, but it produces extra costs, so maybe there is some better idea...

https://www.twilio.com/sms

[dwertheimer]

Yes, but we can't rely on SMS. We know a phone number from Google, so I think we have to tell people we will call the publicly-listed number and they will need to enter the verification code. So, they will need to have access to the business phone when they do the claiming.
https://www.twilio.com/docs/verify/api/v1/verification
We will have to call it from the back-end. They have a node API which seems super straightforward.

// npm install authy

const authy = require("authy")("YOUR_AUTHY_API_KEY");

authy
  .phones()
  .verification_start("5551234567", "1", "sms", function(err, res) {
    if (err) {
      console.log(err);
    }

    console.log(res.message);
  });

FYI, Twilio is actually running a Hackathon right now. I wonder if we should try to enter the app so maybe they will help us on the cost side?
https://dev.to/devteam/announcing-the-twilio-hackathon-on-dev-2lh8

[dwertheimer]

Here's how I think it should work, but I am open to suggestions:
Dominik has already created a page: http://localhost:3000/claim-business
We should just have that React page served from the server. At that point, we already know (from Google) the business' phone number. We should tell the person that they need to be at the business phone number in order to verify the claim. If there are at that number now, will call it when they click a button. When they click it, then we send an ajax call back to the server to start the verification process. We should send the google business id and phone in the ajax call, but for security, we should do a separate google places call on the server to confirm that the numbers match (and there's not any spoofing going on). Then NodeJS calls Twilio verify. The user is asked to enter the verification code. and if successful, our back-end (not the client) writes the claim data to the Airtable database. We should be fairly verbose on logging on these requests (a new Airtable base?) so that we can keep an eye on what's happening if for example we get a lot of failed verifications or whatever. What do you guys think?

[dwertheimer]

I'm not sure how this endpoint differs from the one I put in above. Hoping that @SidhaantAnand can figure that out! https://www.twilio.com/verify/api

[Ilnicki010]

Thoughts about your "logs" idea @dwertheimer
All logs about failure verification should be thrown in Sentry (error tracker platform that we use)
Also, we might implement the column with "stage". for example:

• verification in progress
• failed
• success
  Thanks to that we can reach those guys who didn't finish the verification process or sth went wrong

[dwertheimer]

Sounds like a good idea. We should log some things on the front-end and back-end.
Maybe you want to write a Javascript function (populated with our account credentials and whatever metadata) for logging to our server that we can use on the front and the back end? This is my favorite part of NodeJS is that you can share libraries/utilities on the front/back. Maybe split this out to a separate ticket. @Ilnicki010

[Ilnicki010]

Actually, we can connect the back-end app to Sentry using their SDK
(https://sentry.io/for/node/) the same way as we did with the React app.
In that case, we would have all bug logs and other errors from the back-end and front-end in the same place.