What explorer is and what is not?

[MaksymZavershynskyi]

• Should explorer be our equivalent of https://etherscan.io/ ? If yes, which features of Etherscan should it implement?
  • Contract source code linking with verification;
  • Support of fungible tokens and non-fungible tokens;
  • Profiles for the contracts, e.g. social links, icon, etc.;
  • Analytics and comments for contracts;
  • Ability to annotate fraudulent accounts;
  • etc
• Should it be considered to be a part of the contract development tools? If yes, how should it integrate into the development workflow?

[kcole16]

We certainly need something like an Etherscan, whether or not we build it is a question of whether we're willing to resource it similarly to Etherscan (which is a full company).

There are a lot of features to add, and as NEAR scales there will increasingly be more and more useful features (see Etherscan's continual evolution). @ilblackdragon mentioned a potential evolution of the Explorer into a developer portal and dashboard, which could include things like testnet faucets, contract/account tracking tools (detecting strange behavior, notifying of TX failures) etc.

Looking at alchemyapi.io, there is likely a business in this. IMO, the ideal long term case is that this is picked up and treated like a business, whether by us or by an external team or company. It will be difficult to match the quality of Etherscan without a similar amount of resources, and the case for expending these resources long term is somewhat weak without a business case.

As for priorities, the first two features you mention are the most critical IMO.

• Fungible and NFTs we should support relatively soon
• Contract verification is very valuable, and ideally this exists somewhere in our ecosystem shortly after Phase 2 (whether we build it or not)

[frol]

Should explorer be our equivalent of https://etherscan.io/ ?

Yes, though the scope is huge, and currently we focus on correctness of the viewed data. So far we missed quite a core part of the internal detail (receipts and execution outcomes).

Should it be considered to be a part of the contract development tools?

I believe, we should pursue this as well, at least Explorer needs to be able to display the data in a reasonable way, so developers can definitely use it, and the workflow is that near-api-js / near-shell just print a link to the transaction they initiate, and Explorer should be able to display the whole progress of the transaction clearly communicating the execution graph.