Spend more time building for your users, less on wallet integration

Showcase
42

FYI: the guide that you linked to no longer exists:
https://docs.identitykit.xyz/guides/executing-canister-calls

43

For the demo app, if Oisy doesnā€™t support delegation, why is that presented as an option on the connect wallet popup? It would be nice if the list of supported wallets was dynamic, based on the chosen connection type (Account / Delegation). cc @dostro

44

Looks like the post is now too old to edit :cry:
If you havenā€™t found it yet itā€™s here.

Great point, we should add that so people have an example to copy from. Thank you!

45

I think this topic has been discussed multiple times, but I want to bring it up again. can we maybe also take the chance to come to an alignment regarding the naming of the button and the ā€œconnectionā€ method?

  • ā€œLoginā€ / ā€œSign inā€
    • Session authentication / delegation
    • Unique principal per dapp ā†’ enhanced privacy
    • No approval needed if not explicitly enforced by a dapp (session key is used to sign)
  • ā€œConnect Walletā€
    • Using a wallet with a fixed principal
    • Shared principal across dapps
    • Approval required for each tx

What I personally do not like at the moment is if dapps display ā€œConnect Walletā€ and then show Internet Identity as an option to ā€œconnectā€. This seems wrong and missleading to me.

Happy to get more opinions about this, but I hope you agree with this point of view in general.

Maybe we can take this chance to clarify this once for all and adjust docs and examples accordingly :pray:

There might also be use cases where the delegation (Login / Sign In) is needed/wanted for non-token related transactions, but the dapp still wants to additionally integrate with a wallet using the signer standard flow for handling token-interactions. Maybe we can also think about best practices in that regard.

46

From my conversations with dozens of teams and many more individuals, the vast majority of non-DFINITY Web3 devs agree that users are wallet addresses, the caller of a method is the userā€™s wallet address, unique wallet addresses per dapp hinder growth (and what II does automatically is what every other wallet offers as a manual feature), and that a wallet address that can execute calls on behalf of the user is called a session key in other networks (or delegation on ICP). Your POV has been a major point of tension with most of the existing developers Iā€™ve spoken with.

Still, nothing prevents developers from changing the button name and whitelisting their wallets of choice.

47

Hi @b3hr4d, I couldnā€™t find any agentManager in NFID identityKit, or am I missing something?

48

Unfortunately, thereā€™s no agentManager support for NFID yet. I didnā€™t have time to look into the Integration, and the tools arenā€™t available. Iā€™ll have to create it from scratch!

But Iā€™ll definitely try the OpenID integration as soon as it launches on the main-net!

1 Like
49

Ok, thank you for the quick answer.

1 Like
50

FYI we released v1.0.9 10 days ago (with v1.0.10 early next week).

Quick summary of this thread:

  • This work started in the summer of 2023 ā€“ a little over 20 months ago ā€“ because we believed the ecosystem would only grow if we cooperated on making it easier to develop amazing apps via standards. We believe so much in this that we spent the majority of our resources on this initiative, at the expense of working on our own products.
  • Weā€™ve released 32(!) versions since v0.0.0-alpha.1 was first released 8 months ago, and are grateful to all the devs who joined our discord to collaborate with us on bugs found along the way
  • NFID team has helped the Oisy, Plug, and Stoic teams implement and debug these standards in their wallets, and continues to do so out of conviction that this will grow the ICPie
  • NFID has also helped ecosystem teams like Odin.fun, Waterneuron, ICPSwap, Kongswap, Cycleops, Catalyze, Toolkit IC, Bity/GLD DAO, Nuance, Pacapump, Claimlink, Nebula, Yuku, and others adopt standards via the IdentityKit package or something of their own

There are two major initiatives weā€™ve learned need to get done from here:
1. Make it easier for devs to integrate. That includes making it frontend framework-agnostic as well as address local development issues (which is admittedly a long-standing ICP DX issue, not specific to IdentityKit)
2. Make requesting an auth method more flexible. We expected that all wallets would support providing dapps with an account as a string or as a delegation. Unless Iā€™m mistaken, Oisy will only ever provide accounts as a string and II as a delegation. This work would refactor the DX so that dapps may choose a preferred auth type such that one app could authenticate both II and Oisy users.

2 Likes
51

Minor but important for our 33rd version, thanks to feedback from @rem.codes