Get best of the week

Web service that allows users to independently maintain a culture of communication online

In previous posts , a new approach to moderating online discussions was proposed, which does not require an appointed moderator or collective voting and allows users from different sites to organize into a kind of community of moderators. This approach will allow users to control the online communication culture themselves, which will reduce the burden on website owners to moderate comments.



Readers of Habr were offered a small test example of a commentary tape in which one could try this approach in action.

Thanks to everyone who takes part in testing! Already the initial statistics allow us to say that readers confidently perform moderation. Now it's time to move on. In this post, I want to discuss the simplest possible device for a web service that implements this approach. Unfortunately, experience for the implementation of such a task is not enough, therefore, the advice of the Habr community is required.

What are the current requirements for the web service?

  • Easy connection of new sites to the web service.
  • simple basic functions of the moderation API.
  • at the initial stage, it must withstand a load of at least 40-50
    simultaneously moderating users.
  • in the long run it should not be difficult to scale.

Given these requirements, the web service diagram presented in the figure is still looming.



In order to connect your site to the web service, the site owner will need:

  • install a script on your js website that encapsulates functions for working with the API.
  • Add moderate attribute to the comment input field , which the script will focus on. After that, when you click on the comment field, a moderation dialog will appear.
  • Add the moderate attribute to each comment in the feed , which the script will focus on. After that, a button will appear next to each comment that brings up the moderation dialog.

In the process of its work, the script will use the following functions of the moderation API (of course, there will be more functions that should ensure the functioning of the Community, but now we consider only the basic ones):

  • GetAccessToken , IN: api_key.
    Request a temporary token for the current check. In this token, encrypted on the server side, all the data necessary for the server is stored, allowing the server to identify the current scan and distinguish one scan from another. The token has a limited lifetime. The site owner must register a unique api_key on the web service, which is included in the token.
  • GetChecks, IN: token. OUT:comments_list_for_check,last_comment_check_results
    . , , .
  • SetCheck, IN: token, comments_list_with_result, comment_for_check OUT: true/false
    . , ( ) true comment_for_check .

Apache mod_php is currently planned as a web server . Pros: it works quickly, requires a minimum of configuration knowledge. As a minus: scripts are executed from a single apache user.

The web service API functions are planned to be executed in php . Pros: speed of development, cross-platform, acceptable performance. Cons: security (however, it is planned to use version 7, where there are fewer holes)

We will use Sphinx as the base . Pros: Easy installation, speed of search and ease of scaling compared to relational db. Minus: the lack of join queries, but this is solved by the correct structure of the database.

So far, it seems that initially all this can be run on an ordinary VPS and thus ensure the work of 40-50 moderating users at the same time. If the load increases, then in VPS it will not be difficult to add resources (memory, processor, disk capacity), and if the load on DB Sphinx increases, it will not be difficult to deploy another instance of Sphinx.

Questions:

What can be the "pitfalls" in this implementation? And what technologies would you use to implement the simplest version of such a web service?

Thank you for the attention !

More articles:


All Articles