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

Integration of ic-reactor with IdentityKit

Background

Currently, integrating ic-reactor with IdentityKit requires wrapping the entire application in multiple providers and manually updating the agent and authentication state. This approach is less straightforward and user-friendly compared to modern Ethereum development tools like Wagmi.

Ethereum Approach and Developer Experience

In the Ethereum ecosystem, libraries like Wagmi have significantly improved the developer experience. Wagmi provides a set of React hooks for Ethereum, while Viem handles the lower-level interactions with the Ethereum network.

Key aspects of the Wagmi approach:

  1. Configuration-based setup
  2. Seamless integration of wallet connections
  3. Automatic handling of network changes and disconnects
  4. Easy-to-use hooks for common operations

For example, in a Wagmi setup:

import { createClient, http } from "viem"
import { sepolia } from "viem/chains"
import { createConfig } from "wagmi"
import { injected, coinbaseWallet, walletConnect } from "wagmi/connectors"

export const walletConnectConnector = walletConnect()
export const coinbaseWalletConnector = coinbaseWallet()
export const config = createConfig({
  chains: [sepolia],
  connectors: [walletConnectConnector, coinbaseWalletConnector, injected()],
  client({ chain }) {
    return createClient({ chain, transport: http() })
  }
})

function App() {
  return (
    <WagmiProvider config={config}>
      <YourApp />
    </WagmiProvider>
  )
}

and they will have:

This approach allows developers to easily configure their dApp and start using Wagmi’s hooks without worrying about the underlying complexity.

Proposed Approach for ic-reactor and IdentityKit

We should consider adopting a similar approach for ic-reactor and IdentityKit integration. This would involve:

  1. Creating a configuration object that combines ic-reactor and IdentityKit settings
  2. Developing a single provider component that handles both ic-reactor and IdentityKit functionalities
  3. Providing hooks that abstract away the complexity of agent management and identity handling

Here’s a proposed implementation:

import { createAgentConfig, AgentProvider } from '@ic-reactor/react'
import { NFIDW, Plug, InternetIdentity } from "@nfid/identitykit"

const config = createAgentConfig({
  signers: [NFIDW, Plug, InternetIdentity],
  featuredSigner: NFIDW,
  targetCanisters: ["canister-id"],
  authType: 'delegation',
  onConnectSuccess: () => console.log('Connected successfully'),
  onConnectFailure: (e) => console.error('Connection failed:', e.message),
})

function App() {
  return (
    <AgentProvider config={config}>
      <ActorProvider canisterId="YourCanisterId">
        <YourApp />
      </ActorProvider>
    </AgentProvider>
  )
}

In this setup, developers would use hooks provided by ic-reactor:

import { useQueryCall, useAuth } from '@ic-reactor/react'

function YourComponent() {
  const { isConnected, connect, disconnect } = useAuth()
  const { data, loading } = useQueryCall({
     functionName: "YourFunctionName"
  })

  // Use these hooks to interact with the IC network and manage identity
}

Benefits

  1. Simplified setup process
  2. Improved developer experience
  3. Consistency with modern web3 development practices
  4. Easier adoption for developers familiar with Ethereum tools

Next Steps

  1. Gather feedback from the community on this approach
  2. Design and implement the configuration system
  3. Develop the integrated provider component
  4. Create and document new hooks for common operations
  5. Update documentation and provide migration guides

Community Input

We’d like to hear from the community:

  1. How does this approach align with your development needs?
  2. Are there specific features from Ethereum tools you’d like to see implemented?
  3. What challenges do you foresee in adopting this new approach?

Please share your thoughts and feedback to help shape the future of IC development tools.

5 Likes

Woah, excellent!!

Do you have a sample app deployed built with ic-reactor?

Thank you for your enthusiasm! To answer your question:

If you mean just ic-reactor alone, you can check out B3Forge, which is an example of an application built with ic-reactor.

If you mean with IdentityKit integration, not yet! I don’t have a sample app deployed that demonstrates the combined use of ic-reactor and IdentityKit.

I’d love your help to move this forward. Specifically, we need assistance in two areas:

  1. Creating the configuration system outlined in the proposal. This would allow for a more streamlined setup process similar to Wagmi.

  2. Developing a vanilla API for IdentityKit that can be used within ic-reactor. This would enable tighter integration between the two libraries and provide a more cohesive developer experience.

Would you be interested in collaborating on these aspects?

I think you could use slide-computer/signer-js as the vanilla API(?)

2 Likes

FYI Plug update with bug fixes is out!

Cc @skilesare

1 Like

kk…let me ping the guy who did the patch.

Basically, the same code is here as well…if you have anyone that wants to do a reference implementation I’d be happy to accept a pull request that unifies the login.

Otherwise, if you have a best practices guide I’ll get to it eventually.

1 Like

We have docs here and looking at the repo, seems like a fairly straightforward integration.

We’re currently supporting a dozen devs across discord/slack/X so we’re also a bit under-resourced to submit a PR but did put this on our list! :raised_hands:

1 Like

@nfid/identitykit@0.0.4 released:

  • automatic delegation expiration management (disconnect user if delegation expires on page-load or in-session)
  • set default delegation maxTimeToLive to 30min (though this is configurable)
  • useTargetAuthenticatedAgent and useNonTargetAuthenticatedAgent hooks to call target and non-target canisters respectively
  • fixed derivationOrigin
  • fixed Plug targets

https://docs.identitykit.xyz

1 Like

Hi there, Sam Drissi here, co-founder of bIPQuantum. We’re developing a tech-driven IP solution combining AI and ICP, leveraging NFID for secure user management. We’re excited about NFID’s potential to streamline the user experience, but we’re currently facing some challenges with ic-reactor and would love an update on its development timeline. Could you share any insights or a potential release date? This will help us align our launch and ensure a smooth integration. Thanks!

What issue are you facing? Have you contacted ic-reactor’s @b3hr4d ?

Hi Sam, thanks for your interest! At the moment, I’m waiting for the vanilla version of IdentityKit to be released. Once available, I’ll integrate it directly into the core package of IC-Reactor, which will streamline the integration across the system and reduce the manual effort involved. This will ensure smoother functionality and better performance.
I’ll share updates on the release as soon as I have more concrete information.
Looking forward to seeing how bIPQuantum utilizes IC-Reactor!

Thanks for the suggestion, Dostro. The primary issue we’re encountering with NFID involves the seamless integration with IC-Reactor for secure and reliable authentication. We are reaching out to @b3hr4d for guidance on overcoming current challenges.

Hi @b3hr4d, thanks for the update on the integration with IdentityKit! Given our timeline, we’re currently blocked and eager to move forward with NFID for bIPQuantum. Could you provide a more specific release date or any interim solutions for integrating NFID into IC-Reactor? This would greatly help us plan our next steps effectively. We’re looking forward to leveraging the enhanced functionality your update will bring to streamline our IP-driven platform.

Hi Sam, thanks for your patience! Once the vanilla version of IdentityKit is available, which shouldn’t take longer than a week on my end, I’ll be able to fully integrate it into IC-Reactor. In the meantime, a workaround would be to create an agent manager using the IdentityKit-provided agent and pass it into the:

<AgentProvider agentManager={identityKitAgentManager}>

However, one limitation to be aware of is that the current IdentityKit agent prompts for permission on every query call, which might affect the user experience. I’ll keep you updated as things progress!

Popups depend on authType and agent used. Query calls that don’t need to be executed by the user should be called with an anonymous identity, otherwise using identityKitAgent will attempt to execute the query as the user for which you probably don’t have permission.

We’re releasing a new version this week where identityKitAgent will dynamically route how to execute the call (anonymously, without popup if permission was given, or with popup if not).

More on executing canister calls on ICP and summary table below.

Auth option Wallet address Wallet approval pop-up for executing calls to your canisters Wallet approval pop-up for executing calls to other canisters
Account Global Yes Yes
Account Delegation Global No Yes
Relying Party Delegation Unique to dApp URL No No

I would say, most of the queries are user-specific, so they need to be executed on behalf of the user. Anonymous identities wouldn’t work for those calls.

Exactly, and that’s why I’m holding off for the vanilla version of IdentityKit. The current hooks make managing this process quite cumbersome and inefficient, especially when dealing with different authentication flows. The vanilla version should simplify this significantly.

Blood :drop_of_blood:, sweat :sweat_smile:, and tears :sob: has gone into @nfid/identitykit@0.0.5 thanks to all the dev feedback in our Discord!

Here’s what’s new:
:zap: Simplified Auth: Say goodbye to agent setup headaches—use the useAgent hook to streamline authenticated calls (and use your own anonymousAgent to make anonymous ones when needed).
:key: Connect Like a Pro: Use hooks to connect specific signers or CustomConnect via URL!
:computer: Local Internet Identity Support: ii transport now uses the signer URL as the provider URL for local ii—more flexibility for you!
:wrench: Even more advanced customization: New options on the Advanced Options page:

  • allowInternetIdentityPinAuthentication for Internet Identity PIN
  • signerClientOptions.identity to change base identity
  • signerClientOptions.storage to use custom storage

More buidl, fewer headaches! :rocket:

P.S. v1.0.0 in the next 2 weeks :heart_hands:

2 Likes

:rocket: As promised: IdentityKit is now officially v1.0.0! :rocket:

We’re thrilled to announce IdentityKit’s promotion to version 1.0.0, packed with major upgrades for smoother and smarter Web3 interactions across ICP:

:sparkles: Automated Session Handling — Your sessions now auto-expire on delegation timeout, keeping security tight with effortless logouts.

:gear: Enhanced Environment Handling — The isInitialising flag in useIdentityHook() ensures a seamless experience, holding off until your session is fully ready to go.

Tap into the full network effects of a thriving ICP ecosystem with IdentityKit, the tool to break down silos and scale your impact. :globe_with_meridians:

Use NFID Wallet in the IdentityKit Demo App to see all 7(!) of the new wallet standards in action:

  • Connect a delegation for your main wallet address
  • Call a canister to IdentityKit’s Demo canister (no approval prompt)
  • Call icrc2_approve (approval prompt)
  • Call ICP transfer (approval prompt)
1 Like

FYI IdentityKit v1.0.2 released with support for dfinity/agent v2.1.3

1 Like

FYI IdentityKit v1.0.4 released with support for Oisy and PrimeVault

2 Likes