ts-odd
ts-odd copied to clipboard
oddsdk
Pointilistic Private Partition UCAN Capabilities
We have this written in detail... somewhere. I'll dig it up. In the meantime:
Currently UCANs include the entire bare namefilter. This is both space inefficient, and leaks more information than it strictly needs to. We're doubling the size of namefilters (#312) to solve related challenges, but that makes the space problem worse.
The optimization is to list only the hash of the current highest directory that you're given access to. This operates recursively, so if the parent UCAN has hash A, and the child UCAN has hash B, then you must have both in the filter. This moves us from a straight line bare namefilter to a pointalistic view.
Multiple hashes may eventually be required per layer (ANDed), but the belief right now is that it won't be necessary, so putting that off.
Hashes? I thought those would be the inumbers from the spec?
What do you mean by hashes? The hashes of AES keys used to encrypt? IS this pre-2048bit namefilters & inumbers or post?
Currently UCANs include the entire bare namefilter.
I think that's not the case right now:
These are the 3 UCANs from my drive.fission.codes.
Apparently, fct: []. Perhaps that's a bug?
Hashes? I thought those would be the inumbers from the spec?
Ah I could have been a LOT clearer: hashes of i-numbers in the filter (the set bits)
Multiple hashes may eventually be required per layer (ANDed), but the belief right now is that it won't be necessary, so putting that off.
To also clarify this part: if you want to turn these points into more of a line, you can add multiple i-numbers in an array to say "must include ALL of the following", rather than the one at the current level and multiple from the UCAN proof chain. Thinking pictorially, this can be done to make the points more "line-like" if you need the extra specificity.
As mentioned in the original post, I think this falls into the "interesting future direction" bucket. It doesn't block getting the first bit set up and there's a possibility of YAGNI
Apparently, fct: []. Perhaps that's a bug?
fct: [] can be omitted, but it's not a semantic bug I guess
Apparently, fct: []. Perhaps that's a bug?
fct: [] can be omitted, but it's not a semantic bug I guess
Hm. I'm trying to understand what the system should look like. Above you say
Currently UCANs include the entire bare namefilter
But I can't find where that bare namefilter is in my ucans. I thought it should be in the fct field, and I thought, maybe it's a bug that it's not in there?
