Every piece of information in the Functionand Data Protocol is encrypted and shielded before it leaves your device. That's how we do things and we wouldn’t have it any other way. But how does it all work? What's really going on when you take a photo and store it on FxFotos app, or save your notes in FxFiles?

The scene

In a typical Web 2 setup, information produced by the user is uploaded to a centralized server. This information is typically encrypted on transit, but often stored on the server side unencrypted. In cases where it is encrypted at rest, the server administrators, operators or app developers often have access to the unencrypted user's data.

That doesn’t sound good, does it? But wait: it gets worse. Aside from accessibility, the integrity of the data itself is typically not verified. For example, there is nothing that can stop an administrator from changing a pixel from red to maroon in a picture that the user has taken and uploaded onto a centralized server. Web 2 has no inherent mechanism safeguarding users from data tampering or alteration.

In a decentralized web, information is stored differently. The data is divided up into interlinked smaller pieces that typically make up a Directed Acyclic Graph (DAG) with pieces scattered across multiple peers. The use of the word "peer" is intentional. Unlike servers, peers are “corporate” in the truest sense of the word: they are united to work together as a single entity. Typically peers share equal responsibilities and importance. Each piece of individual data is verifiable: it is identified by its cryptographic hash and linked to other pieces that are also identified by their cryptographic hash. The thing about cryptographic hashes is that while they are very, very sensitive to changes in data, if given the same data they will always return the same hash. This means if the data is addressed by its hash, then we should get the exact same data. Having asked for data by its hash, the receiver can calculate the hash after having received the data and compare it with the original hash they were looking for.

This property is at the heart of a decentralized web; it is a simple yet powerful property that allows much more powerful concepts to be built up on top. Data in the decentralized web is not always encrypted, but it could easily BE encrypted. Today this aspect combined with built-in verifiability features has fostered a fundamental rethinking of data ownership, sovereignty and privacy.

At this point it’s fair to ask: But does all of this dividing, hashing and interlinking make things more complicated to work with? After all, an app that doesn’t work is no app at all! Photos need to get stored, files need to get archived, and notes need to get saved.

FxExchange Protocol

Enter FxExchange Protocol: Functionland's bread and butter when it comes to DAG exchange. FxExchange is part of the Functionland Data Protocol: given a DAG, the protocol’s job is to quickly and efficiently shift it from one point to another. At its core, the Functionland Data Protocol uses Web Native File System (WNFS) to store your files.

WNFS offers a familiar lens through which to deal with data: UNIX file system files and directories, while at the same time offering a way to encrypt and obfuscate it all into a nifty thing called the “Dark Forest.” (And yes, that’s as cool as it sounds!) As the user interacts with a virtual drive of files and directories, the entire data is encrypted and transformed into a DAG, the shape of which has no resemblance to the original directory structure. This DAG is then sent into the Functionland network for sharing and backup. No-one, except for the original user, can decipher the DAG or see metadata about the original, user-created files or directories.

It also goes without saying that data integrity is preserved by the good old fashioned hashing not only in its encrypted form, but also in its unencrypted form at the originating device.

As soon as one such DAG is generated, the app signals to Functionland’s Data Protocol to sync it to Blox for backup. This is where FxExchange takes over.

FxExchange is built on top of the vanilla GraphSync protocol: a simple protocol for exchanging DAGs over libp2p. It is heavily used by FileCoin Network through another protocol called Data Transfer for exchanging data. In addition, it natively understands DAGs represented in IPLD. This allows the use of sweet IPLD features - Selectors are just one example…but we’ll be taking a look at those in another blog post. (Stay tuned for more!) To learn more about GraphSync, take a look at this document.

FxExchange introduces specific features to control the DAG exchange; namely:

• authorization of exchange between two or more libp2p peers
• authorization management APIs
• push or pull information to/from libp2p peers
• a thin mobile client implementation compatible with gomobile for use in mobile apps
• sync only the absent fraction of a DAG, thanks to IPLD selectors, and finally
• manage multiple WNFS drives that may belong to different users.

Using libp2p as the underlying transport allows FxExchange to continue to function, even in the face of poor connectivity. It also allows FxExchange to opportunistically select the best path for exchanging bytes depending on a given environment. Thanks to built-in support for NAT discovery and Hole Punching built natively into libp2p, FxExchange is able to function on pretty much any network independent of centralized servers. In cases where direct connection is not possible, FxExchange uses the latest libp2p relay feature to transitively connect through other peers in the network.

The control APIs in FxExchange use HTTP-compatible wire protocol for extensibility, sent and received over libp2p go-stream. This offers a familiar interface to developers who wish to extend the FxExchange features, given that most developers are deeply familiar with the HTTP protocol. Concurrently, it enables developers to swap libp2p for vanilla HTTP should the need arise. (This can be useful in cases where FxExchange has to sit behind pre-existing HTTP routing systems.)

FxExchange protocol works hand-in-hand with the FxBlockchain protocol to deliver Blockchain-Attached Storage (BAS) with privacy built right into its core. Stay tuned for future blog posts as we dive deeper into the exchange and blockchain interaction!