feat: initialize new package for signers

[avasisht23]

Pull Request Checklist

• Did you add new tests and confirm existing tests pass? (yarn test)
• Did you update relevant docs? (docs are found in the site folder, see guidleines below)
• Do your commits follow the Conventional Commits standard?
• Does your PR title also follow the Conventional Commits standard?
• If you have a breaking change, is it [correctly reflected in your commit message](https://www.conventionalcommits.org/en/v1.0.0/#examples? (e.g. feat!: breaking change)
• Did you run lint (yarn lint:check) and fix any issues? (yarn lint:fix)
• Is the base branch you're merging into development and not main?

[avasisht23]

Current dependencies on/for this PR:

• development
  • PR feat: initialize new package for signers #1 👈

This stack of pull requests is managed by Graphite.

[socket-security]

Updated dependencies detected. Learn more about Socket for GitHub ↗︎

Packages	Version	New capabilities	Transitives	Size	Publisher
viem	1.17.2...1.18.8	None	+0/-0	5.63 MB	jmoxey

[moldy530]

any reason not to just do this directly in the aa-sdk? we could even have a branch called aa-signers if we want to stage changes further?

[moldy530]

let's drop this

[avasisht23]

id + details, or just details?

[moldy530]

just details, since we have a getDetails method

[moldy530]

I wonder if this should live in aa-core still. if this is here, then devs will ALWAYS need to install aa-signers which shouldn't be a requirement if devs want to bring their own in the end

[avasisht23]

hmm good point. that makes sense.

[avasisht23]

this is actually more in line with how we did accounts

[avasisht23]

any reason not to just do this directly in the aa-sdk? we could even have a branch called aa-signers if we want to stage changes further?

chatted live yesterday in sync: https://alchemyinsights.slack.com/archives/C04RHSDSP9U/p1699297061008119?thread_ts=1699074100.738799&cid=C04RHSDSP9U

tl;dr: this is a breaking change and requires 3rd party contributions. ideally this all gets in before merging to development. as we build out with turnkey/magic/lit, we don't want to hint to the other signers that we're partnering with them by having their impls in first.

that said, we could just merge in our own impls using the docs and then reach out to signers after to tweak. is that what you mean?

[moldy530]

Yea that's fine if we don't want to merge it into the development branch because it's a breaking change. Let's create a new branch called aa-signer in the main repo and use that as the base branch for all this dev. it'll be easier to track changes and get contributions

[denniswon]

Is the notion of User ”ALWAYS” relevant for signer?

Then what about Local signers, Wallet Signers?

I think we should align on the goal of having a separate aa-signer package.

In my opinion, it should be:

1. signer type for telemetry should not rely on arbitrary strings
2. there should be more dedicated process/place for 3rd party partners/signers to integrate with aa-sdk

[avasisht23]

Is the notion of User ”ALWAYS” relevant for signer?

agreed, it's not. as I've been playing with integrating magic, I've realized this. let's discuss tomorrow.

right now I have something like this in aa-core/signer/types.ts to account for distinction between AuthSigner and Signer:

import type { Hash, Hex } from "viem";
import type { SignTypedDataParams } from "../account/types.js";

export interface AuthSmartAccountSigner<Inner, AuthParams, UserDetails>
  extends SmartAccountSigner {
  inner: Inner;
  user: SmartAccountUser<UserDetails> | undefined;

  authenticateUser: (params: AuthParams) => Promise<UserDetails>;

  getUserDetails: () => Promise<UserDetails>;
}

export interface SmartAccountSigner {
  signerType: string;

  getAddress: () => Promise<Hash>;

  signMessage: (msg: Uint8Array | Hex | string) => Promise<Hex>;

  signTypedData: (params: SignTypedDataParams) => Promise<Hex>;
}

export interface SmartAccountUser<UserDetails> {
  id: string | undefined;

  isAuthenticated: () => Promise<boolean>;

  getDetails: () => Promise<UserDetails>;
}