Initial Investigations: File IO and OS Integration

Subtask of #1 (closed)

Investigate how Bramble's existing stream import and export system can be used to integrate with outside networking processes.

Android Sharesheet Integration:

Android allows apps to send and receive data through a native UI called the "sharesheet" https://developer.android.com/training/sharing/send

Using a sharesheet system, users could export outgoing Briar messages as encrypted data, and pipe this data to other apps using the sharesheet. This is a similar concept to the core functionality of the Nahoft App (https://nahoftapp.com/index-en.html)

While not explicitly a public mesh solution, allowing public mesh data sharing applications the ability to easily import and export Briar messages would give users a way to share their messages in situations where Briar's current transport stack isn't working.

Filesystem API:

Following this idea of creating easier integrations with outside networking software, we propose a "filesystem api" which will allow outside apps to send and receive Bramble data using normal file IO.

A quick sketch of the 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 watchlist of directories for Briar to periodically scan for new files to test for contact tags

In practice, this could allow easy integration between Briar and outside applications, outside apps would just need to periodically read specific directories, and write files to the other set of directories.

The other aspect of this is that it creates a separation of concerns between Briar, and outside applications which have possibly dangerous behavior. The other side of this is that it could create an easy footgun for users.

This could probably be fit to work as a Bramble transport plugin.

Edit: the core file import/export functions are already implemented for the existing Android "Export to removable drive" feature.

If the goal is to communicate with third-party applications, some type of network sockets might be better, as any program in the userspace might access and monitor those directories, meanwhile intercepting network socket communication is not possible without root privileges (?). See the HTTP/websockets API of briar-headless.

https://code.briarproject.org/briar/briar/-/tree/master/briar-headless

The thinking behind using filesystems instead of something similar to the briar-headless app is driven by a few reasons:

• Async queuing: if we just have a directory that this plugin writes outgoing messages to, we don't need to immediately do anything with the files, no need to run any sockets or actually coordinate connections between any applications.
• Portability: Lots of applications already operate with files, so by going in this direction Briar would receive lots of transport layer integration "for free"
• Usability: "Files" are a computing primitive that even most non-technical users understand, so providing the interface in this form might be more useful for both technical and non-technical users (I have no objective data to back this up just going by the fact that my parents can send emails with attachments and are definitely not technical users )

The privacy and security drawbacks to this approach are definitely serious, my thinking is that

1. Briar already allows a similar type of file export. Though this new approach would be leaking lots more metadata because it is an automated system. Maybe you could do some fuzzing creating fake files etc.
2. This api would primarily be used to leverage Briar's encryption and group chat format over more insecure transports like centralized messengers or public DHT type systems like bittorrent or ipfs, so the user would already be agreeing to lose some security benefits.

I think regardless, building in a simplified API to Briar would need to come with some sort of opt-in system to accompany it.

Also, it might be interesting if you could do websockets or https calls between apps on Android.

REST api:

Another idea is creating a REST api or websocket extension similar to briar-headless

As explained by Nico:

If the goal is to communicate with third-party applications, some type of network sockets might be better, as any program in the userspace might access and monitor those directories, meanwhile intercepting network socket communication is not possible without root privileges (?). See the HTTP/websockets API of briar-headless.

https://code.briarproject.org/briar/briar/-/tree/master/briar-headless

Native Integration:

If an networking solution offers a java/kotlin library it may be possible to natively integrate it into Briar's plugin architecture.