[tahoe-dev] [tahoe-lafs] #956: embed security metadata in parent directory

David-Sarah Hopwood david-sarah at jacaranda.org
Tue Feb 16 21:05:24 UTC 2010

James A. Donald wrote:
> tahoe-lafs wrote:
>  > #956: embed security metadata in parent directory
>  >
>  >  There is going to be a compatibility problem with doing this, since
>  >  we don't (as far as I can see) have anywhere in the directory
>  >  format to encode new fields that will be ignored by old clients.
>  >  This will also be a problem with several other proposed features,
>  >  including deep-verify caps as described in #308, and extensible
>  >  directories suggested as part of #959.
> The COM approach to addressing this type of problem is that the client
> should never see the raw data of a structured object, rather a presentation
> of that data, and the presentation depends on the negotiated interface, so
> older clients see an older presentation.

In Tahoe the webapi clients don't ever see the directory format (they do
see JSON-based formats, but those are extensible).

The storage clients do see the raw data format of a directory, and that's
inevitable: there is no other component that would be able to translate
the directory contents for them and that would be easier to upgrade.

In any case, I was mistaken in saying that there is nowhere in the
directory format to encode new fields. As Brian pointed out in the next
comment, there is the JSON-encoded metadata. That wouldn't be sufficient
to support deep-verify caps (because the metadata is encrypted with the
read key and the verify slots shouldn't be), but it is probably sufficient
for the use case in #956.

David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100216/71797826/attachment.asc>

More information about the tahoe-dev mailing list