When unregistering a wallet, it seems to remove all wallets except for the one I tried to unregister in useStandardWalletAdapters. I think the filter is filtering for only the wallet I'm trying to unregister instead filtering for all the wallets but the one I'm trying to unregister.

In particular at

should it be wallets.some((wallet) => wallet !== standardAdapter.wallet)?

(Aware that this isn't supposed to be used by dApps necessarily, but wanted to use it for some in-team testing purposes)

Motivation

Many potential applications might prefer to encrypt end user data via a public key the user controls rather than encrypting via a user's password (i.e. lastpass), as passwords are a poor UX compared to a web 3 wallet. Metamask currently is the only web 3 wallet I'm aware of which offers the ability to decrypt via private key. Ideally Solana wallets should support this, and ideally all the wallets would use the same algorithm for obtaining a public encryption key and the same asymmetric encryption algo too. In the linked EIP you see a proposal for wallets to offer an RPC for encryption via secp256k1 + ECIES.

Details

Relevant discussion in Ethereum: https://ethereum-magicians.org/t/eip-5630-encryption-and-decryption/10761/128
Metamask SDK:

• encrypt: https://docs.metamask.io/wallet/reference/eth_getencryptionpublickey
• decrypt: https://docs.metamask.io/wallet/reference/eth_decrypt/

Open related issue in Backpack coral-xyz/backpack#4241
Open related issue in Solana Mobile Seed Vault solana-mobile/seed-vault-sdk#144
Closed related issue in Solana web3 repo solana-labs/solana-web3.js#1367

Hi @jordansexton , the docs mention:

This guide is for wallets that want to implement the Wallet Standard. This can be done in essentially two ways.

A. Write a wallet with a Wallet Standard compatible API.
B. Wrap your existing API with a Wallet Standard compatible API.

These methods are similar, but since wallets that exist today already have their own APIs, we'll focus on the latter.

Are there any docs on A? I have an existing wallet (connecting to Solana, handling token transfers, transaction history, getting NFT metadata, etc) and simply want to:

• add whatever I need for Wallet Standard
• not add any other code (some Phantom-specific implementation detail that I don't need)

Link https://solana-labs.github.io/wallet-adapter/example/ is not available anymore

My discover
ASISAME#5708

Steps to reproduce:

• Install OKX Wallet Extension
• Run an app that uses Solana wallet adapter (you dont even have to open the OKX extension)

The error:

react-dom.development.js:22839 Uncaught TypeError: off is not a function
    at StandardWalletAdapter.destroy (adapter.ts:125:13)
    at useStandardWalletAdapters.ts:40:73
    at Array.forEach (<anonymous>)
    at useStandardWalletAdapters.ts:40:44
    at safelyCallDestroy (react-dom.development.js:22932:5)
    at commitHookEffectListUnmount (react-dom.development.js:23100:11)
    at invokePassiveEffectUnmountInDEV (react-dom.development.js:25207:13)
    at invokeEffectsInDev (react-dom.development.js:27351:11)

Its coming from this method:

destroy(): void {
    this.#account = null;
    this.#publicKey = null;
    this.#connecting = false;
    this.#disconnecting = false;

    const off = this.#off;
    if (off) {
        this.#off = null;
        off();
    }
}

Can you please share any wallet's code that implement your standard. Because In my wallet's contentScript I done what you said but its not working. Also my wallet support SOLANA, NEAR and ETHEREUM tokens. Please help. Stuck on this for days.
My mail: [email protected]

Overview

Inspired by EIP-3085, this design allows Solana applications ("dapps") to suggest chains to be added to the user's wallet application. The wallet application may arbitrarily refuse or accept the request. We have received a request for this feature from many dapps.

Desired Outcome

The desired outcome is for dapps that are on testnets, canary chains, or other SVM chains to be able to conveniently prompt their users to switch networks and seamlessly interact with their dapp and see their assets rather than requiring complex manual custom RPC changes. As more SVM chains spin up, this can prevent a mess with multiple standards and one-off implementations down the line.

Implementation

1. Solana Wallet Standard: At first glance there are some changes needed to the Solana wallet standard. There are places where the wallet is required to return all chains that it supports, so we would need some interface for the dapp to pass back a new chain to be added: https://github.com/solana-labs/wallet-standard/blob/master/packages/wallets/solflare/src/account.ts#L25 This change seems like it could be made immediately if it is done in a non-breaking way. The wallet should not be required to add a chain even if the dapp requests it.
2. Wallet Adapter: We would need to make some change to the wallet adapter so the dapp can specify the desired RPC network. This would need to be rolled out after the Wallet Standard change.
3. Dapp Support: The dapp updates their Wallet Adapter library and specify their desired RPC network. If no RPC network is specified, by default this change has no effect - the behavior is exactly the same as SVM wallets function right now (default to Solana mainnet). This is the last change to occur.

Describe the bug
https://github.com/solana-labs/wallet-standard/blob/master/WALLET.md states, after registering the wallet implementation:

// Attach the reference to the window, guarding against errors.
try {
    Object.defineProperty(window, 'uniqueNewYork', { value: uniqueNewYork });
}
catch (error) {
    console.error(error);
}

We should probably remove this:

• The global seems to be unnecessary - registering the wallet is enough for the wallet to work. Removing the global would avoid unnecessary complexity, Exupery's law, etc.
• HTML element IDs are globals - yes under window, not just window.document. As wallets are loaded on all web pages, and the element IDs being globals is expected behaviour (it goes all the way to Internet Explorer) there's a non-zero chance a wallet name will conflict with an element ID on an arbitrary web page.
• There's a smaller chance a wallet name may conflict with an existing well-known global. Maybe someone is new to web dev and thinks navigator is a good name for their new wallet (in this case defineProperty() will work, then things will start failing for the rest of the page).

Happy to submit a PR just thought a discussion would be preferred in case I'm missing something.