openzeppelin / accesscontrol-explorer Goto Github PK

We will receive requests to support new chains. We should document the process to deploy a new subgraph for those chains.

How do we deal with subgraph updates? Can subgraphs be versioned so that they can be updated asynchronously/progressively? The UI should be version-aware.

Ideally we would be able to accept PRs to integrate subgraphs deployed by contributors. Is there a checksum to validate that the subgraph code is not tampered?

The data shown in the explorer is only truthful if contracts are honest. We should have a disclaimer somewhere that a dishonest contract can lie about roles or owners.

In the pattern where a contract is its own admin, in the "Member Of" panel, we should label the contract's own address as "self".

Embed the video for our workshop on the topic: https://www.youtube.com/watch?v=g68PZua0lKQ

EIP-3770 addresses look like eth:0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe or poly:0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe. They map to CAIP-10 identifiers which look like eip155:1:0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe.

We should support EIP-3770 but also CAIP-10 as not all chains will be covered by the former. Support for EIP-3770 should be built by mapping to CAIP-10 under the hood.

I'd propose to have URLs formatted in this way, maybe /eth:0x1234...5678/contract.

The search bar should also support entering a chain-prefixed address.

The mapping from role ids to role names is a huge JSON file generated at build time. It weighs about 1MB (about half when gzipped) which is more than the entire web app, and really slows down loading.

One alternative is to load it asynchronously, but at least a naive implementation of this resulted in flashing role ids before actually being decoded to names.

There are many ways in which this can be optimized.

1. We currently generate the dictionary by taking base names and generating variations of the name (e.g. from "whitelist" we generate "WHITELIST", "WHITELIST_ROLE", "ROLE:WHITELIST", and so on) and also variations of the identifier scheme (using the name bytes directly, or hashing them, or ABI-encoding then hashing). This results in lots of ids that are not necessarily in use and the size of the dictionary grows exponentially(?) for each new variation. We could reduce the approach to only generate those ids that are actually in use and this will probably drastically reduce the size of the dictionary.
2. A second question is if we want to send a pregenerated dictionary or send the role names and hash them on the user's computer. This will reduce the size of what we send over the network by not sending the hashes (which because of their randomness don't even compress significantly), but will require computation on the user's side. This would need to be done off the main thread so it introduces some complexity for dealing with Web Workers and properly caching the result.
3. If we send the prebuilt dictionary, we may not want to send it fully and instead expose an endpoint for each id and in this way only transfer what's strictly necessary.

The account view is currently scoped to one chain, but accounts can have roles on multiple chains and it makes sense to want to see all of them at once. Like how Zapper displays assets across all chains. With AccessControlCrossChain this is particularly relevant.

This may be simpler to implement with an upcoming version of @urql/svelte so we may want to wait for that (urql-graphql/urql#2370).

When viewing an addess such as
/view?address=0xC0eb11fBC755D31c6FECEaAc8760ddCb88C64fE1
and clicking on one of the owned contracts (for example 0x0277dd6961fc3B9b7D6D89dc275888B11465b4A5) the new data sometime isn't valid.

In particular, the page header and other elements list might be kept in cache.

This is because of src/componants/utils/Fetch append mechanism for paginated queries.

• Sometimes props.variables change, but the previous query included only one page
• In such case, setting offset to 0 doesn't trigger any change.
• manifest should help detect and sort these things, but apparently this bug still exists :/

The one example we have currently is an Ethereum mainnet contract. We should make sure it always links to the contract on that chain.

Somewhat related to #11.

We may want to have examples on various chains.

When copy-pasting the addresses as seen in Access Control Explorer to use in ethers.js scripts, I keep getting error:

reason: 'bad address checksum',
code: 'INVALID_ARGUMENT',

Minor usability tweak, when clicking in addresses to view in an external block explorer, open a new tab instead of navigating outside of Access Control Explorer.

Logs are currently only visible in the general "contract" page. When visiting a particular role in that contract, we should list the granted and revoked events for that specific role.