Crowdsource
crowdsource
NOTES.md <markdown> Are there going to be people who's job it is to verify reports of raids?
Or is there some mechanism where a reporter first enters a location and then some master report for that location comes up that gets added to?
In terms of simplicity and independence for the data, adding data to one big raid report will make it harder to parse and attribute to each reporter. Perhaps a reporter could scan all the reports for an area and then chooose one to use as a template for their own report (or create a new one).
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
Are there going to be people who's job it is to verify reports of raids?
Or is there some mechanism where a reporter first enters a location and then some master report for that location comes up that gets added to?
In terms of simplicity and independence for the data, adding data to one big raid report will make it harder to parse and attribute to each reporter. Perhaps a well rated reporter, upon entering a location, could scan all the reports for near that location and then - add their id to verifiedBy array - chooose one to use as a template for their own report - create a new report
A new reporter couldn't see other reports but could file a new report.
@celsom3 here is a swagger-like definitions section.
If we did use similar registration/ authentication for subscribers and reporters the there would be one user record type that has a boolean field for subscriber and reporter. They would join by userId to reporterId and subscriberId and the subscriber and reporter records. I'd suggest that email be the username since it would apply to a users multiple devices (phone/laptop).
Subscribers would have an array of regions they subscribe to
Reporters would have a rating, an array of reports they have made, an array of recommenders and an array of people they recommend.
A report would have a raid info, a reporterId and a report rating maybe based upon reporter's rating and completeness or speciificity.
A raid would combine information from all the highly rated reports for a location. It would also be joined to those reports via an array of reportIds, and to the reports via an array of reporterIds. Its confidence rating would be the threshold upon which the raid becomes an alert and could merely be some combination of the report ratings.
definitions:
User:
type: object
properties:
userId:
type: string
email:
type: string
apikey:
type: string
subscriber:
type: boolean
reporter:
type: boolean
timestamp:
type: string
Subscriber:
type: object
properties:
subscriberId:
type: string
phoneNumber:
type: integer
format: int32
regions:
type: array
items:
type: object
properties:
lat:
type: integer
lon:
type: integer
city:
type: string
zip:
type string
radius:
type: integer
Reporter:
type: object
properties:
reporterId:
type: string
reports:
type: array
items:
type: string (raidIds)
recommendedBy:
type: array
items:
type: object
properties:
colleagueId:
type: string
colleagueRating:
type: integer
recommends:
type: array
items:
type: object
properties:
colleagueId:
type: string
rating:
type: integer
rating:
type: integer
Report:
type: object
properties:
id:
type: string
reporterId:
type: string
verifiedBy:
type: array
items:
type: reporterId
timestamp:
type: string
rating:
type: integer
location:
type: object
properties:
lat:
type: integer
lon:
type: integer
address:
type: object
properties:
street:
type: string
city:
type: string
zip:
type: string
numOfIceMen:
type: integer
iceIds:
type: array
items:
type: string
images:
type: array
items:
type: image
other:
type: array
items:
type: string
Raid:
type: object
properties:
id:
type: string
reportersIds:
type: array
items:
type: string
reportIds:
type: array
items:
type: string
timestamp:
type: string
confidence:
type: integer
location:
type: object
properties:
lat:
type: integer
lon:
type: integer
address:
type: object
properties:
street:
type: string
city:
type: string
zip:
type: string
numOfIceMen:
type: integer
iceIds:
type: array
items:
type: string
images:
type: array
items:
type: image
other:
type: array
items:
type: string
</markdown>
