3Box Roadmap: The Next Chapter
A look ahead at our big plans for the second half of 2019
Fast forward to today — since November, we’ve earned 13,000 installs of 3Box packages on npm, seen users create more than 2,500 profiles, and mobilized a strong, enthusiastic community that truly understands the value of user-managed data. These numbers continue to grow daily and our outlook couldn’t be more positive on our community and the future direction of the project.
The Next Chapter: What’s in Focus?
Last November, we released our first roadmap. It’s now been eight months since then and we’re excited to release an updated roadmap that outlines what we’ll be working on for the next six months.
Over the next six months, we will focus our efforts on scaling the 3Box network, improving the core 3Box identity system (3ID), and making it easier for projects to integrate with 3Box.
These three objectives are extremely high-leverage. By focusing on them, we will be able to onboard many high value projects in the ethereum ecosystem, and deliver a much improved experience for their end users built around decentralized, portable, user-managed data.
To help us achieve our objectives, we will focus on the following product themes:
- 3Box Network Scalability
- Robust Identity System
- Messaging API Features
- Developer Experience
- Native Mobile Compatibility
- Social Features
3Box Network Scalability
As a project, one of our most important long-term priorities is to continuously improve the performance and decentralization of the 3Box network. In the next six months we will take the necessary steps to begin moving our current architecture to an even more more distributed, peer-to-peer IPFS and OrbitDB pinning network where there are various community members running their own 3Box node.
The first milestone on our journey toward greater decentralization involves migrating our current APIs for getProfile, getSpace, and getThread to
stateless APIs. By serving data to queries via serverless functions, we can operate more efficiently. It’s also a cleaner design that will allow us to easily support an architecture with clustered pinning nodes keeping track of data on the network.
After implementing stateless APIs, will begin running multiple internal
3box-pinning-nodes in a cluster. This will allow us to take the initial steps required to coordinate saving data on multiple nodes, which begins our process of moving to a more peer-to-peer architecture over time.
External, Community-Run Nodes
After we achieve greater scale on our internal networking, we will begin to open up our pinning-node network to make it easier for others to run and operate their own node.
To do this, we will implement a solution for
IPFS pinset and garbage collection, which will allow community-run 3Box nodes to only pin a subset of the data stored on the network that is relevant to them. This improvement will enable apps running their own 3Box node to only pin the data related to users of their application, which is usually contained in their app’s spaces. Additionally with this improvement, users will be able to easily spin up their own node to pin their data. This could possibly be run on something like dappNode.
Robust Identity System
Multiple Ethereum Accounts
We’ve heard many requests from the community that you would like to use the same 3Box profile and data across
multiple Ethereum accounts, so we’re working on supporting this capability. Multiple accounts also moves us in the direction of being able to support contract wallets, which can require that users maintain many auth keys for a single account. Multiple accounts will also allow users to migrate their 3Box account from an old address to a new address.
Contract Wallet Support
As many major web3 wallet providers work to improve the security of their offerings, they’re beginning to implement contract-based user accounts. So we will support
contract wallets too! Soon users will be able to link their 3Box to their smart contract based account provided by their wallet provider. To make this a reality we will be using EIP-1271.
In order to improve the experience of authenticating spaces, which currently requires that users sign multiple messages, we are planning on migrating 3Box authentication functionalities into an
iFrame where we eliminate the need to sign multiple messages by deterministically deriving keys for each space. See 3IP-3: 3ID HD Path. Another benefit of using an iFrame for authentication is that we can display a custom 3Box authentication UI, which will provide users with more detail about the app that is requesting data permissions, thereby improving control and security. Additionally, the iFrame improves security because dapps no longer need to have access to the user’s 3Box keys in order to read and update their database.
Identity API will allow ethereum wallets to have a native 3Box data authentication interface, which will improve the overall security and user experience of permissioning data when interacting with dapps via their wallet. It’s likely this identity API will be built using a standard JSON-RPC interface, so we expect it to be compatible with wallets such as MetaMask and WalletConnect.
3Box Account Onboarding
We want to enable web3 applications to begin onboarding users in a more progressive fashion, by separating the process of onboarding a user and their data from the process of onboarding their blockchain wallet to perform an on-chain transaction. To achieve this, we will create a system for creating and securing a user’s
3Box account with very minimal friction so users can begin creating a profile, using the application, and interacting with other users well before they encounter the friction of being prompted to create and/or link an existing wallet account. This separation of concerns will improve the overall experience of onboarding to web3 apps.
Messaging API Features
Improved Access Controllers
access controllers allow developers to have more control over which users are permitted to post in a thread. Currently, all threads are open threads — meaning anyone that discovers the thread (through various methods, such as visiting a URL where the content is visualized) can add posts to the thread. We will soon enable a variety of access control configurations that allow restricted write access to a thread.
Moderated threads are decentralized message or content feeds that can be moderated by a set of users to control the content. This functionality has been requested by many projects in our community and is the next evolution of our generalized threads concept. In their current form, all messages posted in a thread are immutable, but moderated threads allow mods to remove posts.
Members threads are threads where write-access for posting messages is limited to members of the thread. This is useful for many reasons. Multi-member threads can be used to restrict posting to members of a specific community, and single-member threads can be used for content feeds, such as a user’s status updates or follower lists.
Private threads are threads where read-access for viewing the thread is limited to a permissioned set users, done using encryption. Private threads will power functionalities such as direct messages (DMs) and private group chats between users.
Ephemeral threads allow apps or users to create message threads that exist for the duration of a session, with no saved or synced history. Ephemeral threads are useful for large, chatty, or gossipy channels where many users participate and they might not be concerned with what happened while they were away from the site. Essentially, ephemeral threads enable trollbox-like functionality for every web3 app — similar to the infamous Poloniex Trollbox circa 2015–16. Now, wouldn’t it be cool if we could add a site-wide chatroom to every dapp, especially DeFi trading and prediction apps?
Developers, developers, developers! We’re dedicating significant effort to improving the experience of developing with 3Box. As a result, we will focus on improving our
documentation and displaying it on a specific
documentation site, in addition to continuing to keep it up to date on Github.
As part of our commitment to helping developers more easily build apps on 3Box, we’re writing more
Builders Guides. Builders Guides are tutorials for using the 3Box APIs and other tools. You can read the first guide here: How to Integrate with 3Box Profiles.
We’ve heard requests that we should begin adding more explicit support for various
data schemas in the 3Box protocol, but we don’t want to limit developers to a certain set of schemas because this is generally limiting to how 3Box can be used. In time, we will begin allowing developers to define specific schemas for their data, which will maintain the flexibility of the overall system.
Native Mobile Compatibility
We’re moving to support 3Box on native mobile applications and will first begin with
react native since a few of our wallet partners are written in react native. We will take a phased approach of first using
ipfs-http-api to connect the react native app to a remote 3Box node, and then improve to a more native implementation with the 3Box node running locally. Swift and Kotlin support will be added later, and will be prioritized depending on demand from the community.
followers to ethereum. 3Box users will be able to maintain a public list of ethereum addresses that they “follow.” Since this list is public, it will be available in all the different apps and wallets where a user accesses their ethereum account. Users will now be able to see how many mutual followers they have between another address as an added measure of social security before interacting or transacting.
ENS Reverse Lookup
ENS is a great method of registering and enforcing unique usernames (individual domains) within the ethereum ecosystem. Since ENS names also contribute to one’s identity within the community, we think they are a great compliment to 3Box profiles, storage, and messaging functionalities. As a result, we plan to display the ENS names owned by an address in their 3Box profile, right alongside all their other information. We will also display these addresses inside the profile-hover component.