Author: Vasu Harshvardhan

In my previous blog post, I had achieved the authentication at the initial handshake in the app. Since then there has been quite a lot of progress in upgrading the Meshenger app.

Progress Till Now

1.) Refactoring of the codebase

Initially, I started with the refactoring of the codebase in order to allow different means of connection to the client. For e.g. contacting a client over the server or Internet, enabling direct calls in layer 3 networks with the help of multicast groups and pim6sd. etc. I am working on enabling the calls over the Internet.

Firstly, I started by removing the “challenge” from the entire codebase. Challenge was used as a security parameter but now as authentication has been developed, it became redundant. Secondly, I refactored the Contact (Client data) and AppData (User data) class to hold different connection data like mac address, port and the hostname. I moved the identifier and address in the “connection_data” ArrayList and stored the data structure serialized as a string in the Contacts database which needed to hold different contact data of the form List<ConnectionData>. I added this data to the QR-Presenter Activity ‘s QR-Code and parsed in the QR-Scan Activity. I followed the same procedure for the AppData database also. Lastly, I also removed “username” and “identifier” from the call JSON.

2.) Implementing client online/offline detection over the Internet

For implementing the client online/offline detection over the Internet, I needed to hold a persistent TCP/IP connection to a signalling server. So I started a thread at the start of the app and that thread opened a persistent TCP/IP socket for each SignalingServer object in the connection_data. The sockets were held open for as long as the app is running. I used a signalling server made on node.js and ran it on the laptop. Then after connecting the phone A and phone B to the laptop’s hotspot, I ran the app on the phone A and the server displayed that the user is online. After that, I checked for the client status by running the app on phone B while still keeping the app on phone A on. The result was displayed that the client was online and the client’s status was detected over the Internet.

Next Steps

The next phase i.e. the Final Phase of GSoC 2019, will be about achieving the call over the Internet, adding other features and some code polishing.

In my previous blog post, I gave an overview of the project, that I am working upon. Since then there has been quite a lot of progress in upgrading the Meshenger app.

Progress Till Now

Since the official coding period began, I started with fixing the existing bugs in the app which were crashing the app. There were quite many of them such as a splash screen issue, a night-mode bug, video-call crash issue etc. Apart from this I also made some UI/UX changes in the app such as changing the About activity of the app, matching the app-bar theme with the status bar etc.

The main thing which I did in Phase 1 of GSoC was to establish a secure authentication at the initial handshake between two devices. For this, I followed asymmetric cryptography to do the authentication work. Firstly, I created a new table in the database of the app to transfer all the data such as settings data, keypair, database version, MAC address from SharedPreferences to that database table of the app. For the key pair generation, I used the Lazysodium library to generate a public key and a secret key in both appA and appB. After generating both the keys, I passed the public key into the QR-Code of both the apps, so as to share it between both the parties. Now when appA makes a call to appB, an offer is exchanged between the apps which had to be to be encrypted and decrypted. For that, I used a nonce(random string), public key of appA and secret key of appB to encrypt the offer(signalling blog/SDP offer) in appB and then I decrypted the encrypted offer using the secret key of appA and the public key of appB in appA. Finally, the authentication was secured and voice and video-calling were established.

Next Steps

The next phase i.e. the Phase 2 of GSoC 2019, will be about achieving the Internet feature functionality in the app which will enable the app to contact people over the Internet as a fallback option.

Overview

Meshenger App, also known as Local Phone App, is an Android app which allows voice and video-communication without any server or Internet access and works in a local network​. Last year, a successful technical demo of the app was made under GSoC and was also published on F-Droid. This year’s GSoC target is to make the app stable, versatile and to expand the usability and user-base of the Meshenger app, which will directly benefit the community networks as the app primarily depends on it and communication using local networks will always be the foremost priority of the app. The app will be revamped and new features will be added to enhance the app, like allowing calls over the Internet, securing authentication at the initial handshake, fixing bugs/issues etc. which will improve its performance and give a great overall user experience. Here is a link to the GitHub page of the Meshenger App project- (https://github.com/meshenger-app/), which you are all welcome to explore and contribute in.

About Me

My name is Vasu Harshvardhan and I am a student currently in 2nd year, pursuing Bachelor of Technology (B.Tech) course in Electronics and Communication Engineering from Jamia Millia Islamia, New Delhi, India.

I have a special interest towards Open Source Software and have always aspired to be a part of something that could help and make everyone’s life better through technology and contributing to Open Source is clearly the best way to do so. This is the first time I am participating in GSoC as well as contributing to the Freifunk community and through this project, I plan to become a bonafide member and a long-term contributor to the Freifunk organization.

Project Goals

The three main goals of this project are:

• Allowing audio and video communication over the Internet. As the app uses WebRTC library, a special signalling mechanism needs to be implemented for SDP handshakes between the two peers. A STUN server will also have to be enabled for obtaining the public IP addresses of both the clients. The WebRTC will then establish the P2P connection as both the peers have exchanged the signalling data and will be able to communicate with each other over the Internet.
• Establishing a secure authentication at the initial handshake between the two devices. For this, I have decided to use the libsodium library to encrypt the SDP offer/signalling blob that is exchanged by sending it to the other app and fed to WebRTC.
• Polishing the app by improving its UI/UX, fixing issues/bugs etc. in order to make the app stable and boost its performance.

Next Steps

During the Community Bonding Period of GSoC’19, I had researched about the implementations of the proposed features to be added, followed up the codebase of the app and had productive discussions with my wonderful GSoC mentor on this project, Moritz Warning. Following his suggestions, I have decided to first work on the security feature of the app, as it will help me to get into the flow of things and will lead to a progressive and productive development of the app.