Public-Mesh-Research-Report.md

@@ -934,25 +934,32 @@ This was tested with the Samsung Galaxy A21s, LGE Nexus 5X and Moto G 4G.
 
 ## Alternative Transports
 
-### OuiSync
+### Ouisync
 
-It is currently possible to transport Briar messages between contacts via a OuiSync repo by using Briar's file export function.
+It is currently possible to transport Briar messages between contacts via a Ouisync repo by using Briar's file export function.
 This idea could be further explored by adding features to Briar to more easily export large amounts of messages, or even automate the import and export of encrypted files.
 
-TODO: Move this to the OuiSync/Briar collaboration report
+A video demonstrating Ouisync as a Briar transport layer can be found here: https://vimeo.com/839579124
+
+TODO: Move this to the Ouisync/Briar collaboration report
 
 #### P2P Connections over Intranets
 
-One open question related to OuiSync and other alternative networking tools is how they perform in situations where there is a national-level intranet that is cut off from the global internet, and two peers inside the intranet want to connect to each other.
+One open question related to Ouisync and other alternative networking tools is how they perform in situations where there is a national-level intranet that is cut off from the global internet, and two peers inside the intranet want to connect to each other.
 If reliable ways to make p2p intranet connections are found, it could be an interesting transport layer for Briar or a similar app to implement.
 
-### LoRa / Ham Radio
+### Filesystem API
 
-TODO
+During our research on using Ouisync as a transport layer, we had some thoughts on an approach to generalize this "file import/export" feature. As Briar already includes the necessary methods to import and export Bramble streams to files, this could be used in an automated way to link Briar with outside Android applications like Ouisync automatically, by using the Android filesystem.
+A description of a possible implementation of this idea:  
   
-### Filesystem API
+- Outgoing messages would be encrypted and written to a list of directories for each contact/group, if there is no assigned directory for a given contact or group, it falls back to either a default directory or is simply not written to a file.
+- Users set a watch-list of directories for Briar to periodically scan for new files to test for contact tags   
+
+This approach is not limited to Ouisync, developers of arbitrary data transport layers could create Android applications also following this file import/export system, allowing Briar messages to be tunneled through outside transport systems like a public mesh propagation application.
+
+For more information visit: https://code.briarproject.org/briar/public-mesh-research/-/issues/23#note_77366
 
-TODO
 
 ## Future Considerations
 
@@ -985,13 +992,26 @@ The soft AP attack unfortunately rules out some interesting options, such as usi
 
 If we're willing to drop support for older devices that don't support BLE peripheral mode then we can consider using BLE advertising and BLE GATT as the basic transport supported by all devices, while opportunistically using RFCOMM, L2CAP CoC, Wi-Fi Direct legacy mode, NSD and LSD for devices and networks that support them.
 
-### Evaluate Briar's Threat Model
+### Evaluate Experimental Transports
+
+#### Packet Radio and LoRa
+
+During this research, we have run experiments on the traditional hardware and software systems of modern Android devices. In the future it may prove useful to evaluate more non-traditional transport layers like packet radio or LoRa technologies. These solutions introduce additional hardware and software requirements, which make them less approachable to the general public. However, packet radio and LoRa technologies allow the transmission of data over 1km+ ranges, which is an extremely useful property when deploying communication networks in situations with no other accessible networking infrastructure.
+
+Projects like [Reticulum](https://reticulum.network) have shown that it is possible to build specialized public mesh networking protocols over low-bandwidth radio hardware, while also offering reasonable encryption and privacy properties, like obscuring the originator of link establishment handshakes.
+
+#### Structured Sneakernets
+
+Completely ad-hoc mesh networks and sneakernets often have issues with message latency and delivery rates. One way we can try to improve these metrics is by increasing the structure of message propagation. Further research in this area could search for ways of creating 'Social Consensus' for message rendezvous points, like finding town squares or popular physical locations for people to meet in order to increase the exchange of messages.
+
+Another area of research is the use of long-range, low-bandwidth transports like packet radio or LoRa, to use as gossip channels for structuring message delivery systems, only sending announcement and delivery instructions over the air, and leaving data propagation to a sneakernet.
 
-TODO: What does this mean?
 
 ### Transport Energy Draw Experiments
 
-TODO: Create a future work subsection in the Mobly section?
+TODO: Create a future work subsection in the Mobly section? Paul: yeah I like this idea
+
+
 
 # Test Automation via Mobly
 
@@ -1093,19 +1113,40 @@ As in the first setup, we used Chrome to check random websites. Except for Googl
 
 When an Android device thinks that its Internet connection doesn’t work, either due to a captive portal or due to certain Google domains being unreachable, apps on the device are still able to connect to IP addresses that remain reachable, and the device can still resolve DNS queries for other domains. Even though various parts of the UI indicate that the system considers the Wi-Fi connection to be offline, the system does not seem to block any traffic as a result of this assessment.
 
-# Routing Protocols [WIP]
+# UI/UX Research
+
+Communication over social or public mesh environments is an unfamiliar user experience for most of the general population. Creating applications that allow the public to use these types of networking systems in efficient ways relies heavily on creating interfaces that are able to communicate the core ideas of the application's behavior, in a digestible manner.
 
-## Existing Research
+From a privacy and security aspect, it is also of upmost importance to give users an interface that allows them to safely interface with other possibly untrusted devices.
 
-# UI/UX Research [WIP]
+During our research we took some time to think about approaches designers could take in order to provide interfaces for mesh networking software.
 
 ## Security Profiles
 
-TODO insert tor screenshots
+One of the core approaches interface designers can take with social and public mesh applications is the idea of "Security Profiles" that give users a fast and clear way of viewing, and modifying the threat level they are currently operating at.
+
+[TODOPIC picture of tor security profiles]()
+
+In tor browser, a popular private web browsing tool, they offer users a set of three different profiles that correspond to different browsing settings which generally match the labeled security level. For mesh applications, this same concept maps nicely to the connectivity profile of a user's personal mesh node. One proposal for a mesh security profiles panel could be a radio select array with three options: 
+- Public Connections
+- Social Connections
+- Trusted Contacts
+
+These levels cover the public mesh, social mesh, and one-hop social mesh propagation strategies, and if offered to users, give them a way to adjust their threat level in real time.
+
+The other important component of security profiles is to give users a quick way to view which profile is currently running. Because some security profiles have serious privacy ramifications, it's important to make the current mode easy to constantly monitor. The other side effect of this thinking is that it should be near impossible for users to accidentally change security profiles.
+
+[TODOPIC fire alarm]()
+
+Fire alarms for example, have been designed to stop accidental activation. A similar thought process needs to be considered for designing the activation UX for less-secure security profiles. Application developers might find it reasonable to make it easy for users to move to more-secure profiles however.  
+  
+A small caveat here though, is that allowing ease of profile switching could allow users to quickly activate public mesh modes in important physical locations, thus increasing the amount of time spent in public mesh mode in active areas, which would lead to an increase in message propagation. This suggests there is not one definite approach to designing interfaces for these use-cases, but more of a balancing act between performance, and keeping non-technical users safe.
 
 ## Connectivity Profiles
 
-TODO insert figma designs
+Besides giving users interfaces to monitor and update their security profiles, more advanced public mesh systems might require interfaces that allow user control over which types of transports a user's node can make. This idea was explored in a mock-up sketch that depicts a chat application that allows for connections to be made via Bluetooth, WLAN, Tor, and a Bittorrent swarm:
+
+[TODOPIC figma images]()
 
 # Appendix