Community mediation by community influencers to resolve problems and mitigate violence.

StopBeef is at it's heart matchmaking software. The idea is to use anonymous tips about neighborhood beefs to identify respected members of the community (OGs) to intervene with the participants.

The current implementation was written as a prototype and to provide architectural guidance. Therefore it is explicitly not production-ready. While we believe the idea and overall design and coding patterns are sound, there are many limitations and every line of code should be reviewed before public launch.

This codebase is MIT licensed.


  • Beef - A problem between two or more individuals in a community that might escalate to violence.
  • Beef Spotter - An individual that reports a beef anonymously in an attempt to prevent violence.
  • OG - A respected individual in the community, this person is not affiliated with the police and has the ability to intervene with the beef participants in an unofficial fashion.


The process as it's currently envisioned is only partially automatic. It should work something like this:

  • StopBeef organizers get involved in the community. The identify respected OGs, pitch them on their role of stopping potential conflicts, and get them to register with the site.
  • The application is advertised and it is made absolutely clear that it is both unaffiliated with the police and that submitted data will remain private and anonymous.
  • Users head to the site and input any beefs they are concerned about.
  • The application reconciles information entered with OGs in the system. (This currently happens through an external process but ideally would happen entirely in the browser so that we can claim to not store any data on submissions at all.)
  • OGs are recommended, selected, and contacted about a beef that they should act on
  • Currently this is a auto-manual process. Identified beefs are emailed to a StopBeef administrator (along with matching OGs and other information). The administrator is then meant to review the information before forwarding it along to the OGs identified.
  • Ideally the beef spotter would be presented with a list of OGs that the system believes might be able to help, they can select to contact these individuals directly.


The application exists in two parts - the website which gathers the anonymous tips on beefs, and the reconciliation process which matches up and contacts OGs who might be able to help.

The website is written as a simple html+handlebars+javascript site (with ruby+compass for stylesheets).

The backend is in Parse.

The reconciliation process is written as several node.js scripts (in the reconciliation directory).

  • public-twitter-analysis.js - analyze submitted beefs using twitter to identify potential OGs
  • sendReconciliationEmails.js - send emails to OGs

The prototype is hosted as a simple page (on Heroku?) with the reconciliation scripts running from a cron job on one of our servers (these have been stopped).


This project was coded during a weekend hackathon we are no longer actively working on it. That being said, we do believe in it.

If you would like to work on it further or get in touch with the dvelopers feel free to contact us via the issue tracker. We will also occasionally lurk on freenode irc in #stopbeef.

Issues and Known Limitations


The application uses some fairly heavy-duty node and client-side javascript. In addition, while Parse is an amazing tool for rapid development, it requires some basic amounts of knowledge (also we're not too hot on the idea of giving away our application keys).

If you are not comfortable with working in this medium you might be better off starting from scratch with your own take on the concept. This is especially true in the format of a hackathon where it is easy for those involved to spend all their time simply trying to get the existing site running.

In addition remember that the api between reconciliation and sending the OG email is a simple json file, this doesn't need to be created via node or any particular platform - any other platform can write these files.

Tied to Twitter Identities

In order to work within the time allotted we chose to tie everyone in the system to twitter - the most easily explored and identified identity for a person. This obviously limits actual use quite a bit. In production we would want both OG networks and individuals to be tied to identities that could be composed from twitter, facebook, and assembled from names and neighborhoods.

In addition, when this uses the original public twitter API. This API has since been sunset and their v2 API must be used.

Reconciliation Limitations

Reconciliation is the act of collating beefs with OGs that might be able to help the situation. Current reconciliation works as follows:

  • An OG is a candidate for reconciling a recent beef if all participants in the beef follow the OG on Twitter.
  • A beef is identified as being similar to another beef if both involve 80% (configurable) of the same participants.

This process has the following known limitations:

  • Everyone must have Twitter identities
  • While the algorithms used achieve results they are fairly simplistic and have not been examined at all for efficiency
  • In order to not spam the public Twitter api, only the followers of the most recent 5 OGs are fetched. This should be resolved with caching in the script so that we can compare against all OGs.
  • Forcing matches to require that participants follow the OGs on Twitter is overly simplistic.
  • The twitter api likely pages their results but we only get the first page. Therefore, if an OG is followed by 50,000 users we might not be getting all of them.
  • The similarity reconciliation algorithm is based on the Twitter ids of participants. There is a good chance for junk data and duplicates. Therefore we need to loop in an administrator to filter the data further before sending it to the OG. This is yet another person who can see the system internals. The goal is to have zero such people to maintain privacy.
  • This process is intensive and requires a great deal of data calls. As such it needs to happen on the server and only periodically. Ideally it could happen in the user’s browser so no data is stored at all in the system.
  • There is currently no way to tell if a beef has been acted upon there would need to be some sort of criteria for determining when we don’t need to notify OGs

Future Work

Some ideas for future work (that are too rough to be listed as issues).

  • Design / UX - the big question is, how do you convince the beef spotter users that this sight is indeed both legitimate, and unaffiliated with the police. It is NOT a tip hotline.
  • Design / UX - If we achieve our goal of not storing any beef data, how do you convince a user that it is in fact true?
  • Analysis - How exactly do we resolve duplicate Beefs?
  • Analysis - How do we build up a better model of who OGs are likely to influence? The military has some awesome stuff around this, can we use any of that research?
  • Analysis - George (the person who wrote the reconciler) is a math minor. Double check his work, add more sophisticated ways of doing these things.
  • Analysis - How do we identify who the beef participants are if the beef spotter does not enter their twitter/facebook?
  • Development - Update to twitter api v2.
  • Development - Identify whether a beef has been acted on.
  • Development - Use facebook, not just twitter.
  • Development - Any of the above twitter issues.