Epic: Explorer/Scraper for permissionless deployment

[nambrot]

Currently the explorer/scraper only supports the chains by the operator of the explorer/scraper. With permissionless interopability, it is unclear whether it is reasonable to expect the operator to be able to do that. There should be a story for how a deployer of PI is able to get messages to/from show up in an explorer

Explorer improvements

Preview Give feedback

1. Only indicate origin IGP not paid if we're expecting a payment on our IGP #3668
   dx explorer +2
   
2. Pull Explorer's metadata & artifacts from registry instead of SDK #3655
   UX dx explorer sdk +4
   
3. Explorer should show a list of messages outbound from PI chains hyperlane-explorer#163
   0 of 1
   explorer permissionless +2
   
4. Payments for the non abacus works IGP should be highlighted on the explorer #1920
   dx explorer +2
   
5. Implement origin/dest/time filters for PI msg search hyperlane-explorer#164
   explorer permissionless +2
   
6. Timeline widget support for PI messages #2239
   explorer permissionless +2
   
7. Explorer should allow users to self-relay messages #2213
   1 of 1
   dx explorer permissionless +3
   
8. More clearly display unknown chains in hyperlane explorer #2102
   explorer permissionless +2
   

[nambrot]

Maybe the move is to just have the scraper/explorer operator accept PRs effectively, with some ability for a explorer user specifying config on the explorer for testnet chains etc.

[nambrot]

Scope for now is as follows:

• Allow the specification of additional chain metadatas + core artifacts on the client side (pending PI SDK support, Multiprovider refactor, Type loosening  #1804)
• For messages from a scraper-supported chain to a PI chain:
  • Determine processing status by making a view call to the mailbox
  • If not processed, simulate the processing of the message and surface debugging info
• For messages from a PI chain to any other chain:
  • Allow the search for a message via a tx hash
  • When found, the existing message details page should show up with as much of the existing information as possible
  • I believe it should deliveries on a scraper-supported chain should be queryable
  • Similar to above, message processing should be simulated if the message is known to be not processed

Out of scope (for now):

• any scraper changes
• any indexing on the client side
• fetching of ISM metadata

[asaj]

Allow the search for a message via a tx hash

Can we please include message ID as well?

[nambrot]

Generally speaking or for PI?

I agree on the former, but for the latter, I think we want to avoid doing event searches on the client for now

[nambrot]

Filed #1808 for the former

[avious00]

involves integrating with the registry