Requirements document for Sonnet native app

Sonnet Native App Requirements.md

Sonnet One Native App Feature Requirements

Last updated Jul 31, 2019

This document is a high-level description of the various features currently present in the Sonnet One front-end web application and Cordova-wrapped native app that will be used to define requirements and an API for the React Native app.

Any features that we weren't able to implement in the Web environment but we plan to implement in the native app are marked with (unimplemented).

Introduction

• Wireless communication via infrastructure normally available in well-developed and populous areas is not always efficient or possible in remote areas that lack effective network infrastructure, or even infrastructure at all.
• Existing solutions such as statically planned wireless networks based on base stations and relays, or satellite communication, are either expensive or unable to adapt to changes in the environment or operating area.
• We are offering a device running software that allows existing mobile devices to communicate with each other via mesh networks.

Intended Use

• For use by travellers, remote workers, or people needing a reliable way to communicate with nodes in a mesh network.

Definitions

• "Device" - the Sonnet unit
• "Phone" - the user's Wi-Fi and Bluetooth enabled smartphone
• "App" or "webapp" - the front-end facing application running on the user's phone
• "Firmware" - the software running on the Sonnet device

Overall Description

User Needs

The general categories of needs fall into these three:

• Communicate with other people in the mesh network (and locally if more than one device is supported)
• Adjust operating parameters and settings via the user-facing application
• Update device firmware through the application

Assumptions and Dependencies

• User's phone is a smartphone capable of wireless connections, including but not limited to Wi-Fi and Bluetooth
• User's phone is within the wireless connection range of the device
• Both user's phone and device are ON
• Device is not submerged in water or under other extreme environmental duress
• Device's battery is charged sufficiently for operation of all modules

System Features and Requirements

The native application features can be broken down into the following groups:

Top level

Must:

• Run natively on a smartphone, including iOS and Android
• Be able to respond to incoming data from the mesh network at any time while the device is operational
  • This means push notifications when the app is not in the foreground
• Have core messaging functions with or without Internet access
• User data such as name, messages, contacts must be stored independently of Sonnet devices
• Native app must be able to work with any Sonnet device with a compatible firmware
  • API & schema versioning system to ensure compatibility between app and device software (unimplemented)
• Show some indicator if the data connection between the app and the device has been broken
• Allow the user to try and reestablish the connection when it has been broken

User Management

Must:

• Enable the user to register one or more accounts to associate messages, contacts, and other data
• Allow user to access chat interface only on successful login (matching username + password) reject user access if login unsuccessful
• Allow the user to change their name at any time

Contact Management

Must:

• Show a list of contacts that the user has stored
• List must be filterable or searchable by text
• Online contacts must be distinguishable from offline ones
• Tapping on a contact's name in the contact list must open up the corresponding chat with that user

Adding contacts:

• Enable the user to scan the mesh network for other users currently connected
• Enable the user to send requests over the mesh network to other users, to store each other's information and monitor each other's on/offline status.
• Enable the user to ignore requests from other users
• The requests should set up a message encryption scheme
• Enable the user to delete saved contacts
• Enable the user to add other users by scanning a unique QR code for that user using their phone's camera
• Show the user some notification or indicator when another user has sent them a request
• After one user has accepted the request of another, a 'hello' message should be sent from each user to the other
• This message may be spoofed and sent from each user to themselves, except the originator is set to be the other user

Messaging

• Must enable users to send messages of various types, including but not limited to:
  • Text
  • Images
  • Locations (GPS)
  • Audio (unimplemented)
  • Raw files
• Messages must be organized by chats between the user and each contact
• After sending, each message must eventually display a receipt displaying either if it was received, or if not received
• Messages are shown in reverse chronological order (newest at the bottom)
• Each message must display a timestamp
• Messages must be encrypted in transit within the mesh network
• All messages for all users on that phone must be stored on the phone somewhere, not on the Sonnet itself
• Users must be able to create and join group chats.
• Users can send and read messages from each other in a single chat
• A single user in the group is the 'leader'. The leader is the only one who can add or remove people from the group.
• Users in a group may see a list of who else is in the group.
• The leader must invite other users to join.
• Currently, users who are invited to group chats automatically join.
• All of the above message types must be supported
• Each group message must display some kind of information that can be used to identify the sender

SOS

Must:

• Be able to send SOS broadcast to all users directly connected to the Device
• The Device must relay (re-broadcast) the SOS broadcast to all devices it is connected with directly
• The SOS message contains following two pieces of information:
  1. A pre-written message left by the owner of the Sonnet device during the configration phase
  2. The last known GPS coordinates of the Sonnet device
• Receiving device must be able to receive the SOS broadcast with a popup window regardless of the current screen

Maps

Must:

• Show a list of available maps by region, only when connected to Internet
• Be able to view any downloaded maps
• Locate the user on a map, if the data is installed
• If map data is available, open location messages by opening the map and highlighting the location
• User must be able to download or delete map data to/from their device, with authorization (see Settings below)

Settings

All users must be able to view or do, at any time they wish:

• The current battery level of the device
• Logout of their account via a settings menu.

An administrator must be able to adjust:

• The currently installed firmwares (mesh, system)
• Connections to nearby Wi-Fi networks
  • connect + save
  • disconnect
  • delete
• The device's Wi-Fi SSID + password
• Offline map data
  • view available regions
  • download
  • delete
• Radio parameters
  • Antenna (internal/external)
  • Frequency
• Settings password
  • Anyone can initialize
  • Only admin can change/update it

Authentication System

The administrator settings must be protected somehow via an authentication system.

• Any user may initialize a settings password if one has not been initialized yet.
• Any user may provide a correct administration password once one has been initialized (see above)

The administrator must be allowed to make changes in sessions. A session is a period of time where the administrator does not need to authenticate or provide primary authentication credentials (eg. username, password) in order to make changes.

• A session lasts for a predetermined amount of time
• A session is renewed whenever a valid change to administrator settings is requested
  • Valid meaning valid session
• If no actions or changes are requested by the administrator, the session times out
• The admin must re-authenticate in order to continue making changes

Other Requirements

Security

Must:

• Safeguard all user data so that only someone who knows the password to one's account may access it

Errors

Must:

• Properly communicate any errors to the user in some way, so that they are not confused if they end up in an error situation
• Notify the user if there is any potential incompatibility between it and the device or any part of Sonnet's remote infrastructure
• Provide instructions or a link to information on what to do if a critical error occurs (eg. requiring reinstallation of the app or factory resetting of the device)
• Avoid, at all costs, putting the device in an irrecoverable state (ie. bricked)

When I'm got my sonnets? Why your team ignore community on Indiegogo?

Yes, I'm very much looking forward to getting my hands on the finished devices too :)

But some comments?

• A single user in the group is the 'leader'. The leader is the only one who can add or remove people from the group.

I would add:

• The leader is able to pass the leadership role to another group user.
• Either user in a two-user chat can 'Add User' to automatically create a Group Chat, become the Leader and send the invitation to the Added User.

• After sending, each message must eventually display a receipt displaying either if it was received, or if not received

I would add:

• Each message will visually identify the status of each message, i.e. if it has been sent, pending download, received or read.
• Each message will display meta data associated with the message in a separate screen, detailing: status, datetime sent, datetime received, datetime read, message size, and other relevant data.

Love the spec for the app, I really hope an API doc is also made available as I'm a web dev and would like to make a PWA for the sonnet.

In regard to user accounts.
Will a phone hold a uniqe identifier (i.e. uuid) that ensures that even if I move between sonnets I would received messages within the mesh?