Frequently Asked Questions
Fluid Nexus sends messages to any other device running the software, yes?
Indeed. Fluid Nexus works on an opportunistic, broadcast model whereby it searches for any other device in its vicinity via network modalities that must be explicitly enabled by the user: Bluetooth, and link-local connections over WiFi via zeroconf service discovery. No messages are sent if you are only connected to the Internet via 3G/EDGE. Message passing works by first exchanging unique hashes of messages to determine which messages to send, and then by sending the messages themselves. An example of the client side of the protocol can be found in BluetoothClientThread.java.
So what is Fluid Nexus good for?
Fluid Nexus is an interrogative intervention into new ways to distribute messages and multimedia to as many people as are running the software. It works on a model of transmission where people become carriers of data via movement throughout the world, coupled to a set of local networking technologies that attempt to spread messages to nearby devices.
This means that, under certain situations, others whom you do not know might receive the messages you send, meaning you are implicitly trusting someone else to handle your data. We do this all the time as we use the Internet or the postal network. Yet this is commonly understood to be a major security hole amongst computer security researchers. Nevertheless, we believe that such potentials should not be eliminated tout court, but considered as possibilities useful for certain situations and not others. Fluid Nexus, as constructed, is agnostic towards the data that can be shared, encompassing both digital art as well as pieces of actionable information. We cannot imagine what sorts of uses Fluid Nexus might be put towards, perhaps including creative uses of steganography; however, Fluid Nexus, like most pieces of technology being released these days, should not be used if your life depends on it.
What networking technologies does Fluid Nexus use?
At the moment Fluid Nexus uses Bluetooth and link-local wifi. Bluetooth works on the order of 10 meters and was primarily designed as a point-to-point local wireless protocol. On Android the Bluetooth support is somewhat subpar but we have worked around as many of the issues as we could.
Link-local wifi refers to a local wifi connection before it has passed from one router to another. In other words, if you had a home wireless router, link-local wifi would refer to the possible connections between any of the machines directly connected to your wireless router. Fluid Nexus uses the zeroconf protocol (known as Bonjour on OS X) to automatically discover other devices running the software.
While it may seem counter-intuitive to use a wifi technology in software that purports to not need access to the Internet, it has to be noted that wifi is not predicated on Internet access. Indeed, even if there would be no direct Internet access, devices connected to the same link-local wifi router could still form a network amongst themselves. And if access to the internet was removed for whatever reason, people could still open their wifi routers to enable others to share information using software such as Fluid Nexus.
Everything just said regarding link-local wifi is also applicable if you are connected via ethernet.
We are planning on implementing an ad-hoc wifi feature in the near future, thus obviating the need to connect to an existing wifi network. Unnecessary limitations in most Android implementations are making this more difficult than it should be.
Why does my Android phone require pairing to another device?
Unfortunately the Android OS requires pairing before any Bluetooth data connection can be made. This is beyond our control, sorry.
Why can't other devices see my Android phone using Bluetooth?
Unfortunately Android has an annoying "feature" that limits discoverability to only 120s or 300s at a time. This is ostensibly for security purposes. This is a known "bug" that is theoretically fixed in later versions of the OS. There is nothing we can do about this other than popping up an authorization windows every 120s—which is something we don't want to do. One way to get around this is to ensure that any Desktop devices you have running the software are set to be discoverable; however, there are security implications for doing this so be sure you understand them before doing so.
Additionally, you can pair the devices you are interested in connecting to prior to use of Fluid Nexus in the field. The Android application will always try and connect to paired devices—if they are nearby—along with any other devices that it discovers. Once an Android phone has paired with another device, it will always be able to connect to it (assuming it's in range), regardless of its discoverability.
Finally, we have provided the option for users to make the device discoverable for a short period of time through a menu option.
Is information passing through Fluid Nexus encrypted?
There's two issues to consider here: encryption of messages stored on a device, and encryption of messages as they pass from one device to another.
Regarding encryption of stored messages on a device, at the moment on Android, messages are stored encrypted (using SQLCipher), but received files are not. On the Desktop, we do not plan on implementing any form of message encryption within the software itself. We believe encryption on platforms like Linux and Windows is better taken care of using native tools, such as an ecryptfs encrypted home directory, LUKS encrypted disk, or TrueCrypt encrypted volume. All of these options already exist, but it is beyond the scope of this FAQ to explain how to set them up.
Regarding encryption of messages and data as they pass from one device to another, we do not necessarily see the point of this given the current broadcast model of Fluid Nexus. Since anyone running the software will receive all messages sent by other users, encryption does nothing to prevent eavesdropping; all someone has to do is run a copy of the software in order to read the messages. This is by design; Fluid Nexus is meant as an experiment in a distributed network, an intervention into network topology. There are all sorts of ways to obfuscate messages so that even the most innocuous looking text or image can hide something else. With that said, we do utilize the encryption facilities of the native bluetooth stacks on Android, Windows, and Linux by setting up secure RFCOMM sockets.
How can I send encrypted files using Fluid Nexus?
It is possible to send encrypted attachments right now. All you have to do is encrypt the file offline using another piece of software such as Android Privacy Guard (APG) (making sure to retain the same file extension as the original) and then add the file as an attachment to your message. Others won't be able to view the attachment. The message text will be sent in plaintext, however. Your recipient will have to know to decrypt the message offline. All attachments are saved in the folder
FluidNexusAttachments at the root of your internal SD card.