on How docs, reporters and verifiers

[mckennatim]

on How docs, reporters and verifiers

Reporters seem left out in the 'How' wiki docs.

Subscribers just get alerts and have given out little personal info but in 'User Flow" subscribers are like reporters.

• User can enter more details to improve geo targeting
• User can opt to become a Verifier as well
  This seems to blur the idea of subscriber.

It might be clearer to not have 'users' in the docs. Subscribers and Reporters might be better as a description for 'kinds of people' especially as the verifier is some algorithm that fires an alert on some threshold of the weight of evidence from reports.

At this point it reads to me: A verifier is a user, a subscriber is not a user but subscribers get a verification code and have a UserFlow. a user is wrapped in a session so it can report?/verify? Oy.

Shall I try a rewrite?

[celsom3]

Yes, feel free to suggest any changes. I think it's a publicly editable wiki btw @mckennatim

[mckennatim]

Thanks @celsom3. I hesitate to edit the wiki without first running it by here. I am not sure why a subscriber would not want to click on an SMS alert and go back to the app for more detail. But the app should require a token before it displays that detail. Consider using api-key/token reg/auth for both types of users. This is how I would modify it...

How?

The minimum viable product for this project comes in the form of a mobile accessible web application. This web application will mainly serve two kinds of people:

• Subscribers
• Reporters

Subscribers

These people will simply use the app to subscribe to SMS alerts. Clicking on an alert would bring them to the (web)app and additional detail.

Subscription should require a phone number or email, that the system can then confirm with a code to be entered into the web application to verify a number was willingly subscribed by the person owning that phone number/email.

A subscriber could also choose to enter a zip code(s) or city(ies) to indicate the region(s) they want to subscribe to.

Subscriber Flow:

• Subscriber creates account by entering phone number or email
• The server would then send an api-key to the subscribers phone/email.
• Subscriber enters api-key into the web app
• The server sends a token to the the device the app is running on completing the registration for that device.
• The app would run stateless with token included in every request to the server. The encrypted token would then identify the user as a subscriber (or a subscriber and reporter) and then allow the appropriate information to be sent back to the web app

Subscriber can opt to become a Reporter as well and in that role could enter more details to improve geo targeting.

Subscriber can also edit their profile to modify the regions to which they subscribe.

Reporters

Reporter Flow:

• Reporter creates and account with at least an email address and phone number
• The server would then send an api-key to the reporter's email.
• Reporter enters the api-key into the app
• The server sends a token to the the device the app is running on completing the registration for that device
• The app would run stateless with token included in every request to the server. The encrypted token would then identify the user as a reporter and then allow the appropriate information to be sent back to the web app

Reporters would start a report by entering a location. Other reports on that location would be displayed. Reporter can either verify an existing report, write a new report or clone an existing report then customize and submit it.

NOTE: It is possible that people can report through SMS, but that hasn't been mapped out yet. You're welcome to make a flowchart of a possible way to do it.

For this group of people, we will need to collect more data to verify identity, and avoid approving a malicious user as a reporter.

A new reporter would start out with a 0 rating. A zero rating might mean

• a report from that reporter would not trigger a raid alert.
• when a new reporter files a report they would not be able to see other reporter's reports from that location.

Admin

The web application should also have a UI for Administrators. These will be very few people. The main function of these will be to:

• Export data on raids to share with the public
• Approve Reporters
• Revoke user accounts with malicious behavior

shall I modify the wiki?

[celsom3]

Actually, we not tackle the subscribers for MVP. We are discussing the possibility of creating a Twitter bot that tweets out verified raids at first. Would you like to join the Slack?

[mckennatim]

sure, my slack name is mcktimo