Experimental ArgentX wallet v5.13.5 (22/feb/2024, ID :pgicobkbegddeldhlnnacicgioehkbem ).
Experimental Braavos wallet v0.0.2.(no evolution)

@dhruvkelawala , @avimak , @ivpavici , @amanusk

Test DAPP : https://cairo1-js-git-testbraavos002-philipper26.vercel.app/
My documentation for this new APi : https://github.com/PhilippeR26/Cairo1JS/blob/testBraavos002/doc/walletAPIspec.md

Result of the tests of the experimental wallets with PR #194 :
(modifications from previous tests in bold)

Disconnecting after connecting doesn't work,

import {connect, disconnect} from "get-starknet";

// Doesn't work
disconnect();

// Neither does this
disconnect( {clearDefaultWallet: true} );

// Nor this
disconnect( {clearLastWallet: true, clearDefaultWallet: true} );

On the next session (in another tab or revisiting later), checking user login status still returns the wallet.

connect( {showList: false} ).then( wallet => {
	wallet
		?.enable( {showModal: false} )
		.then( () => _onConnectedStatusChange( wallet ) );
} );

Background

This is a continuation of the discussion started on the new wallet snip.

/cc @avimak @janek26

Problem

At the moment, the only way to check what browser wallet are available is by checking for starknet_* objects in the window context. This creates an issue when the wallet is slow in injecting itself in the page because it may be unavailable when the user checks for it. The most common bug caused by this is that the wallet won't autoconnect on page load.

Proposed solution

The solution is to have an event mechanism for listening to wallets being injected into the window. There are two APIs that we can leverage:

• MutationObserver: all browsers implement script injection by adding a script element to the dom, so we can use this API to listen for that.
• window.dispatchEvent/window.addEventListener (EventTarget): we define a new event type for wallet being registered (similar to EIP 6963).

I prefer the second option because it's more explicit.

MutationObserver

This solution requires the least amount of work. If we decide to go down this route, I propose wallets use their wallet id (starknet_*) as the id of the injected script so that it's easy to detect them.

What makes me uncomfortable is that it requires a callback invoked for all mutations to the DOM.

EventTarget

The idea is that when the wallet is injected, it emits an event to signal that to the dapp.

interface AnnounceWalletEvent extends Event {
  type: "starknet:announceWallet"
  detail: Wallet // from get-starknet
}

// on the wallet side
window.dispatchEvent(new CustomEvent("starknet:announceWallet", { detail: this }))


// on the dapp side
window.addEventListener("starknet:announceWallet", loadWallets)
loadWallets() // load already injected wallets

Hello,
I found a problem about provider.
User is expecting a provider of type ProviderInterface (imported from starknet.js) :

StarknetWindowObject.ts :

export interface ConnectedStarknetWindowObject extends IStarknetWindowObject {
  isConnected: true
  account: AccountInterface
  provider: ProviderInterface
  selectedAddress: string
  chainId: string
}

But in the window object, in starknet_argentX or in starknet-braavos, provider are not the same and are not with ProviderInterface type.
In starknet_braavos, the provider is a SequencerProvider (imported from starknet.js).
In starknet_argentX, the provider is a specific l type.

On user side, if you use this command : const starknet = await connect({ modalMode: "alwaysAsk", modalTheme: "dark" }); , starknet.provider is not a ProviderInterface, it's the type of the window.starknet_* object :

Fortunately, starknet.js succeeds to process such data, using the Provider class (including a private provider:SequencerProvider).
But you have access only to the methods of a Provider class. You have not access to specific methods of SequencerProvider and RpcProvider classes of starknet.js (like getClassAt, estimateMessageFee or getEvents). And the only data available for the user to try to create a new SequencerProvider or RpcProvider is starknet.sequencer.chainId. If your wallet is connected to starknet-devnet, the chainId is not sufficient to create correctly the new provider.

I think that get-starknet should :

1. return a provider conform to the ProviderInterface type.
2. return also in a different object the following data (to allow the user to create an other provider including the methods he needs) :

baseUrl:'http://localhost:5050'
chainId:'0x534e5f474f45524c49'
feederGatewayUrl:'http://localhost:5050/feeder_gateway'
gatewayUrl:'http://localhost:5050/gateway'

Hey there,

I wanted to bring to your attention an issue that was raised back in February on the provisions-data GitHub page. It pertains to users who have met the airdrop criteria but haven't received anything. Despite my efforts to communicate this to the developers, I was inexplicably banned from Discord some time ago. Undeterred, I'm reaching out here in hopes of raising awareness, as it appears this matter has been overlooked.

Within my post, you'll find accounts from several individuals affected by this issue.

Best regards,
Mathias

Hello,
I tried to install the last release, and whatever I do I get the following error. 1.5.0 works fine.

npm ERR! code ETARGET
npm ERR! notarget No matching version found for get-starknet-core@^2.0.0.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2022-12-08T15_06_46_813Z-debug-0.log

v2 introduces a regression in the silent-connect (now "neverAsk") flow.

    // silently attempt to connect with a pre-authorized wallet
    useEffect(() => {
        // match the dapp with a wallet instance
        connect({ modalMode: "neverAsk" }).then(wallet => {
            // connect the dapp with the chosen wallet instance
            wallet?.enable().then(() => {
                const isConnected = !!wallet?.isConnected;
                setIsConnected(isConnected);
            });
        });
    }, []);

the code above works 100% of the time using v1.5, and it fails on v2.

I suspect a race because adding a timeout with delay=0 helps, i.e. -

    // silently attempt to connect with a pre-authorized wallet
    useEffect(() => {
        setTimeout(() => {
            // match the dapp with a wallet instance
            connect({ modalMode: "neverAsk" }).then(wallet => {
                // connect the dapp with the chosen wallet instance
                wallet?.enable().then(() => {
                    const isConnected = !!wallet?.isConnected;
                    setIsConnected(isConnected);
                });
            });
        }, 0); // <-- no real delay, just skip a cycle
    }, []);

to reproduce, simply use the first version (without a timeout), choose a wallet, approve the connection (aka "pre-authorize"), then refresh the page. do it with a visible browser-inspect-application tab displayed, you'll see the id being removed (ptobably because getAvailableWallets returns empty array).

one more thing - if you adding a timeout, the code works, but you'll see multiple storage ids, meaning there are more races in there.

Background

At Dynamic, we have partnered with StarkWare to build a bridge component as seen on https://starkgate.starknet.io/. We aim to create a smooth login experience for end users. We use get-starknet-core to connect users' starknet wallet, whether it's Braavos or ArgentX.

Problem

There are two scenarios that could have improved UX, and they both begin at a state where the user has already connected a starknet wallet:

1. The user explicitly locks their wallet while it is connected to a dapp and the dapp is open in a browser tab
2. The user locks their wallet while the dapp is not open (either via a browser restart, or by closing the dapp window and explicitly locking their wallet)

Additionally, when dealing with wallets in a locked state, we want to avoid uninitiated wallet popups – meaning, there should not be any wallet popups without the user explicitly clicking on a connect button.

The starknet window object (accessed via get-starknet-core) has a lot of useful properties and methods like isConnected and isPreauthorized, however these cannot be used for accurately detecting wallet locked state while avoiding popups. The main reason for this is that isConnected is always false until enable is called. However, when enable is called, it will prompt the user to unlock the wallet if it's locked, so we have a chicken-and-egg problem.

Proposed solution

There are two parts, each addressing the problems above, respectively:

1. Emit an accountsChanged event with undefined account address when the wallet is locked
2. Add a flag to enable that states the dapp doesn't want to show a popup/UI in case the wallet is locked and/or not preauthorized

Alternate solution

1. Emit a disconnect event when the wallet is locked
2. Expose an isLocked (or isUnlocked, whichever is preferred) value that represents the current locked status of the wallet, whether or not enable has been called.

Disconnect event
When the user explicitly locks their wallet, the wallet should emit a disconnect event that can be handled via the on method, similar to accountsChanged and networkChanged. This will solve the first UX scenario because in our disconnect event handler, we can disconnect the wallet from our app state.

isLocked
There should be a boolean value isLocked accessible via get-starknet-core similar to isConnected that is:

• true when the wallet is locked
• false when the wallet is locked

Additionally, this boolean should have a value before calling enable – it should not be necessary to call enable for this property to have the correct value. This will solve the second UX scenario because our SDK can read this value and determine if it needs to remove the wallet from its connected state. For a reproduction of the UX problem we aim to solve, see: https://codesandbox.io/s/purple-glade-l3llkm?file=/src/App.js. The problem is with the automatic popup – since we have to call enable first to check if isConnected is true, there is a wallet connection popup on page load. If we were able to check isLocked, then we would know to simply "disconnect" the user (reset their connection state in our app), and then show them the connect button again.

Experimental Braavos wallet v0.0.2.
Experimental ArgentX wallet v5.13.0 (06/feb/2024).

@dhruvkelawala , @avimak , @ivpavici , @amanusk

Test DAPP : https://cairo1-js-git-testbraavos002-philipper26.vercel.app/
My documentation for this new APi : https://github.com/PhilippeR26/Cairo1JS/blob/testBraavos002/doc/walletAPIspec.md

Result of the tests of the experimental wallets with PR #194 :

Experimental Braavos wallet v0.0.1-3.49.0 of 2024-05-15. (ID:nliolbfbelmkiidjenchbhkpdpdanimc)
Experimental ArgentX wallet v5.15.3 of 2024-05-15. (ID:clahjokgpdceomgegfbgoojjkebfagme)

@vladutjs , @avimak , @ivpavici , @amanusk

Test DAPP : https://starknet-wallet-account.vercel.app/
My documentation for this new API : https://github.com/PhilippeR26/Starknet-WalletAccount/blob/main/doc/walletAPIspec.md

Config : Linux mint 21.3 with Chrome 124.0.6367.207.
Result of the tests of the experimental wallets, with Starknet.js v6.8.0 & get-starknet v4.0.0-next.5 :

The current implementation of the DetectMetaMaskProvider relies on legacy detection mechanisms, leading to issues when interacting with multiple wallet providers. As the ecosystem evolves, it is essential to adopt newer standards to ensure compatibility and improve user experience.

The EIP-6963 standard provides a modern and robust approach for detecting Ethereum providers, offering better support for environments with multiple wallet providers.

We now have a very good working metamask-snap for Starknet. It can be a great way to onboard new users to starknet, without requiring them to install a new wallet to just try out a dApp.

We should add Metamask as an option as well here, i.e the ability for a dApp to connect with metamask snap as the starknet wallet.

This will require a wrapper { we can discuss whether it should live here, or as a seperate npm package }, the wrapper should be able to wrap the metamask injected provider, and embed a starknet wallet provider in the window object, and that should allow us to add metamask to UI, and be able to send transactions via it.

Hello! I don't know if it's ok to open an issue for this, but I wanted to comment on it if applicable, apparently if you have a svelte app using get-starknet, only one of the two wallets can be used because userAgent is deprecated by Chrome. From what I could see it is being used in the Modal.svelte:

This is the warning I see in the browser:

And the problem (i think) is that it is not detected to have Braavos installed, I am investigating to find some alternative way or to solve the problem.

Dependencies (tried different versions of both starknet and get-starknet 2.0.0 doesn't work either):

i cant connect Braavos Wallet in local. but i has install the braavos plugin. click connect button ,show the "Install Braavos". why?

@avimak @tabaktoni @ivpavici

Linked to #194

My test DAPP has been updated for the experimental Braavos wallet v0.0.2, and is available here : https://cairo1-js-git-testbraavos002-philipper26.vercel.app/
The results of my tests :

1. subscription to events :

It's working fine for subscription / unsubscription.
At change of network, both account and network events are well occurring.

But I have still unexpected account change events, at each new block.

2. wallet_getPermissions :

It works.

• Return accounts string, in an array of one item.
• If the user declines the permission, the response is an empty array.

3. wallet_requestAccounts :

It works.
Returns an array of hex string ; just use first element.

Still not a fan of this type of response ; I think it's not a good idea to use an array to hold just one account address. It encourages abusing this accounts array to pass arbitrary data. It's a way for security issue.

4. wallet_watchAsset :

It works. The result is true.

The optional parameters are useless, as they are automatically recovered from the blockchain. Whatever you provide, only the blockchain data are used.

• If the address is not an ERC20, the result is false.
• If the token is already displayed, the result is true.

If the user decline the request, the function throw an error. Impossible to differentiate with an internal browser problem.

5. wallet_addStarknetChain :

Not supported by Braavos wallet 002.

6. wallet_switchStarknetChain :

Not supported by Braavos wallet 002.

7. wallet_requestChainId :

It works.

• response is string encoded of SN_MAIN, SN_GOERLI or SN_SEPOLIA.

8. wallet_deploymentData :

This new function is always throwing an error, even just after starknet_addDeployAccountTransaction.

9. starknet_addInvokeTransaction :

It works.

If the user declines to sign, the function throw an error. Impossible to differentiate with an internal browser problem.

10. starknet_addDeclareTransaction :

The problem encountered in 001 is still there : #196 (comment)

11. starknet_addDeployAccountTransaction :

It works.

• The address of deployment is not the one expected with the universal deployer. Ex :

const decClassHash = "0x2bfd9564754d9b4a326da62b2f22b8fea7bbeffd62da4fcaea986c323b7aeb"; // OZ cairo v2.1.0
const starkKeyPub = "0x03cb804773b6a237db952b1d4b651a90ee08651fbe74b5b05f8fabb2529acb45";
// calculate address
const OZaccountConstructorCallData = CallData.compile([starkKeyPub]);
const OZcontractAddress = hash.calculateContractAddressFromHash(starkKeyPub, decClassHash, OZaccountConstructorCallData, 0);

Expected address is 0x360ccaecfd9fb321de0b70da56bc9b96510b75a6ee21e8e9b547f4710ad007f
But the function is returning :

transaction_hash: 0x1aca7fffb34c41d28ad365de6d353111c96a520120275935296f30ca3b012f9 
contract_address:[0x4e892bb64e39cef7363151cfb2aae45216ea3ea6c4200da6ac9c37cf9e14dac]

• The response type is not conform to AddDeployAccountTransactionResult.contract_address: FELT

request starknet_addDeployAccountTransaction resp = {
    transaction_hash: '0x1aca7fffb34c41d28ad365de6d353111c96a520120275935296f30ca3b012f9', contract_address: Array(1)}
        contract_address: Array(1)
            0: "0x4e892bb64e39cef7363151cfb2aae45216ea3ea6c4200da6ac9c37cf9e14dac"
        length: 1
        [[Prototype]]: Array(0)
        transaction_hash: "0x1aca7fffb34c41d28ad365de6d353111c96a520120275935296f30ca3b012f9"[[Prototype]]: Object , 
    crash = false

The address is in fact an array. Same comment than wallet_requestAccounts.

• If the user decline the request, the function throw an error. Impossible to differentiate with an internal browser problem.

12. starknet_signTypedData :

It works.

• It returns an array of hex string.

If the user declines to sign, the function throw an error. Impossible to differentiate with an internal browser problem.

13. starknet_supportedSpecs :

It works.

• The response is an array of strings. Each string is the version of a supported starknet API version. Includes only the 2 main digits ; example : 0.5

In starknet-react we want to give control over wallet selection to our users. One use case is that developers want to show some browser wallets even if they're not installed. It would be helpful to have a getWallet(id: string) method that returns the wallet object if it's installed, or null/undefined if not.

Description:
when connecting a wallet, it will set the wallet id into Storage,
when setting a item in Storage, it will generate a UUID as key and delete the previous item with the previous key

however, if we try to get the storage in async way, e.g put getLastConnectedWallet in reactjs useEffect

the behaviour will become a racing condition, new item may appended to the storage

it could result when getting last wallet id incorrect

resolution:
may try to use https://www.npmjs.com/package/async-mutex to create lock

The current implementation has the remoteEntry.js URL hardcoded, which poses challenges for local testing and integration with MetaMask StarkNet Snap. To address this issue, we propose introducing an environment variable to dynamically handle the URL. This enhancement will improve the flexibility and ease of testing different environments.

We suggest adding a new environment variable named VITE_MM_FED_URL. This variable will allow developers to specify the remoteEntry.js URL during local development. If the variable is not set, the system will default to the original hardcoded URL, ensuring backward compatibility.

file concerned : packages/core/src/wallet/metamaskBridge.ts

1. Allow dapps to connect to a specific chain
2. Allow dapps to add a custom chain via wallet_addEthereumChain
3. Allow dapps to to switch chains via wallet_switchEthereumChain
4. support chainChanged event

Hey guys!

I am using get-starknet module for wallet connection but I found crazy logs in the browser console.
import { getStarknet, connect, IStarknetWindowObject } from "get-starknet"

It seems you're logging all messages. Is it mandatory or could you address it?

Tests made 28/apr/2024 with :

• Linux Mint 21.3
• Starknet.js v6.8.0
• Get-starknet v3.3.0
• A demo DAPP built with Next.js : https://cairo1-js.vercel.app/
• Chrome v124.0.6367.60
• Brave v1.65.114
• FireFox v125.0.2
• network : Sepolia testnet
• all accounts have ETH in their balance, and no STRK.

tests of connection :

OKX :

Extension not available in Firefox.

Tests of transaction :

Metamask

Brave :

Firefox:

good aidea

Hello,
PR #194 has been created by @avimak to decouple Starknet.js from get-Starknet.
One consequence is that Starknet.js will have to communicate directly with the Wallets (ArgentX, Braavos, ...). Work is in progress in the Starknet.js team (@tabaktoni).

My understanding is that the DAPP will request to get-starknet-ui a simplified StarknetWindowObject (without any .provider and .account), and will have access to some requests & events.
Requests :

• wallet_requestAccounts
• wallet_watchAsset
• wallet_addStarknetChain
• wallet_switchStarknetChain
• starknet_addInvokeTransaction
• starknet_addDeclareTransaction
• starknet_addDeployAccountTransaction
• starknet_signTypedData

Events :

• accountsChanged
• networkChanged

I have some questions :

Transaction rejected

• If Starknet.js send one of these requests : starknet_addInvokeTransaction starknet_addDeclareTransaction starknet_addDeployAccountTransaction & starknet_signTypedData, and if the user reject the request of signature, how will be the DAPP informed?
• If Starknet.js send the request : starknet_signTypedData, and if the typed Message has a wrong format, how the DAPP will be informed?

Current account

• With the request wallet_requestAccounts or the event accountsChanged, the DAPP is informed of the list of accounts related to the current network. How Starknet.js will be able to switch to one of these accounts?

Event for account changed in Wallet

If the current network is switched in the Wallet, the DAPP is informed by the event networkChanged.
If the current account is switched in the Wallet, there is no event for this situation. Couldn't it be beneficial to add an event addressChanged?

estimateFee

There are no requests for estimateFee. How will the DAPPs handles this subject?

simulateTransaction

Same question than the previous subject.