[vwrap] Inventory, Asset Metadata and Privacy (was: [wvrap] Simulation consistency)

[Boroondas Gupte <[e-mail]>]

Hi Morgaine

The distinction between metadata and 'content' and storing them in
separately acquirable chunks is a good and quite important idea, I
think. More generally, I can think of several reasons to split a
monolithic data entity E into several separate ones, connected by
referencing each other or by being referenced by a common meta-entity
which replaces the previous monolithic entity:

   1. Several other entities are expected to have some parts in common
      with E, without having other parts in common with it.
   2. Some parties only need some parts of E, but not other parts.
   3. Some parties are only allowed access to some parts of E, but not
      to other parts.

(You might note the similarity between reason (1) and rules used for
database normalization.)

If the entities are immutable (which assets should be according to
previous discussion
<http://www.ietf.org/mail-archive/web/vwrap/current/threads.html#00796>), (1)
can not only occur between unrelated items but will also be very common
for items that result from changing a previous item. Some examples how
this applies specifically to the metadata-content separation (assuming a
similar inventory UI as we have in SL):

    * You rez an object from inventory, resize it, and take it back into
      inventory (which creates a new item there).
          o Same metadata (permissions, name(?), owner)
                + (What about a 'last edited' date, though? SL doesn't
                  seem to store one, but some VWRAP systems might want
                  to keep that info.)
          o Different content
    * You rename an item in-inventory
          o Different metadata (maybe ... see below)
          o Same content
    * You change next-owner permissions on an item, then give it to someone
          o Different metadata
          o Same content

Reason (2) off course occurs when browsing your inventory. If you just
want to e.g. read the names of your items, you don't have to fetch all
the associated content data.

Off course, there are more potential separations that fit one or several
of these three reasons than just the metadata-content one. In SL, having
objects being composed of prims, having prims reference textures for
their faces instead of having the texture data lumped into their own
data, or gestures being composed of steps some of which can reference
animation and sound assets are other examples of such separations.

On 04/10/2011 03:11 PM, Morgaine wrote:
> It is worth noting that while inventories are mostly a client-side
> implementation detail which can be changed unilaterally, the
> /metadata/ held by inventories is a very important and separable
> information type in an architecture that uses 3rd party asset
> services, so it needs detailed examination.
>
> The metadata has to be available to remote parties in the same way as
> the data itself is, and the best way of handling this is to make
> metadata a separate item normally stored in the same asset service as
> the data.
As far as I know, this differs slightly from the concepts/architecture
in SL. This might be a good thing, but because it is almost, but not
completely, the same, we should be aware of these differences: In SL,
there are the concept of assets (which are what I called 'content'
above) and the concept of inventory items, referencing these assets and
holding additional information such as permissions, name, etc. These
inventory items themselves however are *not* considered assets in SL.

So far, that's just a difference in nomenclature, I guess. But the SL
inventory items are also handled differently from SL assets: They aren't
stored (and served to the region) by the asset server, like assets are,
but instead by the inventory service, which also serves the inventory
tree. In fact, at least in the viewer's data model, the folders making
up that tree are just special inventory items that do not reference
assets but reference other inventory items.

One of the drawbacks of how SL draws the line between inventory (-items)
and assets is that it's probably difficult to implement something like
VWR-2427 <https://jira.secondlife.com/browse/VWR-2427>. Treating the
item-metadata as a type of assets as you seem to suggest might allow to
better exploit the commonality that both inventory items and some data
assets can refer to other assets.

(Note that I'm not really an expert on SL's internal architecture, and
most of the above is based on hear-say and some viewer code comments I
remember. Please correct me if I'm wrong somewhere.)

> The metadata item will naturally reference the corresponding data item
> (which is an N:1 relationship when hash-based addressing is used), and
> in some cases can reference more than one data item --- for example,
> the metadata of a mesh will commonly reference not only the graphical
> data required for rendering in the client but also the collision mesh
> or bounding box data required by the region.
Wouldn't it make more sense to keep the metadata-item-to-data-item
relation strictly N:1, and have the mesh data item have a N:N relation
to it's components? (Analogous to SL gestures.) While the item type
should be part of the metadata, I don't think the metadata's structure
should depend on the item type. After all, the structure of inodes of a
file system also doesn't depend on the file formats of the referenced files.

> These two types of data are separate because it would be inefficient
> to require clients or regions to download data that they do not use. 
> Our "asset" singleton now turns into a metadata + data pair.
Yep.

> As a final point about metadata versus data, it should be mentioned
> that generally only the data ever has access restrictions placed on it,
No restrictions for whom? Just for the user whose inventory it is (but
then he/she has to authenticate somehow) or no restrictions for anyone?

> because placing restrictions on metadata leads to unsearchable
> inventories for which the technical term is "annoying as hell", or
> more seriously, poorly functionality and yet another source of lag.
I agree everyone should be able to access their own inventory tree,
including the item-metadata at its leaf nodes. For the tree part, you
later write
> Regions don't have access to your inventory [...]
("inventory" here refers to just the tree, if I understood you
correctly). I guess this is also the case for other users, except where
I have given them explicit permission to view parts of my inventory (if
the protocol was capable of that).

> I am going to assume that nobody wants that [poor functionality and
> lag] and hence, that metadata is never accessed through capabilities.
Now here I'm beginning to wonder, what data all is part of the tree
(that others aren't able to access) and what is instead part of the
item-metadata, (a fraction of) which needs to be broadcasted to other
users, as it contains the references to the assets those other users
have to fetch to render my avatar correctly. For example, is the item
name part of that metadata or part of the tree? It obviously isn't
needed by others, it's merely a reminder for myself of what that item is.

If the item name for worn stuff /is/ broadcasted together with the other
relevant metadata, that's OK as long as the user is aware of it, but it
/does/ have some consequences: In that case, I probably wouldn't want to
name a wearable "The dress that this stupid guy bought me, but that I
like to wear anyway" or "Those shoes that my secret lover Example
Resident gave me" but something more innocent, so that I wouldn't upset
that other user and wouldn't leak that Example Resident was my secret lover.

There might be other metadata that's useful to the users themselves but
that they might want to withhold from region owners and other users.
Imagine for example information about where and when you acquired an
item, which allows you to efficiently search for that item when you
forgot the item name but still remember how you got it. However, if that
info is broadcasted for worn items and you wear enough different items,
everyone around you has a partial trace of your virtual travels.

So we can either split the metadata asset according to reason (3) above
into several assets with different access policies. Or we just lump
metadata we want to keep private together with the tree while only
having metadata we don't mind sharing in the metadata assets.

Cheers,
Boroondas