In 2017, during crypto’s last bull run and after years of pointedly ignoring blockchain hype, I jumped down the rabbit hole. I began to see crypto networks as the best coordination tool we’ve ever had. I met the most passionate, curious, interesting people I’ve ever worked with. And I loved that the challenges to overcome were organizational, economic, and political as much as technical.

In the past four years, I’ve collaborated with dozens of teams, helped found 3Box Labs (a company) and launch Ceramic Network, and worked with several DAOs. The potential, challenges, and excitement in the space are still similar to 2017. But the range of experiments, opportunities, and team types is now incredibly broad.

What to consider as you jump down the rabbit hole

1. Join a community, not just a team.

One of Plaid’s hiring criteria was “Did they read the docs?” In the crypto space, it’s “Did they join the community?”

Hop into the discord or slack, get a sense of the developers and users and how they are engaged. Picking a team without understanding the community would be like getting engaged before meeting your partner’s friends or family.

2. Be honest about what you’re in it for, and choose accordingly.

The pace of activity in the space is completely overwhelming. Make sure you land in a spot where that will drive your motivation not drain it.

If you enjoy constant, multi-disciplinary, frenetic learning and excitement, happy hours that veer back to interesting ‘work’ topics, and the feeling of a quasi-cult-like movement — you’ve found your tribe. Look for teams that were building through the last few years’ bear market. Protocol teams, DAOs, and the early DeFi builders. Join one working on something you really care about because you’ll need deep motivation to keep focus and energy.

If you want more balance or stability, the bull run has given rise to more traditional companies — exchanges (the new banks), infrastructure providers (picks and shovels), and creative studios — that build on this movement but in a more familiar setting. It’s a bit more sustainable and ‘normal.’

If you are in it for the money, there are plenty of DeFi projects with millions of dollars to spend. Or consider keeping your stable income and investing it in crypto.

3. How do you like to work?

While the world has been adjusting to remote work, many crypto teams are native to it and push organizational experiments far beyond that.

• Do you want an office with teammates? Select for this, as most are remote
• Real-time or asynchronous? Plenty of teams work purely off PRs and tickets, gaining massive flexibility but losing face time.
• Radically flat, traditional org structure, or experimental? Do you want the empowerment promised by new org designs or the clarity of clear structures?

Could you work for a protocol?

Many projects aim to (or already have) pass most power to a DAO or community. See how Yearn Finance describes itself. Does the idea of working with complete freedom and a loose association with other community members excite you and feel like the next era of organizations? Or does it seem like the death of coherence, agility, and coordination at scale? Understand a team’s long-term plan for the company and DAO, and if/when that is in the future.

4. How do you gauge progress?

Teams have different DNAs for how much to focus on technical advances, growth and sales, the long-term vision, or product adoption. This gap is wider than normal in the blockchain space because we’re so early — there’s so much green space, less obvious metrics, more delayed feedback, and some self-delusion about what’s working and what’s not.

Understand if teams are engineering, vision, or product-led and what the upsides and downsides to this are, and think about whether those will match your own instincts. If you are instinctively drawn towards growth but the team holds ideology more dear, you could be very frustrated with the roadmap and strategy.

5. Understand crypto compensation.

Startup employees are used to salary, bonus, and equity. In crypto, there are also tokens. They are more liquid, more volatile, often higher upside, and sometimes far less tax-efficient than stock options. Know your situation and what combination of income you care about, and make sure the team you join is keeping the incentives of the founders, team, and investors aligned for the long term. This article offers a good primer.

6. Principles and values matter more than ever.

Culture is what defines behavior in the absence of clear rules, and in projects with smaller teams and bigger communities, the early norms and values carry more burden than ever. Understand both what the team stands for and how they instantiate their values in their operations and their community.

As Vitalik said, “Even a billion dollars can’t compete with a project having a soul.” Make sure you believe fully in the culture being created and can see yourself as one of its core carriers.

3Box Labs is hiring

At 3Box Labs, we are on a mission to transform the web’s relationship with data. If you are impact-driven, curious and bold, and care deeply about improving the web, we’d love to hear from you — we’re hiring across our Engineering, Product, and Growth teams.

Our team is built around 1 purpose, 5 core beliefs, and 8 guiding principles as we work to build a community that can have as much impact as our tech. This means:

• Tangible impact on the future of the web from the center of the decentralized tech movement
• Ownership over novel challenges as we scale and tokenize Ceramic Network
• Collaboration with a world-class technical team (and partners) to create protocols and products
• Constant feedback and usage from a rapidly growing open source community
• Remote and flexible work, with frequent regional meetups and team retreats in amazing places
• Huge upside through equity and the network, globally competitive comp, great benefits

Find all our open jobs here, or reach out to jobs@3box.io and tell us what you’d like to do and why you’d be a great addition.

3Box Labs | Ceramic website | Twitter | Discord | GitHub | Documentation | Blog | IDX Identity

Thinking of getting into blockchain? 6 things to consider was originally published in 3Box Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

On May 25, enforcement begins under the European Union’s General Data Privacy Regulation (GDPR). This long-awaited regulation attempts to put the genie of digital personal data back in the proverbial bottle. Web companies were the first to realize the potential goldmine that is user data and began building businesses around it, attracting users and profits through a model of free services that generate data to sell or consumers to target. ~20 years into this model, public opinion and law-makers have realized the huge costs we’re suffering by letting people be turned into the product. Data breaches and abuses are perhaps the most visible, but huge inefficiencies and massive power in the hands of a few internet monopolies may be just as impactful.

Many businesses are scrambling to meet the new compliance standards. It’s a sweeping regulation that impacts any business operating in the EU, collecting data from EU citizens, or doing any business in the EU, so the impact is global. Interested observers are waiting to see how some of the more vague language will be interpreted and how aggressively regulators will pursue potentially massive fines (up to 4% of a company’s global revenue). Meanwhile, a few are pondering a very different set of questions: how do regulations built for Web2 complement the new models we are building for Web3?

New cryptographic and decentralized technologies — most notably blockchains — have the potential to build data privacy into the core of digital systems. Developed while the GDPR and similar regimes were being drafted, the spirit of the technology and regulations are kindred: more control in users’ hands, more responsibility required of 2nd and 3rd parties. But it’s unclear in ways how the ‘letter of the law’ will apply to this new technology.

Thinking about how these simultaneous legal and technological changes, and shifts in social expectations, interact is key to planning for a more privacy-preserving future. While there are a few apparent incompatibilities — for example, the right to be forgotten on an immutable ledger — good design principles that help all parties make informed decisions can let these operate well together. Regulations and new technology that aim for ‘privacy by design,’ along with mounting public pressure for good data controls, can combine to usher in a new age of data privacy and user-control.

Private protections via public ledgers

Blockchains like Ethereum are public ledgers: they store pieces of data on a shared system that anyone can access, and nobody can delete. One of the things this enables is a new ‘identity layer’ for the Internet, giving users control of their personal data.

This would change the dynamics of digital interactions, likely altering the currently popular model of collecting and monetizing vast amounts of consumer data — the practice that led to regulations like GDPR. This new dynamic is now possible because decentralized technologies can let us build a decentralized consensus around who somebody is, rather than relying on centrally built and managed silos like Facebook or governments.

There’s an irony to using a public ledger to enable and protect private data. If personal data were put on Ethereum, that data would be permanently public for all to see and use. That is, of course, not what we’re doing at 3Box. As detailed in our approach to privacy-preserving identity, this new system relies on a public ledger but minimizes what data is actually put there.

All that needs to be stored on-chain is decentralized identifier (DID), which is just a random string of characters. It’s currently not explicit whether these addresses will be classified as personal information under GDPR. Some precedent and the treatment of IP addresses suggests it may, at least in some cases. However, the DID itself tells nothing about the user: it is simply a random public address that a user claims control of through a private key in order to interact with others via a decentralized identity.

The personal data associated with a DID is controlled privately by the user. This data can be stored on private servers and encrypted so nobody but the user has access, can be pseudonymous so even when the user shares it doesn’t tie to their identity, and can be deleted anytime the user chooses. The only thing public is coded ‘pointers’ between the users DID and servers where the information is stored.

Multiple keys are used so that even pseudonymous identities can’t be correlated. In 3Box’s system, a user can have many keys linked to a given identity and many identities, giving many ways to manage sharing or pseudonymity.

This combination does require thoughtful design to help users, who act as their own data controller. Personal data does not need to be stored publicly — but it certainly can be. Many products, proposals, and open source projects would enable users write personal data to a blockchain if they chose to, and once this is done it cannot be undone. While we cannot control what’s possible in a world of open-source software, we can help developers and users make good decisions. GDPR does not really anticipate situations in which the user is their own controller, and their own legal obligations to themselves.

Done right, users never have to disclose their personal data publicly and get all the benefits of an immutable, user-controlled transaction history. As one example of the flaws of today’s system: 21% of credit reports have erroneous data in them. Immutable transaction records would enable proof of origination to prevent this (and the billions of dollars spent each year on identity resolution, with companies trading user data back and forth), while not requiring that users ever disclose their personal data.

This system isn’t just more secure, it can be more private and far more powerful. Not just for users, but for businesses too: it will make it possible for companies to deliver the same or richer user experience without the risk & cost of holding customer data.

Adoption through value, not just compliance & tech

It’s great that the EU is taking serious steps to curb data abuses, and GDPR may have a significant impact on corporate responsibility. It’s doubtful it will lead to wholesale shift in how data is treated today, with it primarily in the control of organizations. And while public opinion seems to be shifting to demand more security and privacy, convenience and complacency still reign in many cases.

To shift Web3 to a user-centric model, with data truly in the hands of users, will require something more: value. The new model and technologies we are creating ultimately need to show their worth not through ethics and laws but through products and services that give people and organizations obvious value. And while we have work to do, our model will provide enormous reasons for identities of all types to adopt:

• Save users from identity theft and data breaches (Equifax alone cost an estimated $4bn) and protect organizations against cybercrime, estimated to be $6tn by 2021
• Give consumers a route to some of the $100bn+ that Facebook & Google collect in ad revenue, and businesses a more effective way to discover and serve their highest value customers
• Make large data sets & rich customer histories available to startups, reducing barriers to competition
• Give users infinitely granular control over their devices, accounts, relationships, and digital services
• Reduce the 83% of adults who worry about identity theft, and the 40% who lose a password every week

The GDPR in Europe may lead to some huge steps in curbing data breaches and giving users more control. It remains to be seen how regulators will treat public ledgers, a relatively new and unconsidered technology, but we’re confident they are complementary. The identity models being built on blockchain tech can not only enable the privacy and security the law aims for, but can drive widespread adoption of data rights and protections well beyond what the regulation calls for.

Join the conversation in the 3Box discord community.

Entering the age of data privacy was originally published in 3Box Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Reducible identifier

Identity as a concept is difficult — even scholars in the field can’t agree on a definition. They do agree, though, that identity for each of us is not singular and static but rather plural and dynamic. Who we are changes over time and contexts. However, we as people and societies and institutions need something concrete to pick me out from the crowd of others, even others who may share my same name. In Seeing Like a State James Scott calls this ‘legibility.’ When we get past local communities and the Dunbar number, we need to make society understandable. We reduce things to lists and bits of information, and one of the must fundamental bits of information is who we are.

We need a legible, concrete, reducible identity. This leads to passports, social security numbers, and other root identifiers from the physical world. Much of the work in the identity industry is around verifying and authenticating who somebody is in this regard, whether through knowledge questions, facial or bio metric scan, or proof that they know a password or hold a private key.

2. Contextual identification

While reducible identification is critical to anyone trying to keep track of a group, it doesn’t actually tell us much about the person who has been identified. Context about that reducible identity gives orientation to who the person (or otherwise) actually is. Traditionally this may include where somebody lives (driver’s license), who their parents are, what tribe (including nationalities, teams, gangs, political affiliations, religion, etc) they are a part of, or who their employer is — anything you might fill out on a test or census form. More recently, this would include a person’s social graph (Facebook friends, LI contacts) and location data.

This may be static or dynamic information, but it’s not ephemeral — it roots them in time and space. As we move to a more digital-first world, and hopefully soon a self-sovereign world, we talk often of capturing this contextual information as ‘attestations’ or ‘verifiable claims’ to our root (reducible) identity, giving us a way to bring all the context about us together in a powerful, private, verifiable (trusted) way.

3. Dynamic identity

A reducible identifier and contextual identification provide a way to differentiate each other, to verify who somebody is and know some categorical details about them. But they do not tell you who somebody is. The richness of our identity is captured in the multitude of behaviors, preferences, relationships, interactions, histories and even thoughts. Only here can true identity — the plural, dynamic identity — be seen. One persons preferences and behaviors may contradict each other over time, and often do, so this cannot be captured in a reducible and ‘verifiable’ context. It is only captured when our goal is to understand who somebody is deeply, rather than pick them out from a crowd of others.

In today’s world, data reflecting who we are is being generated and captured constantly. With much of our lives online and in our phones, and sensors cheap enough to put on everything, nearly all our interactions with the external world can be turned into digital data. In fact, our internal ‘data’ — health, mood, biological patterns is now logged as well. This is infamously captured and monetized by Facebook and others, but it is also incredibly powerful. If put in control of users and creators of data, we can build a world that lets us use this rich data to truly understand the people around us far better than ever before, and as far more than bits of reducible and contextual information.

In fact, with rich, full identity data, we could understand our dynamic selves far better than previous identity construct have allowed us. In Homo Deus Yuval Harari envisions a breakdown of the singular ‘self’ into a multitude of biological signals and patterns and interactions, changing the very notion of identity — perhaps an indication of why this concept proves so hard to nail down.

The 3 parts of identity in a dynamic world was originally published in 3Box Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

The future of Web3 identity has arrived

IDX is a brand new SDK for building with decentralized identity and user-centric data from the 3Box Labs team. IDX is in alpha but if you’d like to start experimenting, join our discord and jump into the docs.

A new era for Web3 development

The Web3 vision for an internet that is open and interoperable, where users control their information requires a decentralized, cross-platform identity system. To this end, IDX is an open source JavaScript/TypeScript library that exposes high-level developer APIs to various meta-protocols and standards for decentralized identity. Not only is IDX powerful and flexible enough to meet all of your user and data management needs, but it wraps everything in an easy-to-use package that makes decentralized identity accessible to all Web3 developers.

Designed to be cross-platform and highly configurable, IDX is compatible with all blockchains, wallets, and a wide variety of user and application data storage options including Ceramic, Textile, OrbitDB, Filecoin, IPFS, Sia, and Secure Data Stores — so you can seamlessly integrate decentralized identity with the rest of your Web3 tech stack. With IDX, developers can now build much more sophisticated and powerful Web3 applications that rival and even exceed what’s currently possible on Web2.

Why decentralized identity?

If you’ve ever asked yourself any of these questions, then you should definitely consider adding a decentralized identity system to your development stack.

• How can I create a universal identifier to associate data resources from a variety of platforms to a single user?
• How can I improve my user experience with decentralized social profiles?
• How can users create a unified Web3 identity that links many different accounts within and across various blockchain platforms?
• How can users establish trust and reputation by connecting their Web3 identity to existing Web2 social accounts (i.e. Twitter), various anti-sybil systems (i.e. BrightID), domain names (i.e. DNS, ENS, Handshake), and identity verification services (i.e. KYC)?
• How can users create a universal and portable social graph of followers, friends, and contacts?
• How can I store user and application data in various centralized and decentralized data storage technologies in a way that isn’t siloed to my application, gives users ultimate control and portability over their data, and works with all of their existing wallets/accounts?
• How do I discover and import data that a user has created on another application, platform, or network so that I can use it inside my app?

IDX: An open identity framework for Web3

Decentralized identity and user-centric data management are complex, broad-ranging capabilities that touch almost every other aspect of your app architecture. IDX removes the all of the guesswork from implementing these in a scalable and future-proof way.

Build with unified digital identities

Using IDX, all applications can access a shared, globally-available identity layer that contains unified users identities. Built 100% on permissionless protocols, IDX enables users and their most important information to seamlessly flow and interoperate across platforms, while giving users the ownership and control they demand. In a way, the identity capabilities offered by IDX sort of function as a decentralized Keybase but with much greater flexibility and decentralization.

The core of each identity consists of a decentralized identifier (DID) which acts as a globally-unique ID and an identity index which keeps track of an identity’s information. IDX allows developers to deploy identities as well as create, read, update, and delete a variety of metadata and information related to the identity, including but not limited to:

• Multiple user profiles for different contexts or applications
• Portable social graphs, from followers to contacts and family
• Links to multiple blockchain accounts from different protocols (Ethereum, Bitcoin, Polkadot, NEAR, Flow, etc)
• Links to existing social accounts (Twitter, Github, Discord, Matrix, etc)
• Links to domain names (DNS, ENS, Unstoppable, Handshake, etc)

All DIDs, identity indexes, and metadata are securely stored on Ceramic’s permissionless document management network. Because all information is publicly available (but optionally encrypted) and linked via the identity index, any bit of information can be cross-resolved by querying based on any other information. For example you could lookup a user’s profile based on their DID, their Ethereum account, or their Twitter handle; or you could lookup a user’s Filecoin account based on their Polkadot account. We are working with The Graph on indexing these identity structures which will open up many new opportunities in this realm.

Integrate with data storage solutions

Unified identities are the gateway to a world of additional functionality for your application. If you also need a way of storing and managing user data, you have three main options.

• Use the IDX library to directly store documents on the Ceramic Network and add references to those documents in the user’s index. For this option, no additional software is needed; it works out of the box with IDX.
• Store data in alternative data storage systems such as Filecoin, IPFS, Sia, Arweave, Textile, OrbitDB, Secure Data Stores, or Ethereum contracts and use IDX to add references to this data in your user’s index. For this option, you would need to separately install these technologies in your app alongside IDX.
• Use a combination of the different data storage solutions above for your application, each with their own strengths and weaknesses, while mapping everything in your user’s IDX.

Whichever data storage configuration you choose, IDX allows all data to be controlled by the user, discoverable by others, and portable across platforms. This is true regardless of where the data resides (servers or decentralized networks) or which application first created the data.

Share data across applications and silos

As described above, the key aspect of IDX that de-silos information, promotes interoperability, and enables user control is the identity index. It provides a standard interface which allows any application or developer to set and query all available data that belongs to a user so that they might make use of it within their application. The identity index serves as the information root for each user and makes everything discoverable.

To further promote interoperability, the identity index allows developers to:

• Publish schemas, names, and descriptions for data points they are adding to the index, so others can more easily consume this information
• Publish endpoints for where this information can be found, whether a DocID on Ceramic, a CID on IPFS/Filecoin, a contract on Ethereum, or an endpoint for a hosted service
• Request permission to access encrypted data points in the index

Developing with IDX

The following section outlines how to get started building with IDX. For more supporting materials, read the docs.

Installation

First, we’ll need to install the main IDX library and associated dependencies:

npm install @ceramicnetwork/ceramic-http-client @ceramicstudio/idx @ceramicstudio/idx-constants

Query an identity

Then we can use these libraries to connect IDX to a Ceramic network and interact with the documents associated to a given DID. This example shows how to simply query the basic profile for a given user.

import Ceramic from '@ceramicnetwork/ceramic-http-client'
import { IDX } from '@ceramicstudio/idx'
import { definitions } from '@ceramicstudio/idx-constants'

// Use Ceramic devnet
const ceramic = new Ceramic('<https://ceramic.3boxlabs.com>')

// Use IDX-provided definitions aliases
const idx = new IDX({ ceramic, definitions })

// Get the basic profile of a known DID supporting IDX
async function getProfile(did) {
  return await idx.get('basicProfile', did)
}

Save data

More advanced examples involving authentication and setting content can be found in the IDX documentation.

Remember, IDX is still in alpha. If you have any questions, comments, or feedback on what we’ve built or how to use it, please reach out on Discord.

About

IDX is an open source library that is built and maintained with 💜 by the 3Box Labs team, creators of 3Box.js, a leading decentralized identity and data storage solution for Ethereum that has been used by 30,000+ users and 1,000+ projects. IDX is a smarter, mature evolution of 3Box.js. All DIDs and profiles created using 3Box.js will be automatically migrated to IDX once the library goes into production. We are working on various solutions to migrate user data that has been saved in spaces and threads to other IDX compatible data storage systems including Ceramic, Textile, and OrbitDB. If you have questions about this migration process or timeline, please reach out.

Resources

Website
Docs
Discord
Github
Twitter

IDX: A Devkit for Open Identity was originally published in 3Box Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 2: Team lists

Intro

Welcome to the second part of our todo app tutorial, built with 3Box confidential threads. If you haven’t visited part one, check that out first. Here we build out the scope of our todo app to accommodate team todos. This is where the power of confidential threads really shows. Outside of todo lists, there are many applications for confidential members threads; private messages, censorship resistant social media, team chat, and more. Lets start by building our collaborative, confidential task list.

👉 Check out the demo here

🛠 Completed tutorial codebase

What you will learn in this tutorial

Members Confidential Threads

1. User flow for joining confidential members threads
2. Creating a confidential members thread
3. Recording team members opening the applications space
4. Adding team members to the thread
5. Retrieving team posts
6. Adding posts
7. Updating the UI
8. Testing the UI
9. Adding the profile hover component

Setup and Tech Stack

This tutorial is a continuation of Part 1 , so complete that before starting. We will be using the same tech stack.

• React — frontend framework
• IPFS + OrbitDB — where the data is stored (provided by 3Box, so we won’t need to touch this directly, no need to install separately )
• MetaMask — Web3 wallet integration (required to facilitate signing and encryption of data)
• 3Box.js — 3Box SDK that connects wallets to IPFS database storage via 3ID
• Profile Hover, and Profile Edit Plugins — drop-in React components that we will use to speed up UI development
• React Bootstrap— UI Library

1. User flow for joining confidential members threads

Before we start coding, let’s describe the process we will use to handle users joining the confidential thread:

• Start with a hardcoded list of ethereum addresses for team members
• The moderator will also be hardcoded
• When the moderator logs in, we create the confidential thread and save its address in a public space (called waitingRoom)
• In order to be added to the thread, we need to ensure each team member has opened the space previously
• Once a team member opens the space, this will be recoded in a public thread
• Whenever the moderator logs in, they will check the public thread for team members to add to the thread. On adding them, the record in the public thread is also updated
• Returning to the site, team members will be able to add and modify todos on the team page

Lets start by adding the hardcoded list of team members and moderator to the component’s react state (see example):

state = {
    posts: [],
    newTodo: "",
    moderatorsAddress: '0x2f4cE4f714C68A3fC871d1f543FFC24b9b3c2386',
    addresses :[
      '0xab74207ee35fBe1Fb949bdcf676899e9e72Ec530', 
      '0xFF326878D13b33591D286372E67B4AF05cD100bd', 
      '0xbaeBB7d18f8b16B0A970FDa91f1EfA626D67423E', 
      '0x5c44E8982fa3C3239C6E3C5be2cc6663c7C9387E', 
      '0xa8eE0BABE72cD9A80Ae45dD74Cd3eaE7a82fd5d1', 
      '0x5a7246af4fefe777e32399310b50bb7fe2d04f8a', 
      '0x18B14A7d061B504C75C7027738d16dcED739b2E9', 
      '0x5031f308AD02Ed86F44c586aD2B01ae55D034C7a',
      '0xB3B30f49384093eE32d26C2C8E38e6566482C6a8'
    ] // replace these with ethereum addresses you control
  }

🚨 Note, these are the addresses for the 3Box team, update the moderator to use your own address. Add another address you own to the team members array so you can test. You can create multiple accounts in MetaMask’s My Accounts section.

To handle the logic detailed in the bullet points, we are going to be adding a reasonable amount of code in the componentDidMount method. We start by adding the necessary constants:

async componentDidMount() {
    const teamMembers = this.state.addresses.map(member => member.toLowerCase()) //prevents capitalisation errors

    const spaceName = "todo-space"
    const confidentialThreadName = "confidential-todos"
    const waitingRoomName = "waitingroom"
    let teamThread // we will set this later
    const isModerator = this.state.moderatorsAddress.toLowerCase() === this.props.accounts[0].toLowerCase()

    // Access the moderators public space
    const moderatorsSpace = await   Box.getSpace(this.state.moderatorsAddress.toUpperCase(), spaceName)
    const isTeamMember =  teamMembers.includes(this.props.accounts[0]) 

    if(!isModerator && !isTeamMember){
      this.setState({notAModOrTeam: true})
      } 
  }

In addition to setting the names of the space and two threads we will be using, we need to know if the current this.props.accounts[0] is either the moderator or a team member.

We also need to access the moderators public space, as this is where we save the thread addresses. Because we are using 3Box.js to access this, we need to import the library at the top of the file:

import Box from '3box'

2. Creating a confidential members thread

Inside componentDidMount we can add the following block of code (see example):

if (!moderatorsSpace[confidentialThreadName] && isModerator) {
      // if theconfidentialThreadname is not saved in the mods space
      // it means it theconfidentialThreadhas has not been created. 
      // create the confidentialconfidentialThreadand save the  
      // address in the moderators public space

      const confidentialThread = await this.props.space.createConfidentialThread(confidentialThreadName)
      await this.props.space.public.set(confidentialThreadName, confidentialThread.address)
      const waitingRoom = await this.props.space.joinThread(waitingRoomName)
      await this.props.space.public.set(waitingRoomName, waitingRoom.address)
      this.setState({teamThread : confidentialThread})
      console.log("confidential thread & waiting room thread made")
    }

The if statement means this will only be accessed when the confidential thread hasn’t been created and saved to the moderators public space. We are also using space.joinThread to create and join the public thread which stores the team members progress of opening the space (needed to be added to the thread). The address of this public, waitingRoom thread, is saved to the moderator’s public space, so team members can access it. We save the confidential thread to react state, so the moderator can add todo straight away.

For this to work, we need to pass space in as property to the Team component in App.js:

<Route path="/team">
    <Team 
      accounts={this.state.accounts}
      space={this.state.space} />
  </Route>

Visiting the browser, you should now see the console log "confidential thread and waiting room thread made".

We can also add some logic to handle for the case when a team member logs in ahead of the moderator (see example):

if(!moderatorsSpace[confidentialThreadName] && !isModerator && isTeamMember){
      this.setState({moderatorLoginToCreate: true})
  }

3. Recording team members opening the applications space

Now let’s handle the flow for users when the confidential thread has been created. Starting with team members the first time they visit. Here the first thing they need to do is open the same space the confidential thread lives in, and save this update to the public waitingRoom thread (see example).

// when the confidential thread has been created
if (moderatorsSpace[confidentialThreadName]) {
	
	if(isTeamMember && !isModerator){
	// check for the space opening status of the team member in 
        // the waitingRoom public thread    
	const waitingRoom = await this.props.space.joinThreadByAddress(moderatorsSpace[waitingRoomName])
	 const rawPosts = await waitingRoom.getPosts()
	
	  // where we handle the logic of adding team members to the 
	  // waiting room and confidential thread
			
    }
	// Add the moderator login here 
 }

As we need to store data in the waitingRoom thread in string form, we will be creating an object and JSON stringifying it to store in a thread. This object will record the addresses of team members which are in the waitingRoom (opened space but not added to the thread) and added (once they have been added by the moderator). For example:

{
	waitingRoom: [
             '0xa8eE0BABE72cD9A80Ae45dD74Cd3eaE7a82fd5d1',
             '0x5031f308AD02Ed86F44c586aD2B01ae55D034C7a'],
	added: ['0xB3B30f49384093eE32d26C2C8E38e6566482C6a8']
}

Later we will add the code which handles the moderator adding team members to the confidential thread and moving them in to the added array.

Now after rawPosts lets add the following code for the case when there are no posts in the waiting room thread (see example):

if(rawPosts.length < 1){
  await waitingRoom.post(JSON.stringify({
        waitingRoom: [this.props.accounts[0]], 
        added: []}))
  this.setState({moderatorWillAdd: true})
	console.log("first team member added")
}

As user has opened the space, we can add them to the waitingRoom array. We are also updating the react state so we can indicate to the user that they should revisit after their moderator has logged in.

Wen will add the next if statement to process the waitingRoom thread when it contains posts (see example).

if(rawPosts.length > 0) {
      const mostRecent = JSON.parse(rawPosts[rawPosts.length -1].message)
      // check user has been added to the confidential thread
      if(mostRecent.added.includes(this.props.accounts[0])){
        const confidentialThread = await this.props.space.joinThreadByAddress(moderatorsSpace[confidentialThreadName])
        console.log("joinedconfidentialThreadas team")
        this.setState({
             teamThread: confidentialThread, 
             teamMembersAdded: mostRecent.added
             })
             // TODO get posts
	}
		    if(mostRecent.waitingRoom.includes(this.props.accounts[0])){
          this.setState({moderatorWillAdd: true})
	 return
      } else {
        // add user to waiting room in prep for adding to thread
        console.log("adding user to waiting room")
        mostRecent.waitingRoom.push(this.props.accounts[0])
        await waitingRoom.post(JSON.stringify(mostRecent))
        this.setState({
              moderatorWillAdd: true})
	return 
      }
    }

Here we are parsing the most recent post to read from. Then checking if the current user is present in the added array (meaning they have been added by the moderator) we join the confidential thread with joinThreadByAddress.

Then we check the mostRecent post to see if the user is already in the waiting room array. In this case we do not need to do anything except update the react state.

If they are neither in the waiting room or added array, it means it’s their first visit to the application. We need to record them as having opened the space, and indicate to the moderator they should be added to the thread. To do this we record their ethereum address in the waitingRoom array.

4. Adding team members to the thread

The final part we need to add to the moderatorsSpace[confidentialThreadName] if statement, is the flow where the moderator revisits the application to add the team members in the waitingList to the todo thread (see example).

// Add the moderator login here 

if(isModerator){
        // moderator joins the confidential thread and adds users in 
        // waiting room. Then move these users to the added array
        const confidentialThread= await this.props.space.joinThreadByAddress(moderatorsSpace[confidentialThreadName])
        console.log("moderator joinedconfidentialThreads")
        const waitingRoom = await this.props.space.joinThreadByAddress(moderatorsSpace[waitingRoomName])
        const rawPosts = await waitingRoom.getPosts()
       
        if(rawPosts.length > 0) {
        const mostRecent = JSON.parse(rawPosts[rawPosts.length -1 ].message)
        mostRecent.waitingRoom.map(async address => {
            await confidentialThread.addMember(address)
        });

	// Once team members have been added to the waiting room,
	// move them to the added array
        const newWaitingRoom = {
          waitingRoom: [], 
          added: mostRecent.added.concat(mostRecent.waitingRoom)}
          const inConfidentialThread = await confidentialThread.listMembers()
          await waitingRoom.deletePost(rawPosts[rawPosts.length -1].postId)
          await waitingRoom.post(JSON.stringify(newWaitingRoom))
	  console.log("updated waiting room arr", newWaitingRoom)
        }

      this.setState({teamThread : confidentialThread})
      // TODO get posts
  }

Now that we have completed this flow, we can check in the console that it is working correctly.

• When the moderator logs in for the first time — confidential thread and waiting room thread made
• The first team member logs in — first team member added logged and moderatorWillAdd: true in react state
• Moderator rejoins after team member logs in — moderator joinedconfidentialThreads , updated waiting room array with an updated waiting room object
• Same team member rejoins — joinedconfidentialThreadas team and teamThread: confidentialThread, teamMembersAdded: mostRecent.added in react state.

5. Retrieving team posts

Now we have the logic to add members to a confidential thread, the next thing is to add the functionality to retrieve posts. Luckily we can reuse some of the logic we used in personal confidential threads . We can add the getPosts and parsePosts methods to the Team component (see example):

async getPosts() {
    const rawPosts = await this.state.teamThread.getPosts()
    const posts = this.parsePosts(rawPosts)
    this.setState({ posts })
  }

parsePosts = (postArr) => {
    return postArr.map((rawPost) => {
      let post = JSON.parse(rawPost.message)
      post.id = rawPost.postId
      return post
    })
  }

We call the getPosts function just after a team member has joined the confidential thread, we will also add a return statement here. (see example):

console.log("joinedconfidentialThreadas team")
this.setState({ teamThread: confidentialThread, teamMembersAdded: mostRecent.added })
// TODO get posts
this.getPosts()
return

And after the moderator has joined add the line:

// TODO get posts
  this.getPosts()

After this, you should see posts: [] saved to the react state for the team component. We have not added any posts yet so this is expected.

6. Adding posts

To add posts, let’s add the modal component to the render function:

<ModalComponent
    buttonText={"Add a ToDo"}
    ModalHeader={"Add a Todo"}
    ModalBodyText={"One more thing on the list."}
    submitFunc={this.onSubmit} >
    <Container>
      <Form>
        <Form.Group controlId="formBasicEmail">
          <Form.Label>New Item</Form.Label>
          <Form.Control
            type="text"
            value={this.state.newTodo}
            onChange={(e) => (this.setState({ newTodo: e.target.value }))}
          />
        </Form.Group>
      </Form>
    </Container>
  </ModalComponent>

This component works similarly to the one we used for personal todos. We also need to add the onSubmit function:

onSubmit = async () => {
    if (this.state.newTodo) {
      const orderNumber = this.state.posts.length > 0 ? (this.state.posts[this.state.posts.length - 1].order + 1) : (1)
      const post = JSON.stringify({
        text: this.state.newTodo,
        completed: false,
        show: true,
        order: orderNumber,
        postedBy: this.props.accounts[0]
      })
      await this.state.teamThread.post(post)
      this.setState({ newTodo: null })
      this.getPosts()
    }
  }

Let’s also add the UI component to render todos.

{this.state.posts &&
    <TODO
      posts={this.state.posts}
      deletePost={this.deletePost}
      toggleDone={this.toggleDone}
      accounts={this.props.accounts} />
  }

Finally let’s add the deletePost and toggleDone methods:

toggleDone = async (todo) => {
    const post = JSON.stringify({
      text: todo.text,
      completed: !todo.completed,
      show: true,
      order: todo.order,
      postedBy: todo.postedBy
    });
    await this.state.teamThread.post(post);
    await this.state.teamThread.deletePost(todo.id)
    this.getPosts()
  }
  
  deletePost = async (postId) => {
    await this.state.teamThread.deletePost(postId)
    await this.getPosts()
  }

Testing in the UI, you should now be able to add a post, delete a post you have created and select a post you have created.

7. Updating the UI

Now that the core functionality is working, we should update the UI to communicate the flow to the user. Making use of the react state we created earlier in componentDidMount, we can create an isActiveMember constant to indicate when a user is logged in and active. We will also add some brief messaging to indicate to the user their status when they are not an active member (see example).

render() {
   const isActiveMember =  !this.state.notAModOrTeam && !this.state.moderatorWillAdd && !this.state.moderatorLoginToCreate && this.state.teamThread

    return (
      <div>
        <h2>Team TODOs</h2>
        {/* {TODO Section} */}
        {this.state.notAModOrTeam && (
              <h1>You are not part of this team</h1>)}
        {this.state.moderatorLoginToCreate && (
              <h1>Ask your moderator to login to start</h1>)}
        {this.state.moderatorWillAdd && (
               <h1>Wait for your moderator to log in and add you</h1>)}
        {this.state.posts && isActiveMember && (
          <TODO
            posts={this.state.posts}
            deletePost={this.deletePost}
            toggleDone={this.toggleDone}
            accounts={this.props.accounts}
          />
        )}
        {isActiveMember && (
          <>
            <ModalComponent
              buttonText={"Add a ToDo"}
              ModalHeader={"Add a Todo"}
              ModalBodyText={"One more thing on the list."}
              submitFunc={this.onSubmit}
            >
              <Container>
                <Form>
                  <Form.Group controlId="formBasicEmail">
                    <Form.Label>New Item</Form.Label>
                    <Form.Control
                      type="text"
                      value={this.state.newTodo}
                      onChange={(e) =>
                        this.setState({ newTodo: e.target.value })
                      }
                    />
                  </Form.Group>
                </Form>
              </Container>
            </ModalComponent>
          </>
        )}
      </div>
    )
  }

8. Testing the UI

Our frontend is almost finished, now we can check that it is functioning as expected. Try the following:

• A users who is neither a moderator or a team member — the UI will render “You are not part of this team”.
• A team member logging in ahead of the moderator — the UI will render “Ask your moderator to login to start”.
• A moderator logging in for the first time — “confidential thread and waiting room thread made” will be logged in the console. It should be possible to post, check done and delete a todo.
• A team member after a moderator has created the thread:
• First login — “Wait for your moderator to log in and add you” will be rendered in the UI.
• Returning to login in after the moderator has logged in again — you should be able to post, delete and check done todos (that they have created themselves).

If your application works as above, congrats you have completed the core functionality of this tutorial.🎉

9. Adding the profile hover component

One final thing we are going to do as part of this tutorial is make use of the profile hover component to show the users profile picture and 3Box name. If you haven’t already set a profile picture and name, you can do this in 3Box Hub (editing 3Box profiles can also coded to be functional inside any application).

First use npm to install the component:

npm i profile-hover

We will import it to the top of our TODO.js component:

import ProfileHover from 'profile-hover'

Profile hover is the most minimal to add a 3Box plugin, so all we need to do is add the following inside the render function on line 36:

{item.postedBy && <ProfileHover address={item.postedBy} showName={true} />}

You will now see each users 3Box profile render in the UI.

With that we complete this two part tutorial series.

If you have any questions or feedback, head over to our discord channel. We are excited to follow what the community builds with confidential threads!

Building an encrypted todo list with 3Box (part 2/2) was originally published in 3Box Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 1 : Personal lists

Intro

Earlier this year we were excited to launch confidential threads. Private and encrypted messaging opens up the possibilities of what can be built with 3Box.

This two part series will guide you step by step through creating an individual and team todo application. The first part will get us set up with a personal to do app. The second part will extend this to include team functionality.

As with all products built with 3Box.js, there is no need for a server to manage data. This application is built client side. 3Box.js will persist the data in encrypted form on IPFS without the need for you to run your own node. To take a deep dive in to 3Box’s architecture, check out this blog.

👉 Check out the demo here

🛠 Completed tutorial codebase

Read on for part one, building a todo application with personal confidential threads.

What you will learn in this tutorial

Personal Confidential Threads

We start by learning how to use confidential threads by creating a todo list application for a single user. Here you will learn how to join, save, read and delete data from a confidential thread.

1. Getting started with the boilerplate code
2. Installing 3Box.js and opening a space for the application
3. Joining a personal confidential thread
4. Saving and getting todos from a confidential thread
5. Checking done and deleting todos

In part 2 we will be building out this application out to work for groups and teams.

Setup and Tech Stack

For the tutorial, some familiarity with react is required. You can complete by copying and pasting each step, but for a more meaningful understanding, it is recommended you are familiar with the basics.

• React — frontend framework
• IPFS + OrbitDB — where the data is stored (provided by 3Box, so we won’t need to touch this directly, no need to install separately )
• MetaMask — Web3 wallet integration (required to facilitate signing and encryption of data)
• 3Box.js — 3Box SDK that connects wallets to IPFS database storage via 3ID
• Profile Hover, and Profile Edit Plugins — drop-in React components that we will use to speed up UI development
• React Bootstrap — UI Library

1. Getting started with the boilerplate code

To get started let’s clone and install the boilerplate code :

git clone <https://github.com/RachBLondon/todo-template.git>
cd todo-template
npm i
npm start

This boilerplate code is made with create react app. It connects with MetaMask to enable the provider and obtain the users ethereum address. This happens in lines 15–30 in App.js

async getAddressFromMetaMask() {
    if (typeof window.ethereum == "undefined") {
      this.setState({ needToAWeb3Browser: true })
    } else {
      window.ethereum.autoRefreshOnNetworkChange = false; 
      //silences warning about no autofresh on network change
      const accounts = await window.ethereum.enable();
      this.setState({ accounts })
    }
  }
  async componentDidMount() {
    await this.getAddressFromMetaMask()
    if (this.state.accounts) {

    }
  }

This repo also contains some frontend boilerplate components which will be used later in the tutorial (modals, todo lists etc).

2. Installing 3Box and opening a space for the application

First we will install 3Box.js

npm i 3box

and import it to our App.js file

import Box from '3box'

Note do not import as 3Box as variables cannot start with numbers in JavaScript

Now that we have 3Box.js installed, we are going to add the following code to componentDidMount

async componentDidMount() {
    // creates an instance of 3Box 
    const box = await Box.create(window.ethereum)
    await this.getAddressFromMetaMask()

    if (this.state.accounts) {
      await box.auth(['todo-space'], {
        address : this.state.accounts[0]
      })

      // opens the space we are using for the TODO app
      const space = await box.openSpace('todo-space')
      this.setState({ space })
    }
  }

First we use Box.create to create an instance of 3Box. This takes a single argument of the ethereum provider so can be called straight away in componentDidMount. The page needs to be loaded, as we are dependant on MetaMask injecting the provider in to the frontend.

Next once the provider has been enabled using the boilerplate function, getAddressFromMetaMask and the address saved to state, we call box.auth. This authenticates the instance of 3Box we have created with an array of spaces (in this case we only have one, but it supports multiple) and the users ethereum address.

If you have worked with 3Box previously, you may have used a different authentication method, Box. openBox. This method is still supported, but there are a number of benefits to using Box.create and box.auth. Firstly you can create the 3Box instance earlier (you do not need to wait for the user to enable the ethereum provider in their wallet). Second you can authenticate with multiple spaces at once. For new projects, we recommend using the approach detailed in this tutorial.

Then we use box.openSpace to open the space which has been authenticated in the previous step. Finally setting the space to the component’s react state for use throughout the application.

When revisiting the app in a browser, you should now be prompted by MetaMask to sign access to the todo space.

We are creating a space first, as confidential threads live inside a user’s space. We will also be using this space to store public and private data later in this tutorial.

3. Joining a personal confidential thread

Now we will start working on personal todos. Here we will be working with the pages/Personal.js component. First we will pass the space we just opened in to the component as a property (this is done in App.js)

<Personal 
      accounts={this.state.accounts}
      space={this.state.space}/>

We can also wrap the Personal, Team, Profile routes in a conditional preventing them loading before the space. This will allow for easier logic in the components, as they will not render without the space.

{this.state.space && (
        <>
          <Route path="/personal">
            <Personal 
              accounts={this.state.accounts}
              space={this.state.space}/>
          </Route>
          <Route path="/team">
            <Team 
	            accounts={this.state.accounts} />
          </Route>
          <Route path="/profile">
            <Profile />
          </Route>
        </>
)}

Similarly we can wrap the navigation in the same logic.

{this.state.space && (
      <>
        <Nav.Item><Link to="/team">Team TODOs</Link></Nav.Item>
        <Nav.Item><Link to="/personal">Personal TODOs</Link></Nav.Item>
        <Nav.Item><Link to="/profile">Profile Update</Link></Nav.Item>
      </>)}

Now opening the Personal Component. Before we start coding, it’s useful to describe the flow in which we will create and join the Confidential Thread.

• Create a personal confidential thread
• Save thread address to the user’s private space
• When revisiting the user will check for the thread address in their private space
• If the thread address is saved in space, they will join using joinThreadByAddress method

In componentDidMount we will add the following code to achieve the flow described above:

async componentDidMount() {
    
    const threadName = "personal-list"
    const confidentialThreadAddress = await      this.props.space.private.get(threadName)
    let personalThread

    if (confidentialThreadAddress) {
    // the personal confidential list has been created already
    // use it's adddress to join
      personalThread = await this.props.space.joinThreadByAddress(confidentialThreadAddress)
    } 

   if (!confidentialThreadAddress) {
      // the personal confidential list does not exist
      // create it and save the address to the user's private space
      personalThread = await     this.props.space.createConfidentialThread(threadName)
      await this.props.space.private.set(threadName,  personalThread._address)
    }

    this.setState({ personalThread })
    // TODO add getPosts
  }

Once this is done, you should be able to see the personal thread saved to the component’s react state.

4. Saving and getting todos from a confidential thread

For the personal todo list we will be using a personal confidential thread. Each post within a thread comprises of a single string. We would like to store data for our todo app in the form of a JavaScript object. This can be achieved by using json stringify to turn the object in to a JSON string for storage as a thread post.

First lets look at an example todo object:

const demoToDos = [{
	  completed: false, // check true when done
	  id: "1", 
	  order: 1, // used to order the todo in the UI
	  postedBy: "0xab74207ee35fbe1fb949bdcf676899e9e72ec530", 
          // user's address
	  show: true, 
	  text: "Laundry " // todo text
	}
]

Now we are going to add the following two methods to retrieve posts:

parsePosts = (postArr) => {
    return postArr.map((rawPost) => {
      let post = JSON.parse(rawPost.message)
      post.id = rawPost.postId
      return post
    })
  }

async getPosts() {
  const rawPosts = await this.state.personalThread.getPosts()
  const posts = this.parsePosts(rawPosts)
  this.setState({ posts })
}

Here we can see we are calling the getPosts method on the personal confidential thread to retrieve the posts. We wont have any posts saved yet, so we won’t see any content. However after calling getPosts in componentDidMount after we set the personal thread to state (see example), you should see an empty array of posts saved in the component’s react state.

// TODO add getPosts
this.getPosts()

Next let’s add some boilerplate code to create a modal to add todos. Inside the render method, after the h2, add the following (see link):

<ModalComponent
  buttonText={"Add a ToDo"}
  ModalHeader={"Add a Todo"}
  ModalBodyText={"One more thing on the list."}
  submitFunc={()=>(console.log(`submit a new TODO   ${this.state.newTodo}`))} >
  <Container>
    <Form>
      <Form.Group controlId="formBasicEmail">
        <Form.Label>New Item</Form.Label>
        <Form.Control
          type="text"
          value={this.state.newTodo}
          onChange={(e) => (this.setState({ newTodo: e.target.value }))}
        />
      </Form.Group>
    </Form>
  </Container>
</ModalComponent>

The modal component is already imported in to the top of the Personal Component, so the modal should work. Check it by adding some text to the input inside the modal, clicking submit you should be able to see the text logged out in the browser console.

The modal component adds the new todo to react state (this.state.newTodo), so far however, it is not being saved to 3Box. To fix this we need to modify the submitFunc which is passed as a property to the modal component. To handle this, let’s create the following method:

onSubmit = async () => {
    // only submit to 3Box if there is a new todo
    if (this.state.newTodo) {
	// keeps a consistent order of the todo posts in the UI
      const orderNumber = this.state.posts.length > 0 ? (this.state.posts[this.state.posts.length - 1].order + 1 ): (1)

      const post = JSON.stringify({ 
          text: this.state.newTodo,    
          completed: false, 
          show: true, 
          order : orderNumber, 
          postedBy: this.props.accounts[0]})

      await this.state.personalThread.post(post)
      this.setState({ newTodo: "" })
      this.getPosts()
    }
  }

On submit we add an order number to keep a consistent order of the todo posts, stringify the object so it can be saved as a post in the thread, use thread.posts method to post to 3box, set to react state and finally call the thread.getPosts method we have just made.

Now lets replace the submitFun property in the modal component with the onSubmit method:

submitFunc={this.onSubmit}

Once has been added, you will be able to save a personal todo to the users personal confidential thread. You can check this is working by adding a new todo and checking react state that it is being saved in there. We can render the posts in the UI by adding the code below:

{this.state.posts &&
          <TODO 
              posts={this.state.posts} 
              deletePost={()=>(console.log("deletePost"))}
              toggleDone={()=>(console.log("toggleDone"))}
              accounts={this.props.accounts} />
        }

5. Checking done and deleting todos

As you can see, we still need to add the code to check done / undone (toggleDone) and delete the todos (deletePost). To do this add the following methods:

toggleDone = async(todo)=> {
    const post = JSON.stringify({ 
        text: todo.text, 
        completed: !todo.completed, 
        show: true, 
        order : todo.order, 
        postedBy: todo.postedBy 
     })
    await this.state.personalThread.post(post)
    await this.state.personalThread.deletePost(todo.id)
    this.getPosts()
  }

  deletePost = async (postId) => {
    await this.state.personalThread.deletePost(postId)
    await this.getPosts()
  }

Here we can see we are creating a new todo object with the inverse completed property of the selected one. We then use the thread.deletePost method to remove the original post. Similarly in deletePost we also make use of this method to remove the todo. In both cases we are calling the getPosts method to update the todos in the app.

Now let’s add the TODO component, so we can view in the UI.

<h2>Personal TODOs</h2>
        {this.state.posts &&
          <TODO 
              posts={this.state.posts} 
              deletePost={this.deletePost}
              toggleDone={this.toggleDone}
              accounts={this.props.accounts} />
        }

Checking it out in the browser, you should be able to add a todo, delete a todo and toggle the status of a todo.

🎉Congrats, you have built your own decentralised, user controlled todo list! Join us for part two where we will building this out further to include team todos, stay tuned!

If you have any questions or feedback, jump in to our discord channel!

Building an encrypted todo list with 3Box (part 1/2) was originally published in 3Box Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Boost your 3Box Ghost Threads messaging

Introduction

We’ve described the 3Box Ghost Threads API and its benefits in the previous blogpost Introducing 3Box Ghost Threads API. In order to provide you with better experience for using the Ghost Threads API we created a Ghost Pinbot service. This service lets you specify the one or more threads whose messages will be pinned, and in that way help you overcome the common issues in the decentralised realm of messaging such as peer discovery, the initial state sync time and others.

By serving as an equal thread participant the Ghost Pinbot server preserves previous messaging history and list of participants in the thread. Its purpose is to serve as a bootstrap peer and decrease the participants time for joining the thread and loading the most relevant thread state.

It should be noted that the thread state in the Ghost Pinbot is not persistent and will reside in the servers memory only. This is not an issue here since the whole purpose of Ghost Threads API is to provide a performant, in-memory, decentralised messaging. If persistence is crucial for the application you’re building you can find more information about persistent threads here.

Motivation

Decentralised architectures come with huge benefits opposed to the centralised ones in many cases. One of the most common cases is decentralised messaging. The benefits against the centralised solutions are the following:

• Censorship resistent
• More stable, more flexible, and safer
• No single point of failure.

There are some cons as well. The most significant one is the efficiency. Upon joining the chatroom the peer has to find other peers, exchange information about previous messages, etc. This really depends on the algorithms and data structures used for implementing the solution, but one fact is for certain — joining the chatroom can last.

That’s why we’ve provided the Ghost Pinbot. Once it’s deployed, it can listen to as many threads as you want and keep their state in sync. It can serve as a bootstrap node and provide the joining peer with the most recent state of the thread.

Deployment

The 3Box Ghost Pinbot Server provides a couple of templates to ease up the deployment on different providers. The server can be deployed in different modes as well:

• API service for communicating with the Ghost Pinbot API
• PEER service for handling Ghost Thread functionalities
• BUNDLED service which bundles both the API and PEER services.

The service itself does not imply any specific requirements. The following set of instructions describe how to deploy the Ghost Pinbot server on Heroku environment — easy and for free!

Instructions

The pre-requirements needed for this particular deployment are:

• Docker
• Heroku CLI

Deploying Ghost Pinbot on Heroku is easy. There are a couple of limitations though:

• One listening port per application
• Unique application names.

The following steps will deploy the Ghost Pinbot as a set of two services: API and PEER.

Note: please make sure that the API_APP_NAME and PEER_APP_NAME variables in the script are unique.

# Login to Heroku 
$ heroku login 
# Clone the 3box-ghostpinbot repo 
$ git clone https://github.com/3box/3box-ghostpinbot.git
$ cd 3box-ghostpinbot
# Run the command to generate the deployment script
$ ./deploy/heroku/build.sh <API_APP_NAME> <PEER_APP_NAME> 
# Run the script
$ ./deploy/heroku/build/deploy.sh

The services should be deployed now. For example, if you ran:

$ ./deploy/heroku/build.sh ghostpinbot-api ghostpinbot-peer

the deployed services should be available at:

• API: https://ghostpinbot-api.herokuapp.com
• PEER: https://ghostpinbot-peer.herokuapp.com

The PEER service registers on the API service upon bootstrap. You can query the API service in order to get the multiaddress of the peer node:

• GET PEER INFO: https://ghostpinbot-api.herokuapp.com/api/v0/peer

The multiaddress will be listed in the response. This multiaddress can be used as a bootstrap address for future participants. You can swarm connect to it from your IPFS instance or just pass it as an option ghostPinbot while creating a 3Box instance.

Box.create(provider, { ghostPinbot: multiaddress }) 

That’s it! For more information about the Ghost Pinbot and available API(s) please visit 3box-ghostpinbot repository.

Want to learn more?

We’re always available on Discord to help answer your questions. Drop by if you have questions or if you need help integrating. Join us!

Spinning up a 3Box Ghost Pinbot server 👻 was originally published in 3Box Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

3Box partner series highlights 3Box partners and their innovative use cases.

Last month Ren launched RenVM: a private, permissionless and decentralized way to transfer assets across chains. This enables inter-blockchain liquidity, locking up assets on one blockchain and minting them on another. Just a month after launch, $20M worth of crypto has been sent through the network.

To facilitate these swaps Ren built RenBridge, a decentralized application that allows individuals to mint real Bitcoin, ZCash and Bitcoin Cash on Ethereum as an ERC20, and then convert these ERC20s back. This lets holders of those currencies leverage them in Ethereum, including the exploding DeFi ecosystem.

To make this work with complete resilience and user privacy, Ren leveraged 3Box spaces to store in flight transactions.

The challenge: pending transactions

RenBridge provides a simple interface to lockup assets on one chain and mint them on another.

Transactions on Ren can take ~1 hour or more as it’s necessary to wait for deposits on other chains to be safely confirmed before minting ERC20s on Ethereum. During this period, RenBridge needs to keep track of the pending transaction.

One option would be local storage. However, this is a very fragile place to store data critical to the transaction, which may be for large sums. If a user were to clear their browser, suffer a crash, or simply change computers then the record of the transaction would be lost.

Another option would be to run a database keeping track of user addresses and transaction IDs. However, this creates a single point of failure and centralization, with reliance on Ren (or other server operators) for an otherwise decentralized process.

The relevant info could be stored in a smart contract, but this creates cost, complexity and may compromise user and transaction privacy.

The solution: “global local storage” with 3Box

Ren turned to 3Box to backup transactions so there would be a record of all past and pending transactions associated directly to a users keys.

From Ren’s documentation:

3Box syncs with Metmask to store your past transaction(s) on RenBridge. So if you shut down your computer, close your browser, etc. while waiting for Confirmations, you can find or pick up your past/pending transaction.

By using 3Box, Ren could assure that transactions were tracked for users without running their own centralized DB to keep track. Instead, each user could maintain their own log of transactions, fully in their control and fully available across their devices.

It also made it possible for them to build more quickly without the need to build a centralized backend. Eventually, Ren did add their own storage solution to keep track of pending transactions to completely ensure safe tracking and value transfer themselves, as more than $20M flowed through their protocol in the first weeks.

Next up

Ren is quickly growing into the top BTC<>ETH bridge, and helping power the current wave of DeFi activity. They will be expanding the assets they support over time. Try out RenBridge at renproject.io and follow them on twitter @RenProtocol for more coming soon.

How Ren used 3Box to enable BTC<>ETH swaps was originally published in 3Box Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re giving away more than 3,000 DAI in prizes!

We’re excited to announce that 3Box is a proud sponsor of the HackFS hackathon along with other amazing sponsors like Protocol Labs, the Ethereum Foundation, Consensys, Textile, and others. 3Box is offering three bounties worth a total of more than 3,000 DAI in prizes! Read more below.

What is HackFS?

HackFS is a month-long hackathon run by ETHGlobal and Protocol Labs dedicated to realizing the vision of Web3 by encouraging hackers to build projects that combine blockchains (such as Ethereum), linked data (IPFS), and p2p storage (such as OrbitDB). 3Box uses all three of these technologies and so is a great fit for anyone looking to hack on a new project.

Details

Sign up: hackfs.com
Dates: July 6 — Aug 6, 2020

3Box Bounties

As a sponsor of the hackathon, we get to offer prizes to developers for building with 3Box’s technology.

About 3Box: 3Box is the leading platform for decentralized identity, profiles, databases, and messaging that helps Web3 developers build amazing applications.

1. Best Overall Use of 3Box

Builders choice! Create something truly awesome using 3Box and surprise us with your creativity. For this bounty you can create a new project that uses 3Box, or integrate 3Box into an existing project.

3Box offers a JavaScript SDK that delivers everything you need to get going in a single, easy-to-use library. 3Box also offers plugins that make it easy to add various 3Box-powered functionalities, such as profile hovers, comments, or trollboxes, into to any React app.

Prize: 1,000 DAI

Learn more

2. Interoperable #Defi Chat Platform

Create a home for discussions about DeFi protocols and take the DeFi ecosystem to the next level! This bounty is to create a completely decentralized platform for discussing DeFi protocols that can be used across every DeFi interface. Contribute a massive value-add to the thriving DeFi ecosystem.

The goals of this bounty are to:

1. Create a standalone DeFi chat application (name idea: DeFi Talk!) using the 3Box Ghost Threads API
2. Integrate chatrooms into 2+ existing DeFi interfaces (i.e. Zerion, Instadapp, DeFi Market Cap, DEXs, etc) using the 3Box Chatbox plugin

3Box offers a Ghost Threads API that allows developers to create highly-scalable p2p, decentralized chatrooms that are decoupled from any single interface. 3Box also has a Chatbox Plugin which is a simple way to drop Ghost Threads chatrooms into any react app.

Prize: 1,500 DAI

Learn more

3. Ethereum Leaderboard (Yield Farming, Dapp Usage, and more!)

Gamify the DeFi and dapp ecosystem! Create a leaderboard of Ethereum users based on usage of certain apps and protocols.

3Box offers a Profiles API that allows developers to create populate their application with rich social user profiles. This API is great for creating delightful and engaging leaderboards. There are already more than 22,000 profiles created!

Prize: 1,000 DAI

Learn more

4. Create a new doctype for Ceramic Network

Contribute to early development of the Ceramic Network by expanding what’s possible! This bounty is for creating a new doctype that can run on the protocol. Doctypes are the primitives that define content requirements and state transition rules for documents published on the network. You can read the general doctype specification here.

You can create any doctype you’d like but if you need help getting started, a Verifiable Claims doctype that complies with the W3C Verifiable Claims standard would be awesome! Some examples of existing doctypes include: 3ID, Account Link, and Tile.

About Ceramic: Ceramic is a cross-platform information graph that allows DIDs to publish unstoppable content in the form of mutable documents. Each document on the network essentially forms its own doc-chain (of updates) and has it’s own verifiable state. Ceramic network uses DIDs to sign messages and author content, doctypes to define document rules, IPFS (IPLD) to store content, and blockchains (or Filecoin) to anchor updates. Each document gets a permalink in the form of ceramic://bafy.... Ceramic is currenly in early alpha testnet. We will have a fully-functional testnet live in a month or so.

Prize: 500 DAI
Questions & Support: Join Ceramic Discord
Docs: Doctype specification guidelines, Ceramic Specs, js-ceramic

Learn more

Happy hacking and good luck to all! 🚀

We’re always available for questions or support in the 3Box Discord.

Hack with 3Box at HackFS 🚀 was originally published in 3Box Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

3Box partner series highlights innovative use cases in the ecosystem

Zerion makes DeFi simple, beautiful and delightful for both developers and users. With their web and mobile apps and developer SDK, they are making money legos accessible and powerful to builders and consumers alike.

Given this focus on the user, it’s no surprise that Zerion was one of the first dapps to integrate 3Box profiles. They understand the need to build for the user, not just the technical capability: apps for humans need profiles, not hex addresses. This is true even when the focus is on financial transactions.

Major boost to usage metrics

Zerion highly respects user privacy and strives to continuously minimize the amount of user data collected. Anonymized meta-data is only used for product improvements and never sold externally.

With the little and anonymized data they collect, the Zerion team wanted to see how basic read-only profiles impacted usage of their web app. Does this simple UX improvement help business goals?

Users have far higher retention and engagement when a 3Box profile is attached.

First, they looked at retention on the platform for all users versus users with a wallet connected to 3Box. They found that the benefits started on Day 1. Users with 3Box profiles were retained at far higher rates than other users. While exact data by cohort is not available because Zerion takes steps to ensure user privacy and anonymity, this effect continues throughout the first month. Users without 3Box continued to fall off, while users with a 3Box profile remained much more sticky.

Next, Zerion looked at activity between the two user groups. Data fluctuates throughout the month, but users with 3Box consistently engage more than other users, with spiking at times to 2–2.5x the average usage.

Opportunity for more growth

Finally, the Zerion team looked at how users with and without 3Box contributed to their overall user base.

Users with 3Box profiles contributed 20%+ of all activity on Zerion despite making up a much smaller portion of all active users.

As suggested by the earlier data, users with 3Box profiles are adding disproportionate activity and value to the platform compared to those without.

What to make of this data? First, it shows correlation — not causation. We cannot infer that all of the difference in activity comes from signing up for a 3Box profile. In fact, it’s highly likely that the most active users

It does suggest that a clear path to growth is to (a) focus on the users who care about UX, and (b) give them a great experience with rich and social features. These are the users that are retained and engaged, and they have 3Box profiles.

These profiles — along with their data, chat, and other content — can be leveraged across apps. Users and data can be composable alongside money legos in DeFi.

Making DeFi more human

Zerion has known that a great UX is important to users even when their app was primarily focused on monitoring individual crypto accounts and trades. But their thinking and analysis highlights an important point for the whole ecosystem:

DeFi may be about money, but its users are people. Our money legos need to be fun, familiar and human to play with.

It’s likely that encouraging users to sign up for 3Box profiles will drive more engagement. But it’s also important to recognize the users that get the most value from your product. Zerion now knows they can target users with 3Box profiles and likely be speaking to their highest value customers.

In addition to profiles they can offer personalized content, leverage interoperable data from their 3Box spaces (e.g., Metamask watch lists), and offer features like chat or comments to engage them.

What Zerion has shown itself and others is that personalized, human UX is essential to serve the most active DeFi users. And they’ve also shown that we still have a ton of opportunity to grow that base — most of their users still don’t have 3Box, after all.

More coming soon

The Zerion team has big product plans in store for this summer that you’ll want to be sure to watch. Follow Zerion on twitter and if you aren’t already a user check out zerion.io for a best-in-class DeFi experience.

If you’re working on a dapp and want to add profiles, user storage or identity, come by 3Box.io, follow us on twitter, or drop into our community.

Case study: how 3Box boosts engagement and retention for Zerion was originally published in 3Box Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.