Sirikata asset handling code in library form?

[Ryan McDougall]

Right now we are thinking of doing work on our asset handing code for
this sprint. We have some basics, which work for now, but they're very
rudimentary.

We are using Ogre materials, as Sirikata is, but I suspect that asset
downloading and metadata validation is a solved problem (on the face
of it) regardless of format, and we should be sharing code here.

If the Sirikata guys are able to refactor their code into a reusable
library that is not too Ogre-centric, it may be useful for others
here.

Short of that, an Ogre-centric library would be useful. I could have
my guys look at what can be integrated into our system. Then there
might be some feedback about what we did or didn't like.

Short of that, any help Sirikata guys could give in pointing out how
their code works would be a help as we evaluate the code from a
distance.

Cheers,

[Patrick Horn]

Hi all,

To get the discussion going, I'll first start by talking about the
'transfer' library in libcore, which handles memory/disk caching,
protocol handlers, and a high-level TransferManager class.

I'm hoping that not much of this is sirikata specific -- Based on this
page, I think some of these ideas can be reused in other platforms:
http://wiki.realxtend.org/index.php/Asset_Distribution:_Cable_Beach

My hope is for the library to be as reusable as possible, and to ideally
use standards at the protocol level so as to make assets compatible
between basically all virtual world clients even if they are unable to
share code.

The way the asset/cdn library works is by requesting "service" URIs,
which are either filenames (meerkat:///somemeshfile.mesh) or SHA-256
hash references (hash:///0123...). (The code currently assumes sha256,
but this should probably be made more flexible) This distinction is
like the difference between an "Asset server" and an "Asset storage".

Basically, these "service" URIs map to any number of real URIs (http:,
file:, and not implemented yet, s3: or bittorrent:) based on rules set
by the client (and ideally the current space server could suggest some
as well). In order to download an asset, it can try all of the URIs that
are supposed to work, possibly in order of some preference.

One things that I have not thought much about is metadata, but I have
been thinking that it should perhaps be handled by the asset server
itself, and not necessarily provided by clients. If we do use metadata,
I'm thinking that it should be strictly for optional information that is
not required to download the content.


Now the other piece to this asset library is in
liboh/plugins/ogre/resourceManager. Unfortunately this was the piece
that had been borrowed from the old codebase due to time constraints,
and it is harder to separate from the Ogre engine. It uses the transfer
library to handle the low-level downloads, and it also covers some other
things such as tracking the amount of memory being used on the graphics
card itself. It is also responsible for finding dependencies and
providing the assets to ogre in the form of a Ogre::DataStream.
Splitting out the Ogre bits will need to happen at some point anyway
because the physics simulation will need a way to download meshes
without Ogre.

There are also some other important pieces that we do not cover quite
yet. One simple thing is to provide LODs for textures (a lot of our
assets are 2048x2048 or 4096x4096 and wreak havoc on my laptop). For DDS
this is simple: get the header, and seek to the byte position with the
highest mipmap you want. For JPEG it involves streaming the download
until you have the right detail level, then scaling the uncompressed
texture. As for meshes and shaders, this problem might be more
difficult--some graphics cards might not properly handle shaders, so
there needs to be a way to revert to a simpler shader if necessary.


Another thing that the asset library does not cover is handling
content-types, because it was written long before COLLADA entered the
discussion. For HTTP, this is probably simpler to solve by using the
"Accept:" header with the mime-types that you know how to parse (usually
ogre and collada). However, what do you do about hash-references?

My opinion on this front is to disallow hash references altogether, and
allow instead some form of datestamp, for example using ISO-8601:
mymeshfile.mesh@2009-06-09T22:06:28Z would return mymeshfile as it was
at that time, without having to resort to a format-specific and
metadata-lacking hash URI. However, then we will probably need to
propose some sort of standard, and this would likely require some sort
of webserver module to work, unless we require the dates to be exactly
correct, in which case they would make more sense as 'revision numbers'.

This is simply my current re/vision of how an asset service would look.
Not all of this is implemented yet, and I am open to opinions on any of
what I have said.


Also, as for the details of the sirikata code, I'm definitely willing to
discuss in more depth on IRC or the platformtalk list.

-Patrick

[Alon Zakai]

It sounds like it might be too late to propose your using the
Intensity Engine asset system, but I'll briefly detail it here.
(Note that, as with much of the Intensity Engine code, it is
AGPL licensed, but if there is a desire to share code I can
dual-license it under the Apache 2.0).

The Intensity Engine asset system is written in Python
(for portability, ease of development, and because this is not
speed-intensive code). It is fairly minimalistic and engine-
agnostic. Some of the features it was designed to have are
mutability and dependencies, which are important for us. For
similar reasons it stresses simplicity over streaming
performance.

The basic workflow is as follows:

1. A machine (client *or* server) decides it wants to access
an asset with a particular AssetID. The AssetID includes
information as to which metadata server manages this
asset (multiple such servers are possible, i.e., federation).
2. It queries the metadata server, which responds with
the metadata, namely, the (http) URL to get the asset
from, a hash value (and type), a list of dependencies
(also AssetIDs), and some other stuff. The metadata
server can also check if the user is allowed to access that
asset.
3, The machine acquires all dependent assets, using
this same process, recursively from 1.
4. The machine tests the hash value based on the locally
cached asset, if existing, and if necessary downloads it
using standard HTTP.
5. The asset is used.

Uploading an asset follows a similar path, but the asset
server queries the metadata server for whether the
user is allowed to update the asset (assets can have
multiple owners). Uploading is possible from within
the client, or using a web interface.

Basically, the metadata server and asset servers
themselves are simple HTTP servers, reusing existing
web technology. (And both of these are separate
from the server instances, what are called
simulators in Second Life/OpenSim. A 'domain'
consists of one metadata server, one or more
asset servers, and one or more server instances.)

This system is currently being used in the Intensity
Engine. Some features remain to be implemented
like OpenID authentication, but in general the goal is
to keep the core asset system as described above,
i.e., quite simple and to the point. Integration with
particular engines is kept separate, for modularity.

Best,
Alon Zakai / kripken

[Craig Presti]

Hello all,

Following on from what Patrick has mentioned regarding asset metadata, I'd
like to introduce a specification we've been using as the foundation for
VastPark over the past couple of years called Metaforik.

It's an open specification around metadata for representing a unit of
content as a concept (an 'Item'). Each Item can be linked to an unlimited
number of concrete content types (each an 'Asset'). Each asset has a Source
attribute that points to the file for that asset.

Here's a quick example of a simple Metaforik Item:

<Metaforik xmlns="http://schemas.vastpark.com/2009/Metaforik/">
<Item Name="MyAwesomeNewSong "Publisher="bert"
PublisherGroup="group1@vastpark">
<Description>My music track</Description>
<Asset Source="http://example.com/fullversion_song.mp3" Type="Sound"
TargetDevice="All" Culture="en-au">
<Permissions>
<Whitelist Context="Document" Scope="Group" Value="group1"/>
</Permissions>
</Asset>

<Asset Source="http://example.com/preview_song.mp3" Type="Sound"
TargetDevice="All" Culture="en-au" />

</Item>
</Metaforik>

This metadata is describing one concept (a song called 'MyAwesomeNewSong')
and has 2 assets, one a preview version for users who aren't members of the
group group1@vastpark and the full version for users who are members. There
are quite a number of optional attributes not shown in the above example for
simplicity. The xsd is available as part of the VastPark dev documents here:
http://www.vastpark.com/for_developers

This may seem a little untoward, but the benefit is that somewhere (in our
case, inside our scene markup specification, IMML) you can reference the
Item once in a description of the current scene and the responsibility can
be shifted to the client to request the Asset that best suits it (ie: In
Patrick's shader scenario). In VastPark we webservice the Item XML back, so
in the above scenario, the client will not receive the XML for the first
asset unless the logged in user is a member of that group.

Cheers,
Craig

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4140 (20090609) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4140 (20090609) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4142 (20090609) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4142 (20090609) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[Ryan McDougall]

My approach to asset handling has allows assumed a separation of concerns:

- publisher-app takes locally addressed (local file names) set of
assets and their artist-declared dependencies, and uploads the set
into an asset service upload web service, as well as computed
meta-data. the publisher-app automatically generates discrete LoD, and
includes instructions within the meta-data on how to understand and
retrieve Lodded copies.

- upload web service verifies authorization of publisher, and accepts
assets and meta-data -- additional meta-data may also be added by the
web service itself

- simulator acts as a client in retrieving asset dependency
information for the purpose of distribution to attached clients

- simulator only informs interested parties of attached assets using a
globally addressable URI, and no more

- client-logic queries associated meta-data for the asset, computes a
dependency set from meta-data, and hands the set to a downloader

- client-downloader uses the URI scheme to discover how to retrieve
the set, issuing a callback when completed

That is the artist and his special publisher app are entirely
responsible for dependency encoding. Simulator just informs clients
which assets are attached to the scene objects. Asset service merely
holds data and meta-data. The client-logic is responsible for deciding
what to get, and client-downloader just gets it using only the
information within the URI.

I am not quite clear on the need for "service URI" -> "real URI"
mapping. It would seem that service URI encodes some logical decision
about how to get the data made by client-logic (get it from a local
file), or layer of indirection used to avoid hard-coding CDN topology
within the URI.

However I think the URI must be treated as opaque as much as possible.
It was the content creator's policy decision how to submit his content
to the network, and that should be respected by following the URI he
submitted. The only room for decision-making is within the options
provided explicitly within the meta-data.

Since Lodding means different things for different MIME-types,
client-logic would need some sort of understanding about LoD
strategies for each possible MIME-type available.

Lastly, I am not sure I follow the point about disallowing hash
references. Can you elaborate a bit?

Cheers,

[Ryan McDougall]

Click too fast... :(

The content creator is making his work available to others under an
*explicit* set of conditions. The policy that content creator chooses
for the dissemination of his work may be copyright or left, it may
include DRM or it may state it is X-rated material -- but it must be
made explicit somewhere, and meta-data is that somewhere.

Moreover, the person best suited to know about dependencies or LoDs or
any other conditions that may be placed on the content is the content
creator. Having any intermediate step attempt to out-guess that person
will always have corner cases at best. Better just to write them down
during an explicit publish step and respect them, IMO.

Cheers,

[Ryan McDougall]

Yes, and Metaforik is another way of expressing the same idea Ogre
resource (materials, particle, etc) are: "this is a conceptual unit,
and everything within me goes together".

Making things more practical, I don't think we want put Ogre materials
in Metaforik or vice versa, but instead have an explicit "unpack" step
in any API that reads the MIME-type, determines that the asset is
really a container format, parses the container format, and
recursively retrieves contained items.

Container formats play very well with both content creators and
content creation tools.

Cheers,

[Patrick Horn]

With the code, it's not always a bad thing to have multiple
implementations for this.
It will always be a possibility to add python support, and then wrap the
intensity engine python code, assuming that the interfaces are similar
enough.

The Sirikata system is actually designed along pretty similar lines. I
think the main difference is with the AssetIDs and URIs:

What you describe as an AssetID is what I call a "named service URI",
which is basically a URI. Currently I have no restrictions on the format
of this URI, but my intent is to be a sort of "Permanent URL" that never
changes and will always reference the same asset:
http://en.wikipedia.org/wiki/Persistent_Uniform_Resource_Locator

Now, this maps to a "Hash URI" which is another abstract URI of which
the filename component is usually some form of sha256 hash. This
abstract URI then maps to any number of possible http: uris where the
resource could be found, but this last step shouldn't have to be necessary.

I agree about dependency tracking. Currently clients have to parse all
the data files to determine the list of dependencies each step of the
way, and it would be nice to have this information readily available by
the metadata server if possible.

The other thing we do not currently handle is authentication: Even HTTP
has quite a few authentication methods, and it would be nice to
standardize on this (for example, something like Cable Beach, and then
keep a cookie after performing the authentication step.)

-Patrick

[Ryan McDougall]

I wonder if you've looked at capability URLs at all?

http://en.wikipedia.org/wiki/Capability-based_security
http://en.wikipedia.org/wiki/Capability-based_addressing

The idea as it applies to URLs is that someone hands you a URL with a
big unforgeable number in it, which represents your right to access
the resource behind that URL. A functionally similar method would be
to put that number in the Authorization header, which would be
slightly more work for the server implementer (I guess).

Assets protected by such "CAP" URLs might look like:
http://.../assets/<CAP>/<HASH>

The HTTP server would decide based on it's own policy whether the
above URL would be one-time use, or timed use, or eternal use...

I personally don't find securing assets very interesting, but I know
some people demand it.

Cheers,

[Hurliman, John]

The previous thread seemed to be a bit more focused on the implementation of a system to do dependency resolution and asset fetching. However, I don't want this to get lost in the noise so I'm branching onto a new thread to talk specifically about container file formats for content. This is going to be a critical piece of the puzzle, especially when you start talking about the content pipeline of virtual worlds. I like what I've seen so far in Metaforik; what are some other thoughts on the subject? Does a unified container format make sense, or should it be context specific? For example, OGRE assets are great at referencing things that will be fed into the OGRE engine, but it's not very useful for referencing sound files, scripts, notecards, etc. Should those things be put in a separate container file?

John

[Alon Zakai]

Yes, I agree, it does sound like there is a more similar
design than I thought at first.

But I'm not sure why you require three levels of URIs, though,
I guess I am missing something (we use two).

Regarding dependencies, our long-term goal is basically
something like Linux distros have with their dependency
systems (apt-get, yum, etc.), which solve very similar
problems well.

Best,
Alon Zakai / kripken

[Ryan McDougall]

On Wed, Jun 10, 2009 at 10:13 AM, Hurliman, John<john.h...@intel.com> wrote:
>
> The previous thread seemed to be a bit more focused on the implementation of a system to do dependency resolution and asset fetching. However, I don't want this to get lost in the noise so I'm branching onto a new thread to talk specifically about container file formats for content. This is going to be a critical piece of the puzzle, especially when you start talking about the content pipeline of virtual worlds. I like what I've seen so far in Metaforik; what are some other thoughts on the subject? Does a unified container format make sense, or should it be context specific? For example, OGRE assets are great at referencing things that will be fed into the OGRE engine, but it's not very useful for referencing sound files, scripts, notecards, etc. Should those things be put in a separate container file?
>
> John

I wonder if Metaforik could be adapted to a SL-like world?

[Patrick Horn]

Combining container formats and metadata might actually solve a lot of
problems that occur when downloading content just by filenames:
- It is no longer the client's responsibility to recursively compute
dependencies.
- It now is possible to download any type of asset that may depend on
other files, as long as the *uploader* understands the heirarchy. And it
would work for different types of content, not just meshes.
- Metadata could potentially be built into the container format, instead
of having separate metadata for each file.
- This makes archiving of assets a lot simpler. It is simpler to make a
copy of a container file, than to walk the tree, and worry about
cross-references between different meshes (which can happen, but just at
the hash level rather than the filename/asset ID, or if allowed in the
container format, it would likely be done explicitly for a reason, such
as a logically separate component).

The downsides as I see it are:
- It may make reuse more difficult, for example if you want to only
download a piece of a mesh, or just an individual texture from someone
else's mesh, how do you reference this? Since assets are usually stored
by hash, do we require that you just "copy" any files?
- Ownership constantly changes around: you no longer have the reference
to the original uploader. However, keep in mind that this can easily
happen anyway. As I download a mesh, my cache folder on my computer
fills up with all the assets, and I can rename them to whatever I want,
modify the dependency references in each file, and re-upload them to my
CDN server as if I created them.

True, the hash URI can store creator information, since hashes are never
supposed to change, but then that will encourage people to slightly
alter one byte in the file so as to change the hash (which will happen
anyway if the filenames change).

Anyway, I really like the idea of having a standard metadata format, and
possibly combining it with containers/dependency trees so as to simplify
the process of downloading dependency trees for clients that do not
necessarily understand the formats.

-Patrick

[Patrick Horn]

I decided to post this to the kyoryoku list as well --
but here's the rundown of the process of downloading an asset in Sirikata.


The first mapping can be in a configuration file, or the server can tell
the client how to perform this conversion:
permanent-uri:///somemesh.mesh ->
http://mynamelookupserver.example.com/names/somemesh.mesh

This returns another URI:
hash:///1293f84...

In addition, this file might in theory be in XML format and contain
other metadata in addition to the followup URI.

The client performs another conversion, however this time to a different
set of services, for example:
hash:/// -> s3://some...@amazon.com/ or http://cdn.example.com/

The client now chooses which URI it likes better, and picks that, for
example if it prefers example.com over amazon.com, it is up to the
client to pick that uri.

And this will return the binary data for the mesh.

yes, it's confusing, and it sounds like in your case, everything is
given directly in the form of a HTTP uri. The main problem with this,
and the reason that it doesn't work this way, is that meshes or
materials usually need to reference other assets, and when you put a
http URI into the content itself, you are restricting it to only be
downloaded from one server.
The other reason is so that I can stage content on a local CDN server
(in a LAN or on the same host) for testing purposes, and then be able to
upload that content, unchanged, to another CDN server.

Perhaps the solution for this is to have assets reference each other
without a URI.

I really didn't give this all that much thought when I wrote this back
in late january. It just felt to me like it adds flexibility, and
hopefully at relatively low expense. It's probably better if this gets
changed to a simple standard earlier rather than later.

-Patrick

[Ryan McDougall]

NOo00oo! We've begun the top-posting! Must not... submit to conformity... :)

I like the general direction of this line of thought. Although,
container formats are necessarily meta-data, and then it becomes a
concern how to factor things out; whether some attribute belongs in
asset meta-data, inventory, or an intermediate container file.

I would prefer to keep data and meta-data separated, so that you could
choose to reference an asset in the context of it's original
relationship to others, or you could address it's data in isolation. I
think that would handle your proposed drawbacks.

I would prefer to have dependencies outside the container format so
that clients don't need to parse a file of potentially arbitrary
complexity for just deps -- after all, everyone will need dependency
analysis.

The concept of inventory or file systems also comes into play here.

Let me make some definitions and try an example of my thinking in the
context of a whole pipeline:

Asset: dumb, static blob of data that represents a fragment of a whole
work of content
ex: texture, sound

Item: a collection of assets and functional information about how
assets relate to each other, that represents a re-usable, partial or
whole, work of content
ex: ogre material, Metaforik, MyHouse.item
note: Items are not strictly inventory because they contain shader
programs, spatial relationships, etc. -- they are _content_ unto
themselves

World: an arrangement of Items in space, with possibly non-uniform
ownership rights
ex: Joe's Plaza

Inventory: a relationship between Items used by humans to organize
data they have ownership of
ex: ".../my_identity/my_avatar/clothes/saturday_evening_wear/dancing_boots.item"

1. content creator creates WonderWorld locally in a private world.
Items are created by the creation-app and stored on disk. All URIs
within this private world are either of the form
file:///C/Content/WonderWorld/*, or relative to the path
file:///C/Content/WonderWorld/

* in a realXtend-like world, an "item" consists of one prim which acts
as a bounding-box for an ogre mesh (my.mesh), which in turn contains a
some ogre materials (my.material)

2. content creator publishes WonderWorld to his chosen CDN, in this
case the Cable Beach HTTP-based Asset Server at http://example.com,
and clicks "publish"

3. publisher-app recursively parses all WonderWorld Items:

4. publisher-app creates a content hash of the item or asset, and
corresponding meta-data stub

4.1. publisher-app creates a rebased URI for each asset or sub-item by
prefacing all relative paths with http://example.com/assets/, or
replacing all occurrences of file:///C/Content/WonderWorld/ with
http://example.com/assets/

4.2. publisher-app computes a dependency graph for each item or asset
based on it's traversal, and adds the fully qualified URIs of ALL
child assets to the meta-data stub for that asset

5. publisher-app computes LoD settings, including any down-sampled
images or meshes

5.1. publisher-app computes content hashes for all LoD assets, and
places the fully qualified URIs of ALL LoD assets to the meta-data
stub for that asset

6. publisher-app walks the list of items or assets and their
respective meta-data, and POSTs the binary, then meta-data to
http://example.com/assets

7. publisher-app "instantiates" the items within a given simulator

* in a realXtend-like world, this would mean the item describes a
target primitive and an associated Ogre mesh. the publisher creates
the prim in the region's primtable and sets it's RexObjectProperies to
point to "http://example.com/assets/<HASH>" which is "my.mesh", which
depends on "my.material"

8. "instantiated" items within the world enter the "world inventory",
and thus enter the permission model for that world

9. client logs into the simulator and receives notice of an in-world
object and its associated URI-addressed assets

10. client peeks that the scheme is "http" and thus does an HTTP GET
on http://example.com/assets/<HASH>/metadata

11. client decides an appropriate LoD, and downloads and caches ALL
dependent assets listed in the meta-data for that LoD; firing a
callback as the download progresses

* since dependencies are cumulative, recursive parsing of /metadata(s)
is not strictly required
* in a Ogre-like world, the .mesh file does mesh LoD internally, so
/metadata may not contain separate LoD assets

12. when an asset's MIME-type indicates it is a container file, a
container-parser parses the file in order to build the in-memory
representation required by the engine; including via cache look-ups in
the asset cache (by fully qualified asset URI)

* in a Ogre-like world, .mesh, .material, etc., are all container files

13. the renderer is notified of completed items or assets, which it
looks up in the asset cache by fully qualified URI; the fully decoded,
complete, and ready-to-use in-memory binary representation is returned

14. the user wishes to place a flower from his personal inventory
somewhere within WonderWorld, does a drag-and-drop operation to
accomplish this

15. client copies, using WebDAV, the flower item from
example.com/inventory/<identity>/fun_stuff/flower.item to
example.com/inventory/<WonderWorld>/dropped/

16. simulator receives notification of the new item, parses the
container format, and creates an in-memory object (similarly but less
involved than the client, since servers mostly propagate updates or do
collisions/physics)

...

One could argue that it is excessively rigid to have the publisher-app
hard-code absolute URIs, since it would be difficult for someone to
re-use content by downloading it, as he would have to manually rebase
all URIs when he publishes. However isn't that precisely the behavior
that content creators would want? A kind of low-level copy protection
that makes it easier to make new content (because you have the
un-rebased, unpublished Item files on your local PC) than to copy it
from a public server?

I find this discussion *immensely* productive, and am starting feel
that the way is getting clearer. :)

Cheers,

[Alon Zakai]

Interesting, thanks.

The two-level URI method we use does directly indicate
a HTTP address, as you say, but we still intend to implement
things like being able to pick which server to download
from, etc. The main options are:

1. The metadata server can return different URLs for
the same asset, in effect simple load balancing, also taking
into account currently inactive asset servers, etc.

2. Through the dependency system. As I said above,
the main inspiration for me is Linux dependency
systems, so basically similar to how they handle it.
For example, a content-less asset with several
dependencies that are marked as 'get only one'
(slightly similar to 'conflicts' in apt) would let the client
pick one.

I guess this just moves the complexity elsewhere, in
comparison to your approach, so it's a matter of taste
perhaps. Neither seems to be clearly better performance-
wise either.

Best,
Alon Zakai / kripken

[Tommi Laukkanen]

Hello

Couple of thoughts and questions as sum up about the proposed
container format.

- Container format increases data model complexity. Container format
has redundant information as for example models refer to their assets
natively. As with any redundant information it can and will be
sometimes inconsistent because of bugs, user errors and lack of
transactional data storage.
- Container format increases complexity of asset provider.
+ Container format decreases complexity of content consumer. The
container format would be the same with different underlying content
formats making it possible to download dependencies without knowledge
of the content formats.
+ Container format provides standard aggregation language and allows
proceeding to development with multiple parallel content formats.

Questions:

When created content is uploaded to asset server is the original
folder and naming structure completely erased and replaced with UUID
based strings? What about exports from asset server to file system?

Should container format publish metadata document as an optional
aggregate content?

Each time things are uploaded to content server the container
documents have to be automatically generated or maintained by hand. If
they are generated automatically then is there a convention for
generating the url for the content documents? Are container documents
immutable in the sense that the container document pointed by given
url never changes?

Are immutable assets a good thing in the sense that the content of an
given URL never changes? Can it be problematic that two versions of
the same asset have different identities?

Should the container format include last modified dates for caching
functionality if the assets are mutable?

Should we use quasi content protection as a design goal? If we can get
simpler and cleaner implementation should we accept the open nature of
the content pipeline? Usually security by obscurity just makes life
harder for developers without providing actual business benefits.

Should we try to find simplest possible solution to the defined
problem? In other words shall we try and keep the container format as
simple as possible.

Should we try to find another name for the container format as
container is easily mixed with content when writing and reading.

Should we allow for both absolute and relative URIs? Generally I think
relative URIs are better pattern but they require a bit more from the
consumer.

Should we draw a simple picture with all actors, their names and
interactions?

-tommi