refactor!: access-client store decoupling

[alanshaw]

Goals:

1. Decouple store from agent
2. Simplify agent creation
3. Agent governs data format not store
4. Initialization of agent data, not store
5. DRY initialization in agent, not repeated in each store impl

See: https://gist.github.com/alanshaw/ea4bd2b0ab215ade696eac1300be577d outdated

// In regular use:
const store = new StoreIndexedDB()
const data = await store.load()
const agent = data
  ? Agent.from(data, { store })
  : await Agent.create({}, { store })

// Then StoreMemory can be deleted, since the AgentData already stores all data in
// memory. It's equivalent to:
const agent = await Agent.create()

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	f412a45
Status:	✅  Deploy successful!
Preview URL:	https://437468a4.ucan-protocol.pages.dev
Branch Preview URL:	https://refactor-access-client.ucan-protocol.pages.dev

View logs

[gobengo]

fyi I made a draft PR that you may wanna merge into this one and it might help a little bit with resolving conflicts with main
#244

[hugomrdias]

in general looks good but now the user needs to choose store driver plus signer type maybe we can find a easier solution

[hugomrdias]

who knows which signer to use for the agent principal ? With the current code its always ed but browser need rsa

[alanshaw]

Right now, w3up-client/w3ui would choose RSA. I don't think the store implementation should choose. You can put Ed25519 keys in IndexedDB. It's the environment/application that should choose this.

We should create an agent-data.browser.js which just imports agent-data.js and overrides though.

[hugomrdias]

if we dont have a method to test if the store was initialized do we always call this method ? if yes we gonna need to always pass on a Signer just in case its empty ?

[alanshaw]

if we dont have a method to test if the store was initialized do we always call this method ?

Yes, this is probably what you use 99% of the time. Essentially store.load() is the init check (which is what is happening above).

if yes we gonna need to always pass on a Signer just in case its empty ?

No because AgentData.create generates one for you. I understand that's not great if you want to use a different key type from what AgentData gives you by default...and in that situation you'd either always pass it (as you say), or do what this method is doing in your application code. I don't know how to make that a better experience other than picking a better default in the browser.

[hugomrdias]

can we make the store.load() do store.open() ?

[hugomrdias]

humm so user needs to know about:

• Agent
• AgentData
• StoreDriver
• Signer

We can leave Signer in the options for flexibility, but right now BrowserDriver kinda requires RSASigner.

can we reduce this to:

• Agent
• Driver
• Signer (this would be optional, either from the driver or from the user overriding the driver)

Most uses would just need Agent and Driver, i think we can do this by just hiding AgentData inside Agent.

[hugomrdias]

const data = driver.load()

if(data) {
  agent.from(data, driver)
}else{
  agent.create(driver, { 
    principal: await EdSigner.generate() // if we want to overriding Driver.generatePrincipal() 
  })
}

something like this ?

[alanshaw]

can we make the store.load() do store.open() ?

Yes? Just that one? What about .save()? I'm not sure on the utility of it - users shouldn't need to do it. A separate PR perhaps?

[alanshaw]

const data = driver.load()

if(data) {
  agent.from(data, driver)
}else{
  agent.create(driver, { 
    principal: await EdSigner.generate() // if we want to overriding Driver.generatePrincipal() 
  })
}

something like this ?

yes we can do that

[hugomrdias]

LGTM, left one inline comment.

Maybe we could change the naming store to driver and hardcode the data type instead of using generics. Avoid having /** @type {StoreConf<import('../types').AgentDataExport>} */ everywhere. These two are non blocking feel free to ignore.

[hugomrdias]

LGTM, love it much better