cosecha / redadalertas Goto Github PK

Hi - I just found out about this project yesterday, and was looking at your features. I noticed messaging at this point will be handled via SMS, which can become cost prohibitive for the project, even at a small scale.

Any thoughts on supporting notifications via a messenger?
Bonuses: No additional apps to install, just follow the "redadAlertas" bot.

Future interaction can also be added via a bot.

If this is of any interest or was already in the horizon, I can help out. I've developed bots for several platforms out there, including FB, Kik, Telegram, Slack, etc.

Account creation will be invite only. So a verification Code will be needed.

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?

Pages to be created are:

• /dashboard

• This page will display the raids that need verifications

• /report

• This will be where people report a raid

A reporter needs to sign up and get a credential/token. A reporter can create reports. The reporter record on the server would, in addition to some kind of user id, would need to keep a list of report ids filed by that reporter. Each reporter would have a rating. One part of calculating that rating would be from going through their reports to see which turned out to be verified raids. Another might be recommendations from other highly rated reporters. Another factor might be how well people the reporter recommends are doing.

Shall I make an attempt at a data definition/api?

It seems we are missing one level of data abstraction between a report of a raid and something we call a raid.

A report is what reporters create when they notice what looks like a raid

A raid is what is created from a having a number of reports that are in agreement and are from credible sources.

• one raid can have one or more reports associated with it and one ore more reporters who each have a credibility rating.
• it would seem to be the job of the algorithm in code to aggregate reports from the same area, combine information from different reporters who have a good credibility rating and then upon a certain threshold declare it a raid

Can I suggest modification to the api?

Commit in this PR: #70

hi i'm interested in helping out with this - wondering if the project is still being worked on?

Overview

As a user, I am directed to app preferences after the launch screen the first time I open the app.

The False Alarm type was implemented in the App, but not on the server, so if events are submitted with that type they will fail. I imagine that we just need to add that enum type to the server.

I can help make sure what you build is compliant with the TCPA. You don't want a bad actor signing up and then suing you over TCPA issues (which is kind of a cottage industry).

Most pages (minus the / home page) will use template that includes top navigation bar.

Follow the example from https://invis.io/KRAI38IG3#/219546731_Home. Note that the branding doesn't have to look exactly, for now.

We could use some help from designers to make our stuff look nice.

It would be cool to use Material Design or something like Semantic UI. Mainly because there are react component libraries for both.

Just a matter of choosing one and going with it. But there needs to be more discussion around this.

Pages include:

• /signup/verifier
• /signup/verifier/success
• /signup/verifier/failure
• /signup/verifier/final

Overview

As a user, when I launch the app for the first time, I see a landing screen identifying the app and allowing me to being.

Implementation Steps

• Create ejected React Native app
• Create static landing asset for iOS
• Create static landing asset for Android
• Create landing screen

Tech Details

• This seems like a good article for the splash screen: https://medium.com/handlebar-labs/how-to-add-a-splash-screen-to-a-react-native-app-ios-and-android-30a3cec835ae
• Necessary assets are in Dropbox (i.e. the logo and mockups)
• We should be able to do the transparent blue with CSS and React Native components
• We need a high resolution image of a map to place on the bottom
• Use out of the box styles for React Native buttons, but use white text

They will need:

• a phone number or email
• firstName

The server will then generate an inviteCode, and send to either SMS or email. The user will need to enter verification code, firstName, and email address.

This is something that hasn't been decided yet. Looking for ideas and suggestions.

The thing to remember is that there are two repos. One serves the API to access the data. The other simply serves the react app. And let's not forget where we want to host the database.

Possible solutions:

• AWS for react client, and server
• Database hosted somewhere else (like in another country)

That's all I have. Suggestions and discussion is welcome here.

The user should have the option to either verify or report as fake.

Set up using react-router. Routes should include:

• /
  • HomeScreen
• /signup
  • Sign Up page.
• /signup/confirm
  • Page where user confirms with SMS code
• /signup/success

That should be enough to get us started.

Logins have been changed in the API so that they send a JSON web token that's generated on the server. We need to make sure the app properly stores this token and properly sends it to the server for authentication. We also need to add a logout feature that deletes the token from the client's local device storage.

Open to ideas about how to tackle forms. For right now, the approach should be to make the form a dumb component with it's own state that manages validation, then on form submission, sends data to state (which may not be inplemented yet)

It would be nice to have as much tested as possible. Any ideas on what to use for front end testing?

Take a look at the docs for Redux. There is also an example project that I made that uses React/Redux, you can take a look at that.

Now that we're doing pins, sometimes putting the pin on a location that doesn't have a zipcode prevents the event from being submitted.