feat: new session keys with viem

[hugomrdias]

• still needs wiring in react and sdk
• proper e2e testing

Example usage:

import * as SessionKey from '@filoz/synapse-core/session-key'
import { privateKeyToAccount } from 'viem/accounts'
import { type Hex } from 'viem'
import { mainnet } from '@filoz/synapse-core/chains'

const rootAccount = privateKeyToAccount('0xaa14e25eaea762df1533e72394b85e56dd0c7aa61cf6df3b1f13a842ca0361e5' as Hex)

const sessionKey = SessionKey.fromSecp256k1({
  privateKey: '0xaa14e25eaea762df1533e72394b85e56dd0c7aa61cf6df3b1f13a842ca0361e5' as Hex,
  root: rootAccount,
  chain: mainnet,
})
sessionKey.on('expirationsUpdated', (e) => {console.log(e.detail)})
sessionKey.on('connected', (e) => {console.log(e.detail)})
sessionKey.on('disconnected', () => {console.log('disconnected')})
sessionKey.on('error', (e) => {console.log(e.detail)})


const { event: loginEvent } = await SessionKey.loginSync(client, {
  address: sessionKey.address,
  onHash(hash) {
    console.log(`Waiting for tx ${hash} to be mined...`)
  },
})

console.log('event login:', loginEvent.args)

await sessionKey.connect()

if(sessionKey.hasPermission(SessionKey.CreateDataSetPermission)) {
  const hash = await createDataSet(sessionKey.client, {
    payee: '0x1234567890123456789012345678901234567890',
    payer: sessionKey.rootAddress,
    serviceURL: 'https://example.com',
  })
  console.log('event created dataset:', hash)
}

const { event: revokeEvent } = await SessionKey.revokeSync(client, {
  address: sessionKey.address,
  onHash(hash) {
    console.log(`Waiting for tx ${hash} to be mined...`)
  },
})
console.log('event revoked:', revokeEvent.args)
sessionKey.disconnect()

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	synapse-dev	7fdc04d	Commit Preview URL Branch Preview URL	Feb 25 2026, 11:59 AM

[rvagg]

and if it fails and doesn't even get here?

[hugomrdias]

What do you mean? it will throw an error. User still gets the connected event if syncExpirations doesnt fail.

[rvagg]

I mean watchContractEvent, not a big deal but this is lost here: https://v1.viem.sh/docs/contract/watchContractEvent.html#onerror-optional

[rvagg]

This might be a good opportunity to deal with type SessionKeyPermissions being a closed union and ALL_PERMISSIONS being a bit misleading in its name. This came up this week in filecoin-project/curio#1028, noting that (a) SessionKeyRegistry doesn't care what these strings are, it's not exclusive, and (b) DeleteDataSet isn't even standard anymore, it's gone, so our existing set isn't even accurate (but as per that issue we're talking about repurposing it to do Client<>Curio auth, not touching FWSS).

Perhaps:

• ALL_PERMISSIONS -> FWSS_PERMISSIONS
• EMPTY_PERMISSIONS has the same problem
• Make SessionKeyPermissions open, or rename it to FWSSPermissions and do a type SessionKeyPermission = FWSSPermissions | Hex.
• login(), revoke() should expand their permissions? as per above.
• getExpirations() and hasPermission() is harder, but we could clearly document that they are dealing specifically with FWSS only

Not a blocker, but the current session key code gives the impression this is all canonical and a closed set of permissions. But developers should be able to use the registry to do non-FWSS things and having an SDK that makes that easy would be nice.

[rvagg]

Will I be able to pass sessionKey.client to the SDK in the end of this? For the signing operations, will we need to update them to differentiate between a SessionKeyAccount client and a standard one so we can pick out rootAddress when it exists?

[hugomrdias]

Will I be able to pass sessionKey.client to the SDK in the end of this? For the signing operations, will we need to update them to differentiate between a SessionKeyAccount client and a standard one so we can pick out rootAddress when it exists?

Yeah not sure yet, because session keys only works for those 4 mutations (maybe just 3 if delete dataset is gone), some of the other services do other mutations that need the root client.

I think for now I'm just adding a new constructor option to pass a session keys and internally use if available and has permission.

There's one subtle thing in this design, that I want your opinion.

The connect/disconnect are actually optional, they are there if you want realtime tracking of the permissions, if you don't you can just pass whatever expirations you got from login and YOLO the mutations.

I will be cleaning up with your comments and finish testing hopefully sps work today.

[rvagg]

you can just pass whatever expirations you got from login and YOLO the mutations

Pass to where? I don't think we care in any of the places we use it, so this isn't an internal concern. I think the answer here is to just document how expirations work and for long-lived session key instances advise that the developer should be sure to refresh expiries occasionally to be sure to perform login() as needed. Otherwise, not our problem (except for the fact that errors arising from expired permissions will be opaque about the cause!).

[hugomrdias]

you can just pass whatever expirations you got from login and YOLO the mutations

Pass to where? I don't think we care in any of the places we use it, so this isn't an internal concern. I think the answer here is to just document how expirations work and for long-lived session key instances advise that the developer should be sure to refresh expiries occasionally to be sure to perform login() as needed. Otherwise, not our problem (except for the fact that errors arising from expired permissions will be opaque about the cause!).

to fromSecp256k1 and the SessionKey instance will have whatever expirations you want, if you dont connect nor syncExpirations it will just use the initial ones.

but if you want to track expirations and get events to logout user or something you can.

[rvagg]

With some suggestions, and some slightly more firm requests which are probably: missing onError handling, unless you want to defend not doing that? The Synapse.create could do with some attention while you're at it. I also wouldn't mind hearing more justification on connect() / disconnect() being in core and not a react specialty (I'm imagining "there are other long-running uses out there" .. but .. really, it's pretty much only going to be React right?).

I'm going to follow up with a docs PR to this.