After launching Ethereum Profiles, we wanted to provide the community with a medium-term outlook on our plans for the future. While things are definitely subject to change, here’s an approximation of what you can expect from 3Box within the next six months.
How did we get here?
We launched 1.0
On October 24, 2018 we launched version 1.0 of 3Box Ethereum Profiles and distributed data storage. The community was heavily involved in shaping these initial products, as our friends at Gitcoin, Bounties Network, Kauri, Fathom, Ujo, uPort, SuperRare, and many others helped us scope how we might approach solving one of the biggest problems facing dapps today: the need to simplify user onboarding and make dapps more social.
Our contribution to improving dapp onboarding and usability is that we provide distributed social profiles and data storage for Ethereum users. 3Box allows users to easily create a profile, upload their information, and share it between dapps — which makes signing into dapps as simple as one click.
Profiles also allow dapps to set and get data with users via the Ethereum Profiles API. This allows dapp developers to decentralize more of their app’s data infrastructure, and even makes sharing data between different dapps simple. This opens up the possibility for richer cross-dapp collaborations, as well as various partnerships and experiences.
We aim to connect a more cohesive, frictionless, and social dapp ecosystem. If you haven’t already, try creating your profile at https://3box.io.
We went to Devcon
It’s hard to imagine we’re only four months old; 3Box went from 0 to 1 in just 12 weeks. We were lucky to have the chance to attend Devcon days after launching 1.0.0, which gave us the perfect opportunity to get fresh feedback from our friends and developers in the industry. We heard lots of excitement and feedback and came away with a long list of problems we needed to help solve.
We were also thrilled to hear so much ecosystem-wide focus on building for real people and on the societal impact of the tech we’re building. Glen Weyl’s talk on the last day, especially the section on social identity, felt like an articulation of much of what we had discussed during the design of 3Box. As the week progressed our vision for the future of 3Box became more clear and we knew we needed to share this with the community.
We defined a purpose
Following DevCon the core team retreated to Marrakech. We spent 4 days revisiting our team purpose, product vision, and goals, and found ourselves more clear, aligned, and focused than ever on a shared purpose:
3Box exists to provide social infrastructure that helps people build trust and connection online.
While we have big plans, we remain committed to shipping consistent, iterative releases that solve real problems for our community. We are early in this journey, but thanks to your input we have a good framing of the problems we need to solve next.
What’s coming next?
Improved API Performance
3Box.js is the front-end interface for interacting with 3Box. To improve performance, we’re adding multiple caching layers and offering a GraphQL endpoint.
GraphQL: The getProfile method is currently very basic, and always returns the entire profile of a user. By implementing a GraphQL API in this method you will be able to query for specific properties of a user profile. We are also looking at other ways to make 3Box data more accessible though a more general GraphQL interface.
Caching Service: In combination with our GraphQL interface we will be rolling out a more powerful caching system for public profiles. This basically means that you can load the profiles of multiple users much quicker. For example, this would be important if you’re building a social app that requires populating many participant profiles at once. The only drawback is that you rely on a centralized service.
Local Cache: Improves openBox() load times for users of multiple dapps by creating a shared local data cache. Currently each dapp that opens a user’s 3Box will need to individually fetch the user’s data from the 3Box network. This is an unnecessary overhead and we can do better! With a shared local data cache dapp 1 would fetch the user’s data from the network, but when the user opens dapp 2, the data would already be available so there would be no need to wait and fetch it from the network \o/.
Richer Profiles
3box.io is the main way users manage their 3Box profile, and we heard the desire for more profile fields! By allowing users to enter more information, we can make more data available for dapps using getProfile(). We asked dapp developers what other profile data fields they would like to see users arrive with, and here is a summary of the responses.
New Subjective Fields: We’ll be adding new unverified fields such as personal description, birthdate, location, employer, education, skills, interests, and more.
Verified Fields: We’ll also be adding fields for verified social accounts, such as Twitter and Github, as well as verified contact information, such as email and phone number.
Improved 3Box.io Onboarding: We heard that a few users could have enjoyed a bit more guidance during onboarding. After we add more profile fields, we’ll be weaving them into an overhauled new user onboarding flow, which results in improved comprehension. We may even include links to popular dapps that have integrated 3Box so users can immediately try 3Box with other dapps.
Improved Activity Feed: We will also evolve the activity feed to be more human by integrating various on-chain data services such as registries and other sources of contract metadata. This will allow us to display dapp icons and names instead of hex identifiers.
Application-Specific Datastores
Spaces: Right now 3Box only supports two general datastores for each profile: one public store and one private encrypted store. We will begin developing Spaces, which allows for the creation of application-specific datastores that live within a user’s profile. Each space can store public and private user data, specific to each application.
Spaces improve access control to user data, since data can only be written by the application which created the space and cannot be removed by another malicious application. We will be providing additional details in a spec which will be released in the coming weeks. If you have questions feel free to ask on this issue:
Server Sharding
Scale: Right now we run a single server that pins the ipfs/orbitdb data of our users. This can become problematic as more users start creating profiles, since this server would not be able to handle all of the traffic. The solution is to split the pinning-server into multiple pinning nodes. Each node pins only a subset of all 3Box users. When a user opens their 3Box they will automatically be connected to their corresponding pinning node by communicating over ipfs pubsub. More information will be released on this later as we create a detailed specification of this architecture.
Decentralization: The splitting of the pinning-server into multiple pinning nodes also makes it easier for anyone to run a small part of the 3Box pinning network. You could for example chose to pin only the subset that contains your 3Box profile, and be sure that even if the 3Box pinning nodes go down you will always be able to access your data.
Contacts
Followers: Towards the conclusion of this roadmap, we will implement social functionality that allows users to connect with other users. This makes onboarding to social dapps much easier and seamless, since users can bring their connections with them.
Search: We want to make it easy for users to discover their friends and other members of the 3Box community on 3box.io, so we’ll be adding search.
Hiring
To do all this, we need to add a few members to the 3Box team! If you know any experienced distributed systems engineers, proven product managers, exceptional designers, front-end developers, or technical community/integration managers — please send them our way! You can join the discord below, or send a note to community@3box.io.
