Takeaways - Dogfood Your Web3 Ecosystem

Takeaways - Dogfood Your Web3 Ecosystem — 9 minute read

During and after the activities day, we collected a lot of feedback. While one intended outcome was to get everyone some hands-on experience within the ecosystem that they were helping to build or support; another very important intended outcome was for us to learn about what works, what does not work, and what could be improved.

What I’ve started realising is that if we define the everyday user as non-advanced crypto user, we limit it to like 99.9 percent of society 😄

The key takeaway from the dogfooding experience was that the technology needs to be adapted to serve everybody, not just the tech savvy power users.

The body of this post details the various ways in which this central theme surfaced, from DApps, gamification, networks, infrastructure, and skills.

The most common complaint during the day - virtually every single participant had an issue with this - was Internet connectivity issues. This was of course nothing to do with the activities or the ecosystem… but nonetheless was a huge challenge for almost all participants. This was because we were all connected to the hotel’s WiFi, and it simply couldn’t handle the bandwidth needed.

We mitigated this by getting those with local SIMs to start their own WiFi hotspots, and then have the other group members tether to it. We had partial success with this, because there weren’t enough to go around for everyone.

There were also security concerns from connecting to an untrusted network - better to use a network which you control!

The learning point from this, is that relying on the default network at the venue isn’t the best plan. In the next iteration we will have a better connection, capable of handling the anticipated bandwidth required for the planned activities.

Nonetheless, this did prove to be a valuable experience for us, because not all users in our ecosystem have reliable Internet access. We were able to observe which parts were more resilient (and less resilient) under these circumstances.

When planning how to split the teams, we needed to make guesses about who knew their way around the tools and the ecosystem already, and who would need to pick up some skills on the spot. Turns out that only around one in five in the organisation already had the required skill levels. We expected a larger proportion, since by definition, every participant works in the blockchain industry. If we extrapolate this to a global user base, the proportion is going to be even lower. This shows that a move towards serving everyday users is a logical step to mass adoption, as most users will not be crypto native.

Some specific skill gaps that we identified included:

  • Unable to check transaction status using block explorer
  • Not planning ahead - need to retain a small amount of RBTC to pay for gas fees in anticipated transactions
  • Configuring a custom network in a wallet was challenging

On the flip side, there were a few who were really advanced, and were able to identify and perform the easter egg tasks with uncanny ability. Something else that we predicted, and were happy about, was that one or two people from each group, with the higher skill levels, completed their tasks quite easily, and then proceeded to help the rest of the group complete their tasks.

The gamification elements of the activities day also brought out some interesting outcomes.

There was a leader board projected onto the main screen, and this helped to foster a competitive environment. Of course, this led to some heckling about the methodology and fairness etc, but what’s a competition without some of that, eh?

The competitive atmosphere also made it more compelling. Most of the other sessions consisted of presentations, and people would leave immediately when the break started, and dawdle in slowly after the break was over. In this session, however, most seemed glued to their seats, leaving later after the break started, and returning earlier as well. We felt that this was genuine enthusiasm taking hold!

There were several instances of rage-quits observed during the day as well. Some gave up because of the Internet issues. Some gave up because a DApp didn’t behave “as it was supposed to”. Some gave up because they made genuine errors. The experts (the ones who were running and evaluating the groups) were sometimes able to cajole those who gave up to get back into the game. In other cases, the frustration levels were so high that they refused. The good thing is that the latter group was less than a handful of people - most were successful!

My personal reflection of the above is that even though today’s web3 ecosystem is too technical, or otherwise hard to use, some perseverance, paired with help from someone who’s experienced, is able to get them over the line. This was possible (and encouraged) in the way that this activities day was structured. However, this is likely out of reach for the average user.

One learning point from this reflection is that products need to be built with usability in mind. The vast majority of DApps out there simply are not. Simply doing this could almost be a USP (unique selling proposition) in this space, by removing a significant barrier to entry.

Another thing to note is that when dogfooding, the participants are never wrong or stupid. The participants are not to blame; the system that they are attempting to use is really what should be blamed. What about the underlying infrastructure, or the specific DApps that they were using, was causing them to get confused, to make mistakes, or to get frustrated? There is quite a lot that we learnt about where the system failed to meet the expectations of the users, and those are detailed in the “infrastructure-related” and “DApp-related” sections below.

The core technology of the RSK blockchain network had solid, dependable performance. However, there were failures - in the eyes of the users - in the technical infrastructure surrounding/ supporting the usage of the network. There were also failures occurring in the applications/ services within the ecosystem, which also felt like - in the eyes of the users - infrastructure failures.

The most commonly encountered issue- by a huge margin - was the rate limits imposed by the RSK public nodes. Since most of us were on the same network, the public node would have rate limited the entire group as if it were one user; based on the traffic originating from a single IP address. Rate limiting is a valid technique used by devops/ security to protect infrastructure against denial-of-service attack vectors. So this is a hard balancing act. Some proposed ideas around this that require investigation were: Another means of detecting unique users for the purposes of rate limiting? A decentralised form of public RPC nodes?

There were several other very valuable comments too:

  • Provide an easier way to configure web wallets to add the RSK network.
  • In the block explorer, a brand new account shows as “Not Found”; so provide steps to validate or verify that the account is operable
  • Transactions on the blockchain are slow, a lot of time was spent waiting while thinking that something had maybe failed; the biggest frustration here was that DApps were much slower than using web2 apps

The DApp related complaints were:

  • The liquidity available on RSK Swap for the RBTC/RIF pair was too low to be viable
  • The DApp for Sovryn would glitch with the drop down menu when selecting tokens; some swapped RBTC to SOV instead of RBTC to RIF in one of the exercises
  • Too little priority given to user experience in DApps

Better handling of errors within DApps was the most commonly complained about UX issue. If an RPC request failed, in many cases, a DApp would just stall, neither displaying an error nor moving onto the next stage. In other cases, the DApp would show a cryptic error message, such as Invalid RPC Response "" (which is gibberish, and confusing to the average user). The main takeaways here are that DApps need to handle errors more robustly; when errors occur, surface the technical reason in an understandable + helpful manner to the end user, such as RPC server has rate limited you. Consider switching to another RPC server [LINK].

Participants also had miscellaneous other suggestions related to the DApps:

  • Publish troubleshooting guides for usage of DApps within the ecosystem
    • e.g. How to manually reset account TX nonce in wallet
    • e.g. How to clear cache of a web wallet
  • Integrate RNS into more wallets, in order to avoid the need to copy 0x... addresses
  • rLogin be integrated into more DApps within the ecosystem
  • Provide an easy way to split a transfer into a group of accounts

Wrap up

One small step for usability, one giant leap for adoption.

We believe that the experiences we had during this activities day are largely mirrored across the broader web3 ecosystem. The clear call to action is that in order to move the industry to mass adoption, focus is required on improving the user experience. Mass adoption will not be driven by the crypto native and tech savvy individuals. Instead, mass adoption will be driven by its usage in everyday use cases such as purchases, remittances, lending, and borrowing. Therefore, the goal is to take these lessons learned, and apply them. This will be a journey of taking web3 from being accessible to the few, to being accessible by the many.

Fin

A big thanks to everyone who participated. Of course, major props to those who helped with the planning the activities and running the event on the day: Mike Mendes, Bernardo Codesido, Filipe Moura, Maxi del Hoyo, Diego Masini, and Lionel Modi. Thanks to the partners in the RSK ecosystem whose DApps were part of the activities: Money on Chain, Tropykus, Kripton Market, and Sovryn. Thanks to Daniel Fogg and Pei Chen, for seeding the idea around dogfooding. Thanks to Caylie Panuccio and Mike Mendes for reviewing these posts.

This post is (non-chronologically) the final one in a series of posts. Be sure to check out the others!

  • Dogfood Your Web3 Ecosystem - The thinking behind it, and preparation for it
  • Try it yourself! - A list of all activities, (almost) no spoilers
  • Coming soon Demos - How the activities were completed and evaluated, spoilers aplenty
  • This post Takeaways - What we learnt from the entire process