Social Key Recovery Sprint
After our Hackathon in the beginning of August, where we explored the possibilities of a Social Key Recovery app, five adorsyaner set out to refine the functionalities of our initial app in a one-week-long sprint.
In the Hackathon at the beginning of August, we introduced an app prototype for sharing secrets with close buddies. Based on this version, the idea for our one-week long sprint was to refine the existing functionality and especially to develop a prototype that covers the whole process of social key recovery, namely splitting the secret, sending the shards (key pieces) to buddies and finally to recover the secret from the distributed shards. However, before we continued with our app development, the team decided to switch the technology stack and to rebuild the application in Flutter. So why would we jump into a new technology stack, even though we already had a codebase? (I am looking at you sunk-cost fallacy!)
During the first Hackathon, we developed the application with NativeScript and Angular. Initially, this was a good fit as several team members were already familiar with these technologies. Nonetheless, after a more thorough evaluation and experimentation, the team decided to switch to Flutter - a cross-platform (Android and iOS) framework developed by Google. The decision was primarily driven by plugin availability. Required libraries such as Shamir Secret Sharing Scheme (SSSS) or extensive cryptographic functionalities were readily available and could be integrated without the need to develop a plugin from scratch. In the world of cross-platform development, plugins are bridging the gap between native code and the framework’s language. The plugins for NativeScript were either not useable for our project or non-existent. Furthermore, the development of plugins showed to be more time-consuming than expected. As a result, we interpreted the technology change as a ‘lesson-learned’ experience and started from scratch with Flutter.
On the first day of the Hackathon, we rebuilt most of the old features. Next, we set out to build the whole recovery process.
The App now includes the following workflow:
Add Buddies (name, telephone number, connection code)
Create Secret with the option of sharing it - for sharing you must select exactly 5 Buddies. (This can also be done after the creation process).
Recover secret after a new installation e.g. lost device or reinstalled the app.
(only if the secret has been shared previously and after adding at least 3 Buddies that received a shard).
On a more technical level this means:
Storing buddies and secrets in the phone storage.
Splitting secret in shards with SSSS algorithm during the sharing process (Where the current total number of shards is 5 and in return 3 shards are necessary to recover the secret).
Recover the secret with the SSSS algorithm after the key owner initialized the recovery process.
During the sprint, we used two programming techniques which were utilized for different purposes.
Mob programming was mainly used to bring everyone in the group up to date with the technology and the source code. Furthermore, changes that were estimated to have a massive impact on the codebase were also tackled with the “Mob”. As such, important architectural discussions were resolved by the whole group. We also used Mob-Programming to integrate results regularly.
Pair programming was the dominant technique of the sprint as it enabled fast iterations. Additionally, the technique allows for a frequent change in roles (Driver and Navigator), so that everyone is always actively involved in the development and can establish different perspectives on the whole process.
Due to the size of the team (5), one group was acting as a pair (2) and the other team members developed as a mob (3).
We are excited to continue working on this project and are looking forward to developing various features that bring us closer to an alpha version:
Encrypted and authenticated messaging
Improvement of UX/UI
Flexible number of shards and threshold for recovery
Automatic resend if shard can not be transmitted
Add buddy with QR code
Check if buddy still has shard(s) and is available