[vwrap] Is 'Data Z' immutable (like a git snapshot)?

[Carlo Wood <[e-mail]>]

This is very nice work and I think it clarifies a lot.

I have a few very basic questions.

I see that you request Z from two different Asset servers
(originally A, but also C when a backup has been stored there).

No matter how you look at it, that is distributed storage:
compare it with git or mercurial; if Z on A could be changed
then the backup would be out dated, and that is not what
we want. So, I conclude that 'Z' (or rather, then handle
used to refer to Z when asking for it) therefore refers to
a unmodifiable data (compare git's hex ID's that point to
a snapshot).

1) Is that correct?

If it is correct and the handle for Z used in messages
like "give me a cap for Z" refer to immutable data, then
the most logical thing to do would be to use a (large)
hash value of the data (ie, md5) or an UUID that was
generated when the data was last changed (which is less
good because it would cause duplicated data when something
is changed back to what it was before), or to use an
ID that is less large, but whose uniqueness would be
guaranteed by including a (for that authority unique) ID
of the authority that made the last change. The advantage
of the latter is less bandwidth (smaller ID's) and knowledge
of the authority right into the ID of something (handy
for routing). Disadvantages are: it suffers from the same
as the UUID in that it will duplicate data whenever the
same data is generated and it requires administration to
make sure that every authority has a unique ID (compare
giving people unique IP addresses).

2) Which of those is used? has, UUID or smaller specially
crafted ID?

3) What would happen if someone gets a cap for Z, a
modifiable object; then the object is modified and then
the cap is used? Does the cap have a guaranteed life time?

4) If not every previous state of an object is kept
eternally and after changing some object old caps (and
their static data) disappear - then how will the asset
servers that contain copies know that? They are not
necessarily aware that anything changed at all for
that object, so they can't know what the life time
is. It seems that once you make a copy you are doomed
to keep it forever or do garbage collection for assets
that are never accessed anymore.

5) I can image that at SOME TIME in the future we want
a few bit (or more) that ARE mutable-- despite that the
asset ID (Z) refers to snapshot (immutable) data.
Are we going to build into the protocol a provision for
such mutable bits?

This would mean, in the case that the ID is a hash (ie md5)
that the asset Data exists of a payload that the hash is
taken over plus a mutable part that is not considered for
the hash. Obviously, such data then could get desynced
between assets servers with copies.

-- 
Carlo Wood <[e-mail]>