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

fix!: attach ipld view instead of single block #303

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

vasco-santos
Copy link
Member

Attach view instead of single block per #298 (comment)

BREAKING CHANGE: delegation.attach() and invocation.attach() now receive IPLDView instead of Block

BREAKING CHANGE: delegation.attach() and invocation.attach() now receive IPLDView instead of Block
@vasco-santos vasco-santos added this to the w3up phase 4 milestone May 2, 2023
@vasco-santos vasco-santos requested a review from Gozala May 2, 2023 12:45
Copy link
Collaborator

@Gozala Gozala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for tackling this. Unfortunately I'm no longer sure this is a good idea and maybe leaving it at the block level now is a better option. This is why

  • Right now capabilities & facts are not fully traversed implying that after transporting the delegation (transitive) nodes, linked from the attachment will be lost, unless they were explicitly linked from the capability.nb or facts.
    • Although attach right now throws if transitive blocks aren't linked, but then it's not clear to me if there is any benefit to just allowing only a block.

What I was picturing when suggesting this was that capabilities and facts would only link to the attachment roots. That however would require deep traversal of the capabilities and facts as opposed to shallow one implemented now.

In other words I think we should either do full traversal, otherwise this going to be more error prone than helpful. However I could be missing something so maybe we can talk sync about this.

attach(view) {
for (const block of view.iterateIPLDBlocks()) {
if (!this.attachedLinks.has(`${block.cid.link()}`)) {
throw new Error(`given block with ${block.cid} is not an attached link`)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think should only require that root is listed in the attachments, all the other blocks will be linked somewhere from that root.

for (const block of attachedBlocks.values()) {
delegation.attach(block)
}
const attached = Array.from(attachedBlocks.values())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find this very confusing, can we have attachments iterable as an argument instead ? That way we'll simply:

for (const view of attachments) {
  delegation.attach(view)
}

attach(block) {
this.attachedBlocks.set(`${block.cid}`, block)
attach(view) {
for (const block of view.iterateIPLDBlocks()) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be a lot cleaner if we stick blocks into this.blocks and instead have a set of links to the attachment roots.

@vasco-santos
Copy link
Member Author

@Gozala we are now doing full traversal of capabilities. Also checking facts as an entry in array, or value of an object. I guess, we only then need to do a full traversal of facts?

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

Successfully merging this pull request may close these issues.

None yet

2 participants