Re: [vwrap] what's wrong with starting small?

[Morgaine <[e-mail]>]

On Thu, Sep 23, 2010 at 1:03 AM, Cristina Videira Lopes
<[e-mail]>wrote;wrote:

>
> WRT the boundaries of interoperation. In HG1.5, there is a clear
> distinction between internal interfaces (i.e. how simulators and resource
> services interact within the same domain of trust) and external interfaces
> (i.e. how simulators interact with services outside their domain of trust).
> Teleporting, for example, is done differently. So is inventory access.
> Potentially, every interaction between components in different domains of
> trust are done differently than they would be done within the same domain of
> trust, for a performance vs. security tradeoff.
>
> The notion of domain of trust is paramount to HG1.5, because people want
> nothing to get in the way of performance when they know that the machines
> are under their complete control.
>
>
That's very interesting, I like the idea a lot, in part because I regard the
whole "trust domain" concept as an ill-founded delusion and I don't want to
pay the cost for other people's delusions.  It sounds like your approach
might be able to limit the cost of security theater to those whose delusion
requires it.  (Having worked in Defence, I know a security delusion when I
see one.)

There's also another angle to the "trust" issue that your
performance/security tradeoff machinery sounds like it might be able to
handle nicely.  Creative Commons content licensed for unrestricted
distribution effectively carries a master key to pass through the already
vaporous trust domain walls, but unfortunately still pays the performance
cost imposed by other people's inapplicable restrictions.  Perhaps your
high-performance / low-security tradeoff connectors could be used as an
unrestricted transport mesh to eliminate the unnecessary burden for
applicable content.

We need the latter.  The metaverse won't bloom on a bed of nails.


Morgaine.





=================================

On Thu, Sep 23, 2010 at 1:03 AM, Cristina Videira Lopes
<[e-mail]>wrote;wrote:

> Since OpenSim does not assume that there is 1 single data format for these
> exchanges (because there are 2 at the moment), we have recently introduced a
> step of protocol negotiation. The sim asks the server "what kind are you?"
> and instantiates the right connector to it. I'm not particularly fond of
> protocol negotiation, but I see some social advantages in having it: no one
> needs to agree on one single data format, and the door is always open for
> someone to come in with some creative alternatives. As far as OpenSimulator
> goes, if there's an opportunity for diversity, we usually take it.
>
> WRT the boundaries of interoperation. In HG1.5, there is a clear
> distinction between internal interfaces (i.e. how simulators and resource
> services interact within the same domain of trust) and external interfaces
> (i.e. how simulators interact with services outside their domain of trust).
> Teleporting, for example, is done differently. So is inventory access.
> Potentially, every interaction between components in different domains of
> trust are done differently than they would be done within the same domain of
> trust, for a performance vs. security tradeoff.
>
> The notion of domain of trust is paramount to HG1.5, because people want
> nothing to get in the way of performance when they know that the machines
> are under their complete control.
>
>
> On Sep 22, 2010, at 2:13 PM, Hurliman, John wrote:
>
>  We're working on implementing HG 1.5 support in SimianGrid right now which
>> introduces asset fetching across trust domains. Crista could describe the
>> implementation details better.
>>
>> On a side note, I realize that only defining teleport is not very useful
>> if you're try teleporting from Kevin's web-based virtual world to an OpenSim
>> instance that use completely different state synchronization protocols. At
>> best that would end with the web-based client completing the teleport,
>> OpenSim waiting for a UDP connection to be established, and the client and
>> server both timing out. But you *would* be able to teleport from an OpenSim
>> world to another OpenSim-compatible world, and it lays the foundation to
>> start talking about next steps if we want to go further.
>>
>> John
>>
>>  -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of Morgaine
>>> Sent: Wednesday, September 22, 2010 1:58 PM
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: Re: [vwrap] what's wrong with starting small?
>>>
>>> Thanks for the link, Crista!  John's email mentions:
>>>
>>>
>>>
>>> *       Identity/Authentication
>>> *       Assets (possibly Inventory, maybe)
>>> *       Teleport (both login and simulation to simulation)
>>>
>>>
>>> Let's talk about Assets. :-)
>>>
>>> Beyond a small amount of discussion and agreement with Joshua last year
>>> on basic requirements that would enable inter-world tourist use cases,
>>> there has been virtually nothing discussed in VWRAP about this core
>>> topic without which everything else is singularly uninteresting.
>>>
>>> About a year ago, I spoke to John about the need for replacing the
>>> singleton inventory/asset service in Cable Beach with a more flexible
>>> one to allow inter-VW tourism, and John said that his singleton was
>>> just a temporary feature in his prototype and would be improved.  Has
>>> there been any progress on that in the offspring of CB, ie. SimianGrid?
>>>
>>> Staying with "State of the Union" topics, if we're merging VWRAP and
>>> OpenSimulator efforts, would you like to give us a description of asset
>>> handing in the new HG1.5 and where you expect HG2.0 to be heading?
>>> Asset handling on interop is exactly the kind of topic that we need to
>>> have examined in depth before we can write initial drafts that have a
>>> chance of being relevant. :-)
>>>
>>>
>>> Morgaine.
>>>
>>>
>>>
>>>
>>>
>>> =========================
>>>
>>>
>>> On Wed, Sep 22, 2010 at 7:06 PM, Cristina Videira Lopes
>>> <[e-mail]> wrote:
>>>
>>>
>>>        http://www.ietf.org/mail-archive/web/vwrap/current/msg00318.html
>>>        If you are talking about *this* email from John, we are on the
>>> same page.
>>>
>>>
>>>        Meadhbh Hamrick wrote:
>>>
>>>
>>>                so we have a recommendation from at least two implementers
>>> (myself and
>>>                john) that we focus on a small subset of an overall
>>> virtual
>>> world
>>>                problem domain.
>>>
>>>                it seems to me that diva/christina and morgaine are
>>> pushing
>>> for a more
>>>                expansive problem domain.
>>>
>>>                can i ask, what is the issue we have with starting small
>>> and then
>>>                growing the problem domain?
>>>
>>>                i think i remember an IETF "old hand" (it might have even
>>> been barry)
>>>                say that it's a LOT easier to go back to the IAB / IESG
>>> and
>>> ask to add
>>>                things to your charter than it is to remove them.
>>>
>>>                i'm also thinking that some of the tension in this group
>>> is
>>> over the
>>>                conflicting objectives between the "expansionist" block
>>> and
>>> the
>>>                "dimunitivist" block. but it also seems that we're not
>>> horribly far
>>>                off from each other in terms of wire protocol.
>>>
>>>                maybe a solution could be to draft two documents... one a
>>> "long term"
>>>                goal for virtual worlds that describes the "expansionist"
>>> objectives
>>>                and another that is a little more short term and describes
>>> the
>>>                "diminutivist" objective for a small subset of things
>>> needed for the
>>>                long term goals?
>>>
>>>                is the concern with this approach that any near term
>>> service (service
>>>                establishment, event queue, teleport, assets) would need
>>> to
>>> know about
>>>                the totality of the virtual world in order to be
>>> practical?
>>>
>>>                -cheers
>>>                -meadhbh
>>>                --
>>>                meadhbh hamrick * it's pronounced "maeve"
>>>                @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>>>                _______________________________________________
>>>                vwrap mailing list
>>>                [e-mail]
>>>                https://www.ietf.org/mailman/listinfo/vwrap
>>>
>>>
>>>
>>>
>>>        _______________________________________________
>>>        vwrap mailing list
>>>        [e-mail]
>>>        https://www.ietf.org/mailman/listinfo/vwrap
>>>
>>>
>>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>