Blockchain-based Android application for collective defence against sexist actions (II)

In a previous article, we explained the research conducted by P2P Models collaborators, Elena Pérez and Patricia Barrios, to identify the needs of the final user of an app for collective defence against sexist actions. In this text, we continue by explaining how the application was built – its architecture, technology stack and final design. 

Different user postures considered

SpreadApp has different functionalities, and each of them is associated with a different posture. The posture in Goal-Centered Design is the degree of attention with which the user will interact with the app.

The map and all the associated features require a sovereign posture: a user checks the map if they want to look for safe or unsafe places, check the latest or nearest alerts or introduce information about a new dangerous spot or an offensive poster. In all these interactions, the user utilizes the system for medium to long periods of time, and directs the work flow.

Sending an alert requires a transient posture: a user activates the alert in case they are in danger. In this situation, they have neither the time nor the possibility to pay attention to the system. The interaction is short and has to be as simple as possible.

Receiving an alert requires a daemonic posture: when a user receives an alert, they are not actively interacting with the system. The system runs in the background, as a daemon. The interaction is short, and the information must be displayed in a clear way.

These postures are taken into account while designing the system.

Given the on-the-go nature of the system, a mobile phone was the most suitable device, so the input method was necessarily by touch screen. The final design resulted as follows:

Blockchain provides the perfect environment for applications to be fair and secure, since it is almost impossible to manipulate the information stored

An Android application, programmed in Java, was generated. The code for the application is open source and it is available at the GitHub repository: https://github.com/pa7ri/SpreadApp/releases/tag/v1.0 

Technology Stack

The technology stack used for the application is the following: 

Prototype Architecture

Main features

The App has two main features: an SOS alert system (the app sends the user’s GPS coordinates to contacts they have selected beforehand) and a map displaying dangerous locations while maintaining anonymity and privacy. 

The alert system

The alert system focuses on sending and receiving emergency alerts. The user sets up the personal data that they want to share with other users. In case of an emergency, the user can press a button and send this data, along with their GPS location, to other users of the app within a certain range of distance, also previously decided by the user. At the same time, the information can also be shared with Telegram contacts predefined by the user. Once the alert system is activated, a bot sends the information to this Telegram group, so that not only unknown users of the app receive the alert, but also friends, family or other people chosen by the user. Finally, the information about the time and location is stored in an Ethereum blockchain, so that it can be represented on the map. The application also receives alerts sent by nearby users in danger and allows the user to check the information that has been sent.

The map

The map focuses on storing and displaying alerts that have already happened, giving a clear geographic representation of dangerous and safe areas. It allows the user to see places where alerts have been sent, check the information of those alerts and see a graphic representation of the most dangerous areas, using Voronoi diagrams. It also allows the user to post offensive posters, advertisements or other information found on the streets, so users can organize collective complaints. All this information is also stored in a blockchain. 

Why is it a good idea to use blockchain technology?

The existance of intermediate elements in situations of sexual abuse or harassment is simply not adequate, as they can put the data privacy of victims at risk. This can be solved by using decentralized technologies such as Blockchain or IPFS, as they provide the perfect environment for applications to be fair and secure, since it is almost impossible to manipulate the information stored. In the particular context of sexual abuse, sharing truthful and trustworthy information about people’s experiences in an appropriate way can help prevent the continuance of this kind of situation in the future. At the same time, blockchain technology allows for the pseudo-anonymity of personal data. Pseudo-anonymity or relative anonymity is a good option in this case, as all information remains public, in the sense that anybody can check the information, but the person issuing the information is identified only by an alphanumeric code, the address of the account, not by their personal data. Blockchain makes it possible to prevent any intermediary entity from possessing or mismanaging the personal data of users, and the information cannot be modified for anyone’s benefit.

The alert is stored in the blockchain, so that it can be displayed on the map. To be able to store the information in a blockchain, the user needs an Ethereum wallet, and some Ether to send the information. Although the profile data is sent to other users with the alert, no personal data is stored in the blockchain, for the sake of privacy. Consequently, the data stored includes: location, date and time, title and description. In these automatic alerts, the title and description are automatically created by the system. This data is written in the blockchain using a method defined in the Smart Contract. It sends the information to the blockchain, and after a while it is saved permanently.

Because this process takes a while, it runs in a parallel thread so that the user can still interact with the application in the meanwhile. Once the data is successfully uploaded to the blockchain, the user is notified with a pop-up. 

In the case of the storage of images for the posting offensive posters, advertisements or other information found on the streets, if this were stored directly in the blockchain, each transaction would be quite heavy and would consume a large amount of ether or might not even be performed if it exceeds the block size limit. To solve this problem, the images are first stored in IPFS, giving back a hash ID, which is then stored in the blockchain.

One of the main issues that we faced during the development of the app was the fact that transactions in Ethereum need gas to be issued, thus costing the issuer money. This seemed like a major problem, because asking for help – which is the main goal of this app – should never be a luxury item one has to pay for. In this initial phase, no external funding exists for the app, so all money spent must come from either the creators or the users. The final outcome was to keep some of the services free, while having others require Ether to be used. Specifically, publishing points on the map requires a payment, but no other feature does. This has a positive effect. On the one hand, the basic services of the app – asking for help and looking up information – remain free for the user. On the other hand, publishing has a cost, which can dissuade possible “vandals” from publishing unnecessary information through the app, while more aware individuals or collectives will still have the possibility to spread their knowledge if they wish.

Limitations and future work

The system still has a few limitations, some of which are related to the implementation, and there is work that can be done in order to improve this. Namely:

  • Develop a system for the posters. At this point, a user can upload a poster, but nothing else can be done. It would be useful to have a more developed system that would actually allow users to show support and voice collective condemnation.
  • Develop a more general system to facilitate interaction among users, a sort of social network that allows users to create events or initiatives and support them. In the case of events, they should also be able to detail the place, time, date, and all other necessary information as well as let users confirm their attendance.
  • Develop a good funding system to avoid payments in the app.
  • Make the transaction system and the interaction with Ethereum transparent to the user. At this moment, if a user wants to publish something in the app, they have to buy Ether with their wallet or transfer the money from a preexisting one. This process is not at all intuitive for a person who is not used to interacting with cryptocurrencies. It makes some functionalities more obscure and less intuitive for the user.
  • Get rid of wallets using meta-transactions. That is, have a central wallet for the whole system, so that users do not have to worry about managing their own wallets. Under this system, payments are centralized, thus simplifying the interaction for the users. Payments are not made by users, but by the central wallet. The users issue transactions and the central wallet manages them, uploading them to the blockchain. This does not contradict the fact that the system is decentralized. Only the wallet and payments are centralized, while the rest of the system and data storage, which are really the main focus, are decentralized. Using this system, it is easier to make interactions straightforward for the user as well as to test different ways of funding, since money is only handled by the central unit.
  • Improve the alert system in terms of location. At the moment, two users are said to be “near” each other if they share the same zip code, but this is not a good measure of distance. A possible improvement could entail superimposing a fine grid on the map and determining that two users are “near” each other if they are in the same square. All other calculations could also be carried out following the same idea. 
  • Add more functionality to the map. For example, a button to show the current location or a search bar to look for specific locations.
  • Improve alert history. It could be useful to give the option to show either only the user’s alerts or all the alerts in the area. More filters could be added to narrow the search.

 

There are other limitations that are due to the technology itself. Some of them include:

  • If a user publishes useless or false information and it is stored in the blockchain, it will be permanently stored along with the accurate information. An arbitration system could be implemented to ensure that information is trustworthy before sending it to the blockchain. However, this is also problematic because it eliminates part of the decentralization and because it is not always possible to check whether a certain piece of information is truthful or not.
  • The data that can be sent via Firebase has a limitation in size. Therefore, heavy information fields, such as a profile picture, can not be sent in the alert.

AUTHOR

Genoveva López Morales. P2P Models Communication Strategist
Genoveva López
Comunication Strategist

Research is by Patricia Barrios and Elena Pérez.

Authorship is by Genoveva López, but this content has been made thanks to the whole P2P Models team

Designs are  by Elena Martinez
Review by Guerrilla Translation
Rosa Chamorro and Samer Hassan make everything possible

You may also like