Re: [vwrap] "Trust Domains", conditioners and refineries

[Dzonatas Sol <[e-mail]>]

Added "trust domains" to the subject line to hopefully narrow this 
thread before it goes into some random debate.

At the source level, in the (voted upon?) client/server roles, who is 
the trust domain? If user A connect to asset server B, and B connects to 
grid X and grid Y, is the trust domain B, X, and Y, or just B and 
whatever A determines? I don't think there is any determinate 
client/server role here.

Being able to export/import objects with given "trust domain" is 
obviously either going to be "local only" or maybe combination of above 
A, B, X, Y. Should we simply establish trust domains based upon sign-in 
capabilities keep it simple to PGP/GPG keys. I think the URI/GPG-key is 
the simpler way for non-local assets, yet to be proven.

Do consider more complex assets that are "manufactured", and may contain 
encrypted assets within asset bundles in order to move objects between 
regions/v-worlds. The current SL(-compatible) protocols don't seem to 
handle bundles. What-if an asset is made for grid X and bundled with 
another asset for export/import. If grid Y cannot establish any "trust 
domain" with grid X then where should the export/import fail?

Yes, I'm thinking ahead... but the "manufactured" use-case is old (and 
by Morgaine's keeps being set aside to argue other "misapprehensions"). 
The manufactured use-case may get as complex as materials from many 
different grids in order to put together one object. Then we'll have to 
consider if that object requires a predefine trust domain in order to 
interop at various levels.

Let me also include this (un-rephrased from other email): Does "service 
level interop" include anything about "region-crossing"? If it does not, 
then we surely can then partition capabilities into different 
client/server clusters. If people want more seamless movement while in 
"service level interop" then mabye that needs to be upgraded to 
the"region-crossing" level.

When is interop from grid X to grid Y seamless, when do assets need to 
be conditioned (keep "trust domains" in mind), and when do objects need 
to be refined? To continue to use client/server terminology in that 
question is just to complex (or confuses the discussion into further 
endless debate).

Morgaine wrote:
> There is no default format, and nowhere does VWRAP deal in 
> SL-compatible grids.
>
> We are defining a services-oriented architecture which is nothing like 
> that of today's SL, and we cannot for a moment assume that SL will 
> adopt it in the future, as that is their choice, not ours.
>
> The only partly-compatible VW frameworks over which we have a small 
> amount of influence are Opensim and realXtend (which uses Opensim 
> server-side), because we can take their open source code and adapt it 
> to our protocols if we wish.  In that sense, we could be said to be 
> defining an Opensim-compatible protocol, but never an SL-compatible 
> protocol.  That would be a misapprehension.
>
> We occasionally say that we are defining an SL-like /*data*/ 
> architecture, but even that isn't really correct since VWRAP doesn't 
> favor one in-world content type over another.  All content types are 
> denoted merely by a type tag and there is no standard set of content 
> types required.
>
> So what is the real commonality between VWRAP and SL?  Currently, only 
> LLSD is reasonably compatible with SL, although LLSD might well change 
> in more than just its name if we find the current spec not 
> sufficiently powerful or lacking extensibility for our needs.
>
>
> Morgaine.
>
>
>
>
> ==========================
>
> On Thu, Mar 31, 2011 at 4:21 PM, Dzonatas Sol <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Don't need to assume too much like that, Morgaine; however, we
>     need something more of "trust domains" defined and the example(s)
>     I wrote about fit in well as lead-in. I stated these use-cases
>     specially to avoid the use of terminology that now exists, and
>     this leans towards the need to center on "trust domains." I see
>     the use of current client/server-* terminology continually to
>     confuse us (even if some like it, not all do). If we have to think
>     about such terminology for more than 90 seconds each time then it
>     needs to change.
>
>     My side-point was that VWs may have their own object format in
>     their world, and I'm thinking more then just the regions that
>     exist now that the monolithic client connects. Perhaps, others
>     only think about SL compatible grids, and don't worry about the
>     default format.
>
>     Morgaine wrote:
>
>         We've maintained throughout that our protocols would be
>         extensible with regard to data formats, allowing worlds and
>         user expectations to evolve without requiring protocol
>         redefinition.
>
>         In the area of meshes, it is very much to be expected that
>         COLLADA will figure strongly among the graphic formats used
>         (particularly since it was chosen for the iED initiative), but
>         it's not of any special interest to the VWRAP protocols other
>         than as a potential content type.� All we have to do is to
>         make sure that we label each transfer with its appropriate
>         type, and possibly also include other metadata that may be needed.
>
>         We're certainly not standardizing what graphics are used in
>         virtual worlds, beyond assigning types where they might not
>         yet exist.� Hardwiring them would be a recipe not for
>         extensibility but for stagnation.� Other bodies may be
>         standardizing which graphics formats are used, whereas we're
>         trying to define useful deployment architectures and
>         standardizing the protocols through which they are accessed.
>
>
>         Morgaine.
>
>
>
>
>         ===================
>
>         On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol
>         <[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>
>            If we say the conditioner basically authenticates or
>         re-signs an
>            asset from grid X to grid Y, and the refinery would make
>         sure the
>            physics of the object described by the asset is translated from
>            the topology of grid X to the topology of grid Y, then this is
>            basically what COLLADA expects in exchange. This exchange
>         is this
>            different from the usual import/export process. It doesn't
>         have to
>            be this exact process, as this is only an example to us be more
>            familiar.
>
>            It seems a complete waste to not realize that LL has
>         implemented
>            the import process and physics refinery into their browser, and
>            this very feature, though not fully automated as such, could be
>            used to help move assets in-between grids/v-worlds. Since the
>            import is from local basis, the authentication is not
>         implemented.
>            What's to stop to basically export to DAE format on the local
>            storage, from one world, and continue to import that DAE into
>            another grid.
>
>            Note that the refineries may be proprietary. They may produce
>            non-COLLADA formats (from DAE files) that are for optimal
>            render/display capability of the software "client" (i.e.
>         that the
>            end-user has to view graphics).
>
>            As with Google Earth and Sony HOME, they already have their
>         assets
>            conditioned and refined for those virtual worlds such that they
>            can optimally display them. The key note is not the optimal
>            display, as it is about being able to exchange and use in other
>            virtual worlds.
>
>            The DAE format does have extensive abilities, yet the goal of
>            COLLADA is still to define the basic material, scripts,
>         model, etc
>            in the most portable format. The DAE may contain hybrid or
>            specific formats that is stored in the extensions, so that
>         custom
>            objects are retained/transferred.
>
>            If virtual worlds start to not agree upon how they store
>         objects,
>            I see COLLADA as the default format for digital asset exchange.
>
>          
>          https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F
>
>            (Yes, we can put all inventory items in DAE format through the
>            user-data and asset extensions, despite the format mainly being
>            for 3D... just sayin')
>
>            --     --- https://twitter.com/Dzonatas_Sol ---
>            Web Development, Software Engineering, Virtual Reality,
>         Consultant
>
>            _______________________________________________
>            vwrap mailing list
>            [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>
>            https://www.ietf.org/mailman/listinfo/vwrap
>
>
>         ------------------------------------------------------------------------
>
>
>
>         _______________________________________________
>         vwrap mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/vwrap
>          
>
>
>
>     -- 
>     --- https://twitter.com/Dzonatas_Sol ---
>     Web Development, Software Engineering, Virtual Reality, Consultant
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>   


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant