EIP-5573: SIWE ReCap

Crossposting Irakli’s response and suggestion: Multiple "can" for a "with" · Issue #123 · ucan-wg/spec · GitHub

An approach like this would be interesting and it solves for the merge approach you outlined above.


I think his suggestion also makes sense for ReCap:

Schema:

{
  $RESOURCE: {
    $ABILITY: $EXTENSION,
    ...
  },
  ...
  "prf": [&Link] // OCAP delegations
}

Example:

{
  "example://example.com/public/photos/": {
      "crud/delete": {}
  },
  "example://example.com/private/84MZ7aqwKn7sNiMGsSbaxsEa6EPnQLoKYbXByxNBrCEr": {
      "wnfs/append": {}
  },
  "example://example.com/public/documents/": {
    "crud/delete": {
      "matching": "/(?i)(\W|^)(baloney|darn|drat|fooey|gosh\sdarnit|heck)(\W|$)/" 
    }
  },
  "mailto:username@example.com": {
    "msg/send": {},
    "msg/receive": {
      "max_count": 5,
      "templates": ["newsletter", "marketing"]
    }
  }
}
1 Like

Unfortunately, it actually causes the merge problem above. [UPDATE @oed was talking the OTHER merge case. Sorry, entirely my bad :sweat_smile: The bit below is still useful I think]

Repeating here for the group/discussion here: duplicate key handling is under-specified in the JSON spec, and thus different libraries handle them differently:

From RFC 8259:

When the names within an object are not
unique, the behavior of software that receives such an object is
unpredictable. Many implementations report the last name/value pair
only. Other implementations report an error or fail to parse the object,
and some implementations report all of the name/value pairs,
including duplicates.

JSON parsing libraries have been observed to differ as to whether or
not they make the ordering of object members visible to calling
software. Implementations whose behavior does not depend on member
ordering will be interoperable in the sense that they will not be
affected by these differences.

However, we could solve this by wrapping it in an array. Adapting your example above:

[
  {
    "example://example.com/public/photos/": {
        "crud/delete": {}
  },
  {
    "example://example.com/private/84MZ7aqwKn7sNiMGsSbaxsEa6EPnQLoKYbXByxNBrCEr": {
      "wnfs/append": {}
  },
  {
    "example://example.com/public/documents/": {
      "crud/delete": {
        "matching": "/(?i)(\W|^)(baloney|darn|drat|fooey|gosh\sdarnit|heck)(\W|$)/" 
      }
    }
  },
  {
    "mailto:username@example.com": {
      "msg/send": {},
      "msg/receive": {
        "max_count": 5,
        "templates": ["newsletter", "marketing"]
      }
    }
  }
]

This adds two characters (the enclosing {}s) per capability, but makes it compatible with all parsers.

Ah! But agreed @oed that it solves the other case, on extensional fields! Sorry, so many kinds of merge happening there :stuck_out_tongue: :sweat_smile:

Will mention what I said in the other thread as well. I think it would be easier to solve the merge problem by simply not allowing duplicate resource keys?

That’s a change we could make, yeah. It does mean that there’s more things that people can mess up in an implementation, and it’s not a problem that we have in the existing version of UCAN. Not forcing this eliminates a Byzantine (buggy not malicious) case.

1 Like

Here’s my suggestion for how to update ReCap with the same structure as what is currently suggested for UCAN.

This looks really good to me! :tada: :clap:

We’ve updated the UCAN 0.10 WIP PR to use the above syntax :rocket:

1 Like