onflow / fcl-discovery Goto Github PK

Show active pairings via a label like 'installed' and sort to the top if paired for any WC wallet.

Currently, there is no mechanism for error monitoring. Need to add one.

Update missing docs like license, contributing, etc.

Wallets who add themselves to Discovery may also eventually be discoverable through different plugins. We currently filter out duplicates since we needed a way to handle an extension being sent from FCL and an extension having added themselves to show as uninstalled. Service and metadata fields are also starting to become bloated since install links are required for different platforms. It's time to rethink how this is structured.

Problem:
The current design of the discovery page is not very appealing to developers and often doesn't fit well design-wise into dapps. We should also take advantage of local storage to offer a more appealing user experience, especially for new users to crypto who may not understand what a wallet is.

Solution:
I mocked up a design that aims to do the following:

• Follow similar patterns to existing wallet selection UI on other dapps and chains
• Utilize some basic local storage features to surface the most recently used wallet first
• Indicate installed extensions and put them at top of the list of selections if installed
• Design generically and with a minimized color palette to fit a broader range of dapp designs
• Offer visual cues and help to the user to understand wallets and which wallets are being offered
• Provide user the information about the dapp that is trying to connect in a visual way
• Have it be flexible to fit only 2 wallets but also work well when it could expand to 5+ on both desktop and mobile
• Offer reasonable defaults for missing configurations from the dapp (ie. image, name)

Note:

• The following page on the docs site will need to be updated so that the "What is a wallet" can be accurately linked.

Figma Files - In page "Final UI"

Problem

When developing locally with emulator and using the Discovery API, you cannot test the UI you are building around authentication because you need to point directly at the dev wallet running in the emulator instead of services returned from testnet and mainnet.

Proposed Solution

Create an endpoint for emulator and return "Dev Wallet" as a service if emulator services are requested. This service's endpoint will point to the dev wallet localhost url running in the emulator.

https://fcl-discovery.onflow.org/local/authn
https://fcl-discovery.onflow.org/api/local/authn

There should also be a way to override the port if dev wallet is running on a different port than that setup by the emulator. To do this, let's add a query param to the url for port:

https://fcl-discovery.onflow.org/local/authn?port=8702
https://fcl-discovery.onflow.org/api/local/authn?port=8702

Developer message on how to configure is not showing on testnet

To support bug onflow/fcl-js#936, we need to use the new WalletUtils config passed. Also, would be good to switch to JSON post with body instead of query params.

localStorage is not available in incognito and discovery should fallback to sessionStorage in order to avoid this

Like with other Discovery features, we need to know at which version FCL will begin sending plugin services. We need to:

• Create a supported version for plugin services
• Handle new plugin services in the pipeline
• Keep backwards compatibility

Problem

We need installed extensions to show in any environment because you may have an extension not listed in Discovery services you want to use, you are developing with a wallet that has a network switcher, or you are developing a wallet locally you want to test. If you have say an extension that supports testnet and mainnet in your browser, but does not work with emulator it will still show in Discovery because you have chosen as a user to install it. This is confusing to people who may not know this or have forgotten extensions they have and see them listed when running locally but they don't work.

There are now a lot services that are listed in Discovery and more are coming. There is currently a scroll for the iFrame/rpc, but we need a more versatile and better looking solution across other methods like pop/rpc and tab/rpc for when a large number of services are listed. We need a UI update to address this.

This also needs to address the issue of layout for when a service may have multiple sub-services (e.g. WalletConnect has different pairings for each wallet).

If a route is not specified (not supported), we get the following:

Would be helpful to a user to display a page with links to the documentation.

Upgrade FCL to v1

This was recently released, and it needs to be surfaced in discovery.

Documentation required on how to add a new wallet to be included in Discovery.

Should note to:

• Make a PR into the services.json list
• Provide a correct Flow account address in the provider information (used as a unique identifier)
• Provide a live link connected to testnet to test out

Currently, you have to manually run prettier to fix code. This should run automatically.

Issue To Be Solved

Currently, anyone can inject an extension wit FCL and have it show in Discovery. We want to only show wallets that have been merged into the Discovery services list to show in Discovery.

Suggest A Solution

After getting the extensions from FCL, filter out any extensions that are listed with platform: "web/extension" unless that service object is included in the Discovery service list.

The following guides do no mention setting the authn.include in order to get dapper wallet to work with standard discovery. This leads to people creating a lot of code for things that could just work out of of the box. Please update

• https://docs.meetdapper.com/technical-guides
• https://developers.flow.com/tools/fcl-js/reference/discovery

Issue

If an app points directly to the root of Discovery they may be confused that it's not working. It's not clear that they are pointing to the wrong path.

Suggested Solution

Add route options for iFrame and put more information on the page.

Starting in FCL 1.0, extensions will now come from client config. See this PR

• Grab extensions from client config
• Support existing way of grabbing extensions for apps using an older version

Setup CI for repo

• Add Github actions
• Run tests on pull request
• Run build on pull request

Blocto no longer working with iframe on testnet

In order to track analytics of who is using FCL-Discovery, and which applications they're using it with, we should enable Google Analytics support.

We should track:

• Who is using FCL-Discover through enabling Google Analytics.
• Which applications they're using FCL-Discovery, if possible.

Right now an extension has to be installed to show in Discovery. Let's:

• Show extensions if listed in services
• Make sure not to show two (installed and uninstalled from list)
• Open install link if not installed
• Mark service card as not installed if not
• Detect platform and only show extensions for correct platform
• Handle both UI and API side

Only display (UI) and return (API) services with methods matching client supported strategies

• These are now sent from client as part of config client.config.supportedStrategies

Images are fine for the UI version of the Discovery, but when returned on the API relative links won't work.

Discovery service pipes have some updates that we should test with older versions of FCL

In order to support the following view:

We need to collect wallet information from available Flow wallets native to iOS and Android. They should provide the same information as they do on WC such as universal, deep links, etc. and we can serve this via the API.

The API should filter based on user-agent such that a native dapp can show just Flow WC wallets and nothing else OR if they don't have WC configured, the safari browser can be used instead.

The app changes based on FCL version and configuration. Need to figure out a more thorough test plan around changing configuration and version.

• Track how many API requests are being made
• Differentiate between UI vs API requests
• Differentiate between networks

When the list of wallets is long, there is not enough space at the bottom. Last wallet is nearly cut off.

Discovery is checking for version in config, except that's only available on the next release.

Solution:

• Implement old version check from fclVersion if it doesn't exist on config.client
• Change header check to use appVersion

Pairings are known client side and need to be sent to Discovery and displayed as a selectable service

Problem

Version check with semver isn't working on alpha

Upgrade to:

Next 12
React 18

Setup sandboxnet as a network option so that wallets can add themselves to services list if they support it

https://developers.flow.com/learn/concepts/networks

Currently, routes look like this:

Discovery Routes

Discovery API Endpoints

TODO

Add mainnet an explicit mainnet path for both API and UI to support if it is specified.

• http://localhost:3002/mainnet/authn
• http://localhost:3002/api/mainnet/authn

Issue To Be Solved

Not all wallets support all functionality an app needs. For a better user experience, apps need the ability to only list wallets as options if they have the said support. This way a user doesn't wind up using a wallet with limited functionality only to find out later they can't complete actions in the application.

Suggest A Solution

Add a property to services called optIn. This means that when a wallet with limited functionality registers their service they should mark it as an opt-in wallet. We will not return opt-in wallets by default, but if an app wants to show a specific wallet they can explicitly say so in their FCL config by specifying the service account address:

import { config } from "@onflow/fcl"

config({
  "accessNode.api": "https://access-testnet.onflow.org",
  "discovery.authn.endpoint": "https://fcl-discovery.onflow.org/api/testnet/authn",
  "discovery.authn.optIn": ["0x123"]
})

FCL then turns that filter into a query param for the API which we can then filter on. We need to create the filtering functionality from those query params.

If a plugin service has added itself to Discovery, show the service rather than the plugin method. This would work similar to extensions in that any extension will work with Discovery, but if an extension has added itself to the service list then we can show the uninstalled extension as an option as well.