The impact of gateways on decentralized frontend experiences

[mpeterdev]

I want share my opinions on this problem space since it has come up in a few different workstreams this week.

We talked a little bit in our wallet meeting yesterday about the role of gateways. Ideally we should be building them to be the thinnest possible wrapper, such that a given dapp renders the same on every gateway. By default, gateways serve as decentralized entry points to identical experiences.

There will likely be 3rd party gateways that pop up which stray from this, and that may even be encouraged, but that should be a secondary use case and done with clear intention since it leads to fragmentation.

With regards to how this affects our implementation: we should avoid hoisting configurations outside of component land except where necessary to power functionality.

Theming

A great example is theming of reusable components. A reusable button, for example, should take its UI configuration from its ancestor components, not directly from a gateway. This puts the power, and burden, of maintaining a consistent and high quality user experience in the hands of component developer instead of the gateway maintainer. That being said, a root dapp developer may choose to take in configuration values from a gateway and pass it down through their tree.

Let's consider dark mode. If a toggle exists at the gateway level to switch between dark mode and light mode, then the gateway can provide the root component a value along the lines of mode: 'dark' or isDark: true. It then falls to the root component to choose whether to do anything with that value. If the developer has spent time building a UI which has a usable dark mode, they can act on that value and pass whatever information necessary down through the tree to have all descendant components render in dark mode. Depending on how the descendant components are built, this could come in the form of simply propagating the mode value or it could be in manually supplying styles to descendants for their dark mode UI.

It is important to say that this doesn't mean we can't create mechanisms for making it easier to support different configurations, just that the choice to tie into those mechanisms should rest in the hands of component authors.

Functionality

This will be harder, but we want to avoid differences in functionality as much as possible. Users should be free to access decentralized frontends through a gateway of their choosing, especially since gateway choice requires a significant level of trust. We briefly looked at a potential solution where gateway-level functionality such as additional wallet integrations could be built via a lazy-loaded plugin architecture. This is an extremely nascent proposal, but I think it is trending in the right direction.

For theming, we put the power in the hands of component authors. Do we consider power of functionality to be in users' hands? This feels like it has lot of parallels w/ browser extensions, so maybe this becomes something along the lines of BOS extensions which users choose to enable.

[ewiner]

Great writeup. Where my mind goes here is that a component author should declare which gateway features it relies on or could optionally use. With that information, a gateway – even one that doesn't support the necessary features – could refuse to render a component or render it with a warning about missing functionality, or provide each component with only the features it needs, for efficiency's sake.

There's two ways I'm familiar with that JS authors use for such declarations:

1. String directive (e.g. "use strict"), detected by an interpreter or preprocessor.
2. Imports, like import { featureSupported, darkModeEnabled } from @bwe/features/darkMode.

I think imports are the better path for us here. Since we're already hijacking the import system (is that right?) maybe it would be like:

• If the gateway supports dark mode, @bwe/features/darkMode is a real module provided by the gateway that exports featureSupported = true and darkModeEnabled: boolean.
• If you import something in @bwe/features/* that isn't supported by the gateway, it's faked out with a module that exports featureSupported = false and exports anything else being imported as undefined.

Do we consider power of functionality to be in users' hands? This feels like it has lot of parallels w/ browser extensions, so maybe this becomes something along the lines of BOS extensions which users choose to enable.

I don't think we need to consider separate ideas of user-configurability and gateway standards. If components already have to be aware of gateways with differing pieces of functionality, then gateways could also choose to offer their users the ability to customize the gateway feature set or themes.

[heycorwin]

Ideally we should be building them to be the thinnest possible wrapper, such that a given dapp renders the same on every gateway

In this vein, are their collaborative conversations being had around what this "minimum standard" might include or how it might be scoped? If component developers can easily know what the sum of options is with which a gateway can be configured, then I'd imagine that would make it easier to design components that are more widely compatible / gateway agnostic.

[charleslavon]

+1 for Eric's suggestion of establishing a pattern to allow component developers to encode requirements their component expects from a gateway.

This also brings to mind the conversations we (product/design/eng) were having late last year on the expectation that a component developer's dapp should reach a value-add/branding point where they will need to graduate to become gateway operators themselves.

IIRC, the hypothesis is that the benefits of decentralized front-ends are their discoverability and composability which are most useful to accelerate initial dapp development by remixing existing UIs created by the community and quickly distributing a dapp to user communities on known gateways. Then, for the category of developers who are on the founder path, those who intend to grow their app community and build a business, they will want a white-labeled gateway experience to be able to fully own the branding and overall UX.

I think we can lean into this 'eventual gateway operator' hypothesis, and put more effort into patterns around declaring component requirements versus advocating for thin gateways, because this hypothesis is aligned with our refined target users (focused on the founder-developer).