The Case for On-Chain Transit Systems

A social protocol is only as strong as its end user. And end users are only as active as the DApps that empower them.

One of the core—if not rudimentary—cautions that have the potential to make-or-break the success of a social protocol is the disconnect between DApp developers and their majority end users: the gate-keeping of DApp development to those technically capable of building atop these respective social primitives inherently skews the functions and features that a social protocol may offer.

As decentralized social networks replace the web2 platforms we see today, developers will (and should) make up a smaller subset of the average protocol goer—at least, until we design for no-code products that allow any user to build on protocols as easily as Wix or Squarespace enables seamless site design.

Until then, most users are stripped of the autonomy to effectively request and implement the application-layer products they truly want to see. This means that, even while DApp functionalities cater to the core needs of aggregate users—the interfaces themselves often do not speak the same UX/UI language as their target users.

Social infrastructures are cross-protocol projects that solve multi-sided flywheel problems for protocols, DApp developers, and their respective end users. These projects take two forms—firstly, intra-network “roads,” which cater to the discovery and usability of a protocol-specific ecosystem: on Farcaster, usability is intuitive but discoverability is not; on Lens, the opposite is true.

This is a need-state that impacts both developers and their users: optimizing for discovery not only helps users explore and engage with a protocol’s application-layer more efficiently—which addresses the “what’s next?” problem that many decentralized networks face. By bringing more visibility to the apps in development, we’re also less likely to see competitive clients fighting for market (or rather, network) share—meaning that the clients that do manifest on the protocol will tend to service more diverse and comprehensive user needs…like we see on Lens.

In turn, building for usability is what separates traction from churn: Eventcaster’s thumbs-up RSVP feature or the ease of tagging @perl under a Warpcast post makes the process of interfacing with a Farcaster client endlessly simple—and ultimately standardized across the aggregate ecosystem. This means that, when Farcaster’s users do stumble upon a client they care about, these DApps are significantly stickier than on a social protocol like Lens, where each application functions by its own accord.

Building for usability eliminates the user attrition that we frequently see across the web3 space— which extends from the typically steep learning curves requisite to onboarding into various DApps and social primitives. While Lens’ app page provides a holistic overview of all of the different features and functions in service on the protocol, it is hard for a user to determine whether Orb or Lenster is a better fit for their personal social media consumption patterns, or whether to trial Talent Protocol versus Eden Protocol—making the overwhelm of choice anxiety and the need for significant DApp experimentation a challenge to overcome during onboarding.

What we really need—what the end user desires—are UX/UI solutions that integrate and merge the functionality and features of multiple DApps across one interface. This in itself is not a DApp; we’re not tapping into the data-layer of social primitives to build back-end, coded applications—but in most cases, we can probably expect that these front-end interfaces would bring together APIs across multiple clients into one conclusive use-case.

--

Here’s an example of an intra-state “road” on Farcaster that solves for both sides of a key discoverability problem: a web3 native “app store” where crowdfunding is integrated into the interface.

For users, this caters, quite obviously, to latent discovery—although a web3 native app store is categorized not by feature-set, like Lens, or client-type, like Awesome Farcaster, but rather leverages an algorithm that takes into account the nascent possibilities that composable, decentralized data enables. Take end-user personas as an example: don’t show me Buttrfly and Onboard on the same screen—if I am partial to Lenster over Orb, guide me towards the specific client I am most likely to favor between the two…based on my on-chain data, and that of others like me.

For DApp builders, this solves for the rivalry paradigm—as long as DApp discovery (such as being top-of-mind on Warpcast) is explicitly (not just latently) addressed in the UX—a mandate emphasized by one such Farcaster developer.

Merging Awesome Farcaster and Launchcaster under one user-friendly interface already solves a core need for both users and developers—but when we integrate the functionalities of Fabric and PurpleDAO within the “app store” platform, we also get to capitalize on the unfounded potential to bring the autonomy of DApp development into the hands of the end user. Imagine being able to view all of the DApps in current development on Launchcaster, with the added benefit of funding them directly on the same interface—without taking that capability off protocol and to a platform like Prop House.

Or take something like Matthew’s FarChat side project: shared as an offhand Warpcast post and inadvertently gaining expressed interest from the community—along with offers to fund the project as a full-scope DApp. What would that journey look like to take that request for product and turn it into a user-funded Farcaster client? What would it look like for this journey to live within said app-store funding functionality? How can we create more Ghost Knowledge-esque RFPs—where users have the capacity to stake ETH on product proposals within an ideas marketplace—a more cohesive way to crowdsource, and crowdfund, new ecosystem development?

This convergence of protocol clients within one user-facing interface built around a specific feature-set is the difference between latent versus embedded discovery: users drawn to the app-store funding interface get to experiment with one particular use-case for PurpleDAO’s governance features and Fabric’s crowdfunding functionality—an organic touchpoint that serves to not only introduce users to these DApps themselves, but also acts as an onboarding vehicle into them—creating more opportunities to discover other proposals, client use-cases, and channels for community engagement powered by these clients.

On Lens, the architectures of an “intra-network road” would have to solve for usability, versus discovery—which requisites an entirely different set of fundamentals. Here, the landscape may look more like partnerships between various DApps which already motivate familiar user behaviors. Just as many of Farcaster’s clients promote the use of commenting under a post as simplified DApp engagement, what does it look like to take all of Lens’ various protocol clients and group them into categories where the user-journeys take similar shapes, versus based on unique functions? And, taking the example of end-user personas above, is there room to retroactively re-optimize UX on existing DApps based on data-driven preferences according to different subsets of community?

Doing so would require a much more in-depth analysis of where users spend time on Lens’ DApps— and whether or not they’re already venturing off of the social protocol clients they’re familiar with. Maybe we’d find instead that the problem is discovery, before we even begin solving for usability: perhaps users need more pathways to latently discover new DApps within the existing clients they’re already accustomed to—motivating an intra-network road that may look more similar to the convergence of different DApps among one interface, like proposed on Farcaster.

--