Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API for serializing / deserializing delegations #174

Open
Gozala opened this issue Dec 12, 2022 · 2 comments
Open

API for serializing / deserializing delegations #174

Gozala opened this issue Dec 12, 2022 · 2 comments

Comments

@Gozala
Copy link
Collaborator

Gozala commented Dec 12, 2022

As per #173 (comment) there seems to be a desire for an API that can serialize / de-serialize delegations

@Gozala
Copy link
Collaborator Author

Gozala commented Dec 12, 2022

@alanshaw this has came up in the past with @hugomrdias and my answer was, we can't have fromJSON because:

  1. It's unclear what JSON representation of DAG would look like or how would it deduplicate.
  2. I also worry that one could craft JSON that is invalid delegation and could deceive system into thinking it's valid unless verified.

All in all fromJSON sounds error prone that I don't believe it's worth it.

What we do have instead is

const exportDAG = function* (root, blocks) {
for (const link of decode(root).proofs) {
// Check if block is included in this delegation
const root = /** @type {UCAN.Block} */ (blocks.get(link.toString()))
if (root) {
yield* exportDAG(root, blocks)
}
}
yield root
}

Which is used by transport to serialize delegation into a CAR which can represent DAGs

for (const block of delegation.export()) {
blocks.set(block.cid.toString(), block)
}
blocks.delete(delegation.root.cid.toString())
}
const body = CAR.encode({ roots, blocks })

Only reason there was never toCAR / fromCAR is because I wrote sync car encoder but have not got around to writing sync decoder. However sounds like @hugomrdias got around to doing it, so perhaps he'd be game to integrate it here and add those methods ?

I know CAR isn't a string, but but we have base codec to deal with that.

If we really want a JSON version than I think we need to define CAR like structure in DAG JSON in which case it would become plausible.

@hugomrdias
Copy link
Contributor

yes its this file https://github.com/web3-storage/w3protocol/blob/6abe8c2dcc72a888ce998c6f5d126f6ba3f81c4c/packages/access-client/src/encoding.js

I used base64url for the string encoding.
We should move those to ucanto directly.

Is this enough for your needs @alanshaw ?

if it is we should add this task to the current phase

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants