Experiments, Dub, and North Star
We’re hyped.
In only the five weeks since we launched experiments.gg, we’ve shipped twenty updates, each containing a handful of new dub features, product & user research, or concept exploration. On top of this, we’ve launched four new versions of Dub, each a huge jump in usability and viability from the previous.
Many of our “Weekly Experiments Email” subscribers have been asking about the goals for the site and if/how they align with Dub and dubdubdub labs as a whole. For us, experiments.gg started as a way to hold ourselves accountable week to week - building & scaling a browser is a monumental task and a build-in-(semi)public mindset keeps us focused on tangibility and the end-user. It enables us to refocus around our new company mantra:
“Argue with code, answer with users”
But, more importantly, experiments keeps us on a path to iterating on Dub quickly in discrete “week-to-week” sprints. We aim for a distribution of ~three Dub-focused and ~one explorative “experiments” per week - each building on each other to work towards Minimum Viable Dub.
Minimum Viable Dub
Minimum Viable Dub (our MVP) is the first version of Dub browser - built by ourselves, for ourselves. On February 1st, our entire team is switching over to using Dub as our default web browser & wallet - until then, we’re sprinting to build in the minimum functionality to allow us to:
- Use the internet (Minimum Viable Browser - MVB)
- Use blockchains (Minimum Viable Wallet - MVW)
Over the next ~three weeks/sprints (nine major dub features/updates), we have staged ourselves to tick off the remaining requirements for an MVB and MVW, each building on the previous. Some features coming soon include enhanced web search, uploads/downloads, ethereum sign, and gestures.
Post Minimum Viable Dub, we’ll be spending a few weeks squashing major bugs, refactoring code, and preparing for a first private alpha release. From there, we’ll launch segmented versions of the alpha to a series of user groups of approx ~10 users - building, learning, and working closely with them to narrow down features & polish. Basically, building with users to narrow in on our killer functionalities.
North Star
💡 Blockchains don’t feel native to the internet.
Even though the primary touchpoint for blockchain apps is through the web, blockchains don’t feel native to the internet - as a result, the existing end user is stuck trawling through levels of the web3 stack to use and maintain blockchain access, creating security vulnerabilities (opportunities for social engineering), community fragmentation, and usability issues.
New users are forced through 45 min+ training before reaching base familiarity with the lexicon and the task of onboarding falls to the developer (who ends up providing wallet support before app).
In the same way that the terminal was a highly technical, multi-layered touchpoint for the early Internet, we see the wallet (and the surrounding stack) as its analogue to today. Wallets (like terminals) are a bandaid solution - attempting to jam blockchain into a stack that wasn’t built for it.
Just as the Web Browser superset the early web stack, we asked ourselves - what supersets the web3 stack?
Our answer: A blockchain browser that connects users and dApps.
How We Get There
To make blockchains feel native to the internet, the user interaction AND apps themselves have to be seamless. While we’re starting with the first, we soon have to tackle the second.
Similar to wallets, wallet connectors have taken on the role of band-aiding web3 functionality into web2 websites, opening up a mountain of poor error messages, high processing time, and a mix of confusing libraries. As dApp developers ourselves, we know how difficult it is to create and and maintain a connection to the blockchain, all while figuring out new methods of deployment and onboarding.
Just as web browsers today use hooks to make possible external APIs, video calling, and web gaming, we’re building the blockchain hook to make web3 on the internet more seamless.