Etherscan like User Profiles

[mshakeg]

Problem

Etherscan allows users to login to a user profile using their email and gives them access to a number of features such as the following.

Primary Features:

• Watchlists - enables users to watch transfers to and from specified accounts; email notifications are sent out
• Address Private Name Tags - A private name tag (up to 35 chars) and memo (up to 500 chars) for individual addresses can be saved and is useful for labelling addresses of interest.
• Transaction Private Notes - A private transaction note (up to 100 characters) can be saved and is useful for transaction tracking.

Secondary Features:

• Verified Addresses - allows for users to prove ownership of an account that created a contract/token/etc and subsequently modify off-chain contract/token metadata displayed on Etherscan.
• Custom ABIs - allows users to add a custom ABI for an unverified smart contract to interact with it once logged-in to their Etherscan account.
• Token Ignore List - Hide selected tokens from being displayed in the Address Token Summary, Token Holdings and Watch List pages.

Solution

For the team to investigate the feasibility of this ask and decide on the exact implementation details ;)

Alternatives

No response

[SimiHunjan]

@mohsin-hedera can you please review the priority on this issue? Thanks!

[mohsin-hedera]

Very much of interest and would like to pick this up once we have the SC Verification work in place

[Neurone]

I suggest to leverage local storage for all the preferences. This is also useful for features like Labels (#565) and can be expanded in the future with export/import/sharing capabilities to let the community create public/private/shared lists of preferences.

[mshakeg]

Hey @Neurone

I recently came across https://routescan.io and noticed that their user profiles share some similarities with the solution you described in our call, particularly in terms of data export and import functionality. However, I have concerns about Routescan's current implementation that I believe could be improved upon:

1. Centralized Data Storage: It appears that the profile data is stored on a centralized backend. I believe Hashscan users should have the option to persist their profile on any widely recognized decentralized storage solutions, and should not be limited to Hedera (e.g., IPFS, Filecoin).

2. Privacy: I am uncertain about the privacy level of Routescan's Private notes, as there are no requests to decrypt a user profile after connecting and signing in with MetaMask. I think this could be relatively easily implemented by encrypting the user profile with the user's public key (retrievable via eth_getEncryptionPublicKey from MetaMask and possibly other wallets that support it) and decrypting it with the private key (via eth_decrypt from MetaMask). For efficiency, you would probably want to encrypt profile data with a symmetric key, then encrypt that symmetric key with the user's public key and persist both on the storage provider of choice. This symmetric key could reside in the browser's session/local storage for quick access during the same session/browser to avoid having to continuously request the wallet(and user) to eth_decrypt on every login.

I'm still very curious about how #760 will be implemented, if at all.

Edit:

Took another look at Routescan and its private for BOTH you and them and not ONLY you, as the private notes request response returns the private notes unencrypted. Also eth_decrypt and eth_getEncryptionPublicKey are deprecated though I don't the user flow to change much on any EIP that replaces EIP-1098.

[Neurone]

Hi @mshakeg , we are still defining all the details, almost there, but these are the summary of my suggestions. I consider a must defining standards for what we do and how we do it.

In particular, about labels, tags, notes, etc.:

1. Define an open and extensible standard to define user preferences so everyone can use it (web apps, CLIs, etc.)
2. Define an extension for the MNE dealing with labels, tags, notes, etc.
3. Using that standard, the MNE stores/manages preferences by default in web browser storage, and it can export/import (FileSystem and IPFS)
4. MNE encrypts preferences by default with password encryption (AES via KDF)
5. Privacy is paramount: no connection or references to any wallet or existing Hedera key. In addition, using the private key as a login method is a bad common practice. Users should sign TX only when they want to send a TX; using it to sign a custom payload is very risky.

About the community notes feature, we can leverage the above standard format and add the following:

1. Define an open and extensible standard to collaborate (share, discover, retrieve, vote, manage votes) on preferences so everyone can use it (web apps, CLIs, etc.)
2. Define an extension for the MNE dealing with labels, tags, notes, etc.
3. Using that standard, the MNE stores, discovers, and reads preferences by default via HCS (metadata and small payloads) and IPFS
4. Users can either keep preferences encrypted while sharing with the above standard or make them plain and visible
5. As mentioned above, encryption keys are not related to the keys used to share the content via Hedera (i.e. paying for Hedera txs)

What do you think?

[mshakeg]

Hi @Neurone

I'm in agreement with the first three points regarding establishing an open extensible standard and the approach to storage and export/import functionalities.

However, I have some thoughts on points 4 and 5:

4. Encryption with AES via KDF: While I understand the intention behind using a dedicated MNE password for encryption, considering the explorer already supports wallet connections, we might explore streamlining this process using the connected wallet to simplify user interaction by avoiding additional passwords.

5. Privacy and Wallet Connections: I appreciate the emphasis on privacy and the caution against misusing private keys. However, leveraging wallet connections for encryption—without requiring transaction signing—presents a user-friendly way to enhance security. IMO methods like eth_getEncryptionPublicKey for encryption and eth_decrypt for decryption can securely manage user data, aligning with our privacy goals without the downsides of additional password management or unnecessary transaction signing(though I don't really see much of an issue with signing an EIP-712 structured human readable message).

Regarding the community notes, I think those are excellent ideas. However, my current understanding of HCS capabilities and what the mirror node indexes and exposes leaves me uncertain about the feasibility of implementing features like sharing, discovering, retrieving, voting, and managing votes at scale. Additionally, a reputation system akin to that of Stack Exchange might be beneficial for encouraging positive community moderation and contribution.

[Neurone]

Thanks for the feedback, I really appreciate it.

I agree the UX should be easy, but it is up to the wallet providers to make it real, and they can implement encryption more easily via AES than EC keys.

The fundamental topic in favor of AES via KDF is that it does not exclude the creation of other solutions on top of that. If we go with the Ethereum encryption, we force the usage of something not meant for that purpose; all the tools out there are ready for signing tx and verifying signatures, not encrypting payloads.

With symmetric encryption, you get a base secure layer that is fast and easy to implement, and on top of that, anyone can build their preferred secure store (i.e., a browser wallet, a secure vault, etc.).

Once clients or wallets support the standard under the hood, creating the desired UI/UX for their audience is just a matter of a few more lines of code.

Encryption with symmetric keys unrelated to your private Hedera keys is the best approach for me, also because of these issues:

1. Encryption via EC keys is non-trivial, can be tricky and usually not reccomended
2. The MetaMask JSON-RPC API specs introduced the methods eth_getEncryptionPublicKey and eth_decrypt but they are deprecated, and they are not part of the standard Ethereum JSON-RPC APIs. Other proposals attempting to replace DRAFT-EIP-1024 after its closure like ERC-5630 never took off and they are stagnant, so my bet is that is something we will not see soon broadly adopted.
3. The wallet - meaning a secure keystore of secrets that can sign payloads - is a more complex piece of software than simple encryption. Even when using the browser, you need a dedicated extension for the wallet - ok, I use Brave, but the point is that it is an external and complex component. Dealing with wallets via CLIs or backends is far more complex than dealing with passwords.
4. Using private keys limits the shareability of the data. If I want to share that encrypted info with a set of players, I must disclose what I usually consider and use as a private key. Once the private key is disclosed, that private key can be used to sign transactions, not only to encrypt payloads. So, the best practice would be to use a new dedicated key for each encryption operation, and I can bet everything the users will not do unless it's done transparently by the wallet. And if it's done transparently by the wallet, it's easier for the wallet to use a dedicated password/key.
5. Because encryption/decryption via EC keys is not common, almost all HW wallets support only signing payloads, not encryption/decryption, and I hardly see a change there.
6. About EIP-712 - I also have opinions about it, but let's put them aside for this discussion ^^ - but the point is that it is a standard for singing payload, not dedicated to encryption, so we cannot leverage it. And again, it is also very Ethereum-centric and not easily extensible.

About community notes, the draft idea is to use HCS for operations and metadata (because it's limited to 1 Kb of data), linking IPFS CIDs for the actual payloads.

We use the same technique, for example, for the Guardian's trust chain or the CRUD operations on the Hedera DID v1. We can do something similar for other use cases, like the community notes.

[mshakeg]

@Neurone thank you for your detailed response. I'd like to clarify a few aspects of my proposal to ensure we're on the same page:

1. Regarding EIP-712: My mention of EIP-712 was intended to highlight its utility in creating human-readable messages for signing, not as a method for encrypting user data or as a core part of the user interaction for the Hedera explorer. I was just pointing out that I don't see any issue with Routescan's request to sign an EIP-712 message to authenticate an EOA with their backend service. Also, many dApps(especially in DeFi) do something similar by requesting a user to sign a message declaring that they accept the terms of service, etc.

2. Encryption Strategy for User Profile Data: My proposal as outlined in the latter part of point 2 of this message seeks to leverage a two-step encryption process somewhat similar to the hybrid encryption scheme described in ECC Encryption / Decryption(which seems like a more robust way of going about it). The intent is to use the connected wallet's public key encrypt a symmetric key, and not to encrypt user profile data directly with the wallet's public key. However, I am also open to the idea of having an alternative option for a MNE password as a fallback(e.g. their preferred wallet does not support methods for encryption/decryption or at least does not support methods compatible with the MNE).

3. I think it's worthwhile developing alternative standards to EIP-1024 and ERC-5630 compatible with Ed25519 accounts for Hedera wallets to adopt.