Notes on 3Box

Jon Schwartz
Open Work Labs
Published in
2 min readMay 2, 2019

In our last post, we talked about OrbitDB’s design philosophy — aiming for maximum developer flexibility by staying agnostic to underlying strategies like encryption and identity. This article explores 3Box — an example of an OrbitDB use case with specific implementations of identity and encryption. 3Box provides social profiles for web3 applications, using Ethereum key pairs to handle access-control, account-recovery, and encryption.

Access-control

Applications can request a signature with a specific consent message to read private data or write to a user’s 3Box. The user can sign the message with an Ethereum key pair. The entropy in the returned signature is used to create an encryption key for decrypting private data from the user’s store and a signing key for signing requests to make updates to a user’s store.

An application that doesn’t have access to the signed consent message won’t be able to generate key pairs to write to a user’s store and read private data.

Account-recovery

A user’s OrbitDB key pairs are stored in the browser, posing an identity-recovery problem if the browser is cleaned or changed. 3Box generates Orbit key pairs deterministically from a user’s ethereum address. This means that a user can change browsers or switch devices and maintain their Orbit keys as long as they maintain access to their Ethereum wallet.

Encryption

An Ethereum address has a minimum of three Orbit databases — a root store, a public store, and a private store (other stores might be application specific spaces). In the future, 3Box plans to allow multiple addresses to be associated with an Orbit root store.

The encryption scheme for adding a key-value entry into the user’s private store can be found here. To summarize, 3Box computes a hash of the key the user wishes to store. The value is then encrypted with the encryption key generated from the user’s signature (referenced in the “access-control” section). The hashed key and encrypted value are stored in the user’s private data store.

Schema design

3Box is actively researching IPLD/JSON-LD compatible data structures and has already started storing values (such as the user’s image) in IPLD formats. More work on this area to come.

. . .

At Open Work Labs, we’re working with Autark to build Aragon profiles with 3Box.

. . .

Thank you to the 3Box team for reviewing this post and their awesome help along the way!

--

--