user story

[hxrts]

• who is the target user
• product requirements for that user
• why is this useful?

[hxrts]

I want to run a relayer to transport IBC packets from chain A to chain B. Both chains support Interchain Accounts.

The Interchain Accounts module allows the creation of remote accounts on behalf of an individual user account OR the community pool as a whole.

I want to run a relayer that only transports packets originating from the community pool as a public service, where I will be paying transactions fees on the community pool's behalf.

There is one main connection between chain A and chain B, by convention individuals who want to use Interchain Accounts do so via channel X, whereas the community pool uses channel Y.

I don't know what channels exist, however to setup my relayer to only transport packets from the community pool I must know to use channel Y.

I need a list of all open channels between chain A and B for a given connection.

With this information I can manually query these connections for a recent Interchain Account packet and inspect whether it originated from the community pool, validating this is the correct connection to automatically relay.

[charleenfei]

Product Goal MVP: Public UI for IBC activity which will start with IBC channel discovery but be able to expand to cover further IBC features as they develop

Internal Users:

• ibc-go
• IG
• marketing & PR
• people working on golang relayer

IG/marketing wants to see/create visibility about activity on IBC and relayers, this should inform grants decisions and/or marketing&PR efforts

IBC-Go team is interested in seeing activity because this data can be used to support building of community consensus on which channels we use to transfer between chains. Should also segway with IG and marketing team efforts on this point.

Golang relayer usage is more transparent, we can use this for issue triage/deciding the maintenance timeline for the repo.

External Users:

• external persons who are interested in status/activity of IBC
• external devs who want to make transfers over specific channels
• teams working on relayers

External persons are curious about status of IBC now that it's been launched

External devs want to see the active channels, and which transfers are using which channels.

Relayer teams can see current activity/usage of relayers, hopefully will help guide feature roadmap

Caveats + Next Steps

We want to be careful not to duplicate https://mapofzones.com/?period=24 because that already exists.
But we can potentially display much more information granular about the actual IBC queries (message types) over the channels.

We should also focus on relayer visibility bc that's not covered in map of zones, I think this would be the best value added direction for this UI. This would be relayer discovery, seeing the packets that are in the queue, etc

[colin-axner]

Due to the bottom up structure of IBC, channels cannot be considered fungible. This causes fracturing at the application level if two channels which perform the same function for the same connection are used. Tokens transferred from one chain to another using the same connection but different channels are non-fungible. If users/exchanges/wallets proceed to use channels in isolation from each other, we will end up in a world of many fractured IBC tokens that all come from the same place, but cannot be ascribed equal value.

It is very important we begin to coalesce around certain channels in order to prevent liveness and fracturing issues and increase UX of IBC. If there is a canonical channel to transfer atoms to ethermint, then the community as a whole can ensure the associated clients are always kept active and atoms transferred to ethermint via this channel will be fungible and easily tradeable on a dex.

Providing visibility into the most used channels will allow new users to select these channels as well causing a positive feedback loop. This fracturing will apply to all IBC applications

[seantking]

Providing visibility into the most used channels will allow new users to select these channels as well causing a positive feedback loop. This fracturing will apply to all IBC applications

Am I correct in assuming that once there is some "canonical" channels well defined in the future this notion of end users manually choosing their own channels will be abstracted away by the various popular clients?

Also, there is only talk of channels here but ports are equally as important, right? The port informs what type of IBC application is being used. @colin-axner

Some user stories summarized from the comments above:

1. As a DEVELOPER/ADMIN who is setting up and maintaining a RELAYER I would like VISIBILITY over the most used channels for each chain to better inform RELAYER CONFIGURATION
2. As a MARKETING/GRANTS TEAM engaged with different external teams I would like VISIBILITY over what ports (applications essentially) and channels are being used AS TO INFORM grant decisions and PR efforts
3. As a DEVELOPER using the RELAYER for LOCAL DEVELOPMENT I want VISIBILITY over what ports and channels are being used to increase DEVELOPER PRODUCTIVITY

• @colin-axner can you think of any nice features that would be nice to have for local development (when using a relayer locally)? I'm kind of grasping at straws with this story, but I could see it being useful for local development in some way.

4. As a member of the IBC TEAM I want to track the ACTIVITY of different channels to CREATE COMMUNITY CONSENSUS for which channels are defined as CANONICAL

[ethanfrey]

I don't know what channels exist, however to setup my relayer to only transport packets from the community pool I must know to use channel Y.

I need a list of all open channels between chain A and B for a given connection.

This is mostly implemented in ts-relayer. We currently have an issue for this and plan to tackle it soon.

Happy if you comment on the issue and add any other requirements

[ethanfrey]

Also, there is only talk of channels here but ports are equally as important, right? The port informs what type of IBC application is being used. @colin-axner

There is unfortunately no way to list all bound ports on a chain. We had this in our spec, but could not find a query endpoint. We asked the IBC team and there confirmed there is no way to query that information. Maybe in sdk 0.44?

[ethanfrey]

You can also take a look at our IBC Visualizer which provides a graphical interface to list clients, connections and channels (and some packet info) It was designed as an "admin interface" to show stats and not user facing. Happy if anyone wants to make use of this or extend it.

[ethanfrey]

Maybe you can contribute to one of these other (Apache, ICF-funded) projects rather than start another? We'd be happy to collaborate

[hxrts]

@ethanfrey thanks for commenting and we may make use of your library. This project is going to be focused on creating a micro-site that surfaces basic channel info for the Hub. It's also a learning project we're doing as a team to get some hands-on experience working with IBC data, while training our new jr dev @JessicaDosseh in blockchain front-end design patterns.

[charleenfei]

@ethanfrey super cool to see the IBC visualiser! I will take a look at it more in depth but, it looks like we can definitely make use of parts of that codebase. Like @hxrts said, we would ideally want to make something a bit more user facing but the data that IBC visualiser is retrieving looks very helpful.

I'll also put more thought into the relayer story, what we want to display and comment on the issue. Would be great to get more synergy/unification across all the relayers in general and this could be a good way to start doing that :)

[colin-axner]

There is unfortunately no way to list all bound ports on a chain. We had this in our spec, but could not find a query endpoint. We asked the IBC team and there confirmed there is no way to query that information. Maybe in sdk 0.44?

Yes this was an oversight in our sprint for IBC 1.0.0. I've opened an issue for this, so hopefully we can get this fixed soon

[colin-axner]

Am I correct in assuming that once there is some "canonical" channels well defined in the future this notion of end users manually choosing their own channels will be abstracted away by the various popular clients?

Yes this sounds likely.

Also, there is only talk of channels here but ports are equally as important, right? The port informs what type of IBC application is being used. @colin-axner

Correct, but you can also think of channels as a channel/port ID pair

@colin-axner can you think of any nice features that would be nice to have for local development (when using a relayer locally)? I'm kind of grasping at straws with this story, but I could see it being useful for local development in some way.

For local development I don't see any usage. An explorer is useful for exploring what others are doing, not for understanding what you are doing.

It might be nice for testnets

[Jelena647]

Informal went through a design sprint for Hermes and we focused on the persona of a "Relayer Operator". This is a broader category that would encompass operators running the relayer in perpetuity (maintainers) and would also consider the needs of Cosmos stakeholders such as wallets and chain developers that need a relayer to transmit IBC txs. Perhaps it might make sense to divide "Relayer Operator" in to external and internal users.

Internal: Golang relayer, Hermes, TypeScript relayer, etc
External: wallets, chain developers, etc

Some outcomes from that design sprint which are relevant to an IBC channel explorer from the perspective of external and internal Relayer Operators:

• As a relayer operator, I need the relayer to execute in a mode which will ensure that a configured client (or potentially multiple clients) are kept up to date to ensure that consensus states don’t expire. Once this feature is implemented (see issue here), would the visualizer give overview of latest client states? Could it show users the date at which clients were updated?
• Speaking of dates and clients, could the visualizer show when a connection was established between the 2 clients on the respective chains? This would happen once so would be something like a "birth date" for the connection.
• Differentiating between solo machine implementation and the chain itself. There will be situations where the solo machine is a proxy for some other chain being supported. There will perhaps be a proliferation of these solo machines such that distinguishing between the solo machine and the "main" chain might be a challenge. In general, could this visualizer differentiate between clients (Tendermint, Solo Machine, GRANDPA, etc..) somehow?
• Way to view transaction fees incurred to the relayer(s) for processing txs

This is a great overview of end user needs and focusing on channels in the short-term makes a ton of sense. I wanted to add a few comments on relayer operators though I imagine this will be out of scope in the short-term.

[JessicaDosseh]

This is just a summary of what you all have said to see if I understand correctly and some notes for myself.

---

Index

---

(work in progress)

• User Question
• User Story
• User Story Breakdown
• Word Frame
• Questions

User Question

---

Is there any way to view channels that exist via a website?

User Story

---

The goal is to build a data visualization tool by creating a user-friendly and reliable application 
where people can view, search, sort, and filter through channels to help them discover relayers, 
get informed on IBC activity, and make various decisions. 

As a user, I want to use a data visualization tool to do various tasks depending on my needs.

User Story Breakdown

---

User Persona

Internal Users:

Note: think of channels as a channel/port ID pair querying ports not currently available: view spec, and issue

As a MARKETING/GRANTS TEAM engaged with different external teams I would like VISIBILITY over what ports (applications essentially) and channels are being used AS TO INFORM grant decisions and PR efforts

• How are grant decisions being made, and what information do they need to make those decisions?

• What type of PR efforts are being put in place using the information collected from channels?

• Interchain GmbH

full description coming soon

• Marketing & PR

full description coming soon

As a DEVELOPER using the RELAYER for LOCAL DEVELOPMENT I want VISIBILITY over what ports and channels are being used to increase DEVELOPER PRODUCTIVITY

• If an explorer is useful for exploring what others are doing, not for understanding what you are doing, then on the internal side, is the goal to mainly collect information on user activity to help with improving relayer development?

• If this is the case, what type of information do we need to collect as we observe user interaction with the application?

• Would this information be the same or similar to what the grants and PR team need?

• What are the differences between the relayers and do these differences affect what we are trying to do?

• IBC-go

full description coming soon

• People working on relayers (Relayer Operators?):

[Golang relayer] full description coming soon

[TypeScript relayer] full description coming soon

[Rust relayer, Hermes] full description coming soon

External Users:

As a member of the IBC TEAM I want to track the ACTIVITY of different channels to CREATE COMMUNITY CONSENSUS for which channels are defined as CANONICAL

• If I understand correctly, the goal of this person is to use the main functionality (view, search, sort, filter) of the application to let other members of the community know which channels they should converge to.

• This will then allow the community as a whole to prevent liveness and fracturing issues?

• External persons who are interested in status/activity of IBC

full description coming soon

As a DEVELOPER/ADMIN who is setting up and maintaining a RELAYER I would like VISIBILITY over the most used channels for each chain to better inform RELAYER CONFIGURATION

• This group of people are mainly focused on viewing the information. Quick and easy access to what they are looking for so that they can go on their merry way.

• What does relayer visibility mean?

• What type of information determines if a channel is more used over another? Is it purely based on the number of transactions made through the channel?

• Why would some channels be used and others not used?

• Does the information on why certain channels are not being used need to be given to the internal users of the application?

• Do wallets, chain developers fall within this category or elsewhere?

• For most users, I think they simply want to know 'what channels are available between chain-a and chain-b?'.

• Teams working on relayers

full description coming soon

• External devs who want to make transfers over specific channels

full description coming soon

Word Frame

---

Product requirements:

• Main tasks: display, search, sort, filter
• Output: the collection of some sort of data

Feedback loop that gets created:

• External users interact with the application
• Application collects information
• Internal users use the information that the application collects to better inform external users.

Initial feature order:

• External users first
• General functionality for people who want to view information and move on (quick decisions)
• More in-depth analytics and relational information

• Internal users after
• TBD

![ add simple flow chart coming soon]

Todos

display information 
   granular information 
      (i.e., message types) 
      latest client states 
      date at which clients were updated
      when a connection was established (birth date)
      differentiate between solo machine vs. chains
      differentiate between clients
      view transaction fees incurred to the relayer(s)
   focus on relayer visibility
      begin to coalesce around certain channels in order to prevent liveness and fracturing issues
      ---------------------------------------
      visibility into the most used channels
      visibility into the least used channels (Why are certain channels not being used)


View IBC activity 
   View activity overtime period 
   Collect usage data 


View IBC channels 
   inform users of channel-related transfers 
   filter channels by 
      most active 
      least active 

Sort channels 

synergy/unification across all the relayers

Questions

---

What is the general timeline for this project?

How complex do we want this website to be?

How interactive should it be?

Resources

---

• Cosmos SDK - Legacy REST and gRPC Gateway docs

• Design system following the Cosmos - Design patterns (more or less widget like)

• Other visualization tools / issues

  • Map of Zones
  • IBC Visualizer + opened issue
  • Periodic Client Updates issue

[gamarin2]

Hey 👋 @Jelena647 asked me to relay a list of UX issues around IBC we're trying to solve in the upcoming Gravity DEX UI (which will include support for IBC transfers).

• Non fungibility of IBC tokens that have different paths (transited through different chains or different channels). This has a lot of impact (e.g. for pooling liquidity) and is very challenging to communicate to the user (you cannot invest in the ATOM/LUNA(channel1) pool if you've sent your LUNA to the Hub via channel2)
• Predictable relaying: We don't want users to rely on third party relayers that may or may not be live, especially because there is no relayer incentivisation atm.
• Fee tokens. If you try to redeem a n-hop tokens, you need fee tokens on all the intermediate chains. Likewise, if you want to do a simple IBC transfer, you're going to need fee tokens on both chains if you're going to relay your own txs. And even if someone relays your tx for you, your token still ends up on a chain where you don't necessarily have fee tokens to do anything else. We don't want users to be stuck.
• Smart routing: We want to incentivise users to redeem their tokens, and pick channels intelligently, because otherwise IBC paths will keep growing in size, and with that UX challenges too (UI becomes increasingly harder to design as the number of hops grows). Not to mention the diamond problem.