Re: [ogpx] An example to show the problems with defining an OGPX/VWRAP virtual world

[Morgaine <[e-mail]>]

Magnus' interesting analysis effectively reaches the same conclusion that
various people reached in MMOX.  I wrote a short summary of it back then --
http://www.ietf.org/mail-archive/web/mmox/current/msg01307.html .  Trust
agreements will not build the metaverse, but only balkanize it.

In the end, the only trust domain likely to bloom explosively in the way
that the Internet and the web did is the *nil trust* domain, so all this
emphasis on trust agreements is largely immaterial to the worldwide spread
of virtual worlds.  Trust agreements on a global scale become completely
meaningless, as no trust is actually carried.  Schneier's point about
"security theater" applies here completely.

Fortunately, as David Levine has said a few times, trust agreement
technology does not preclude nil trust, so we can work with this.  However,
it will be extremely important to ensure that the nil trust mechanism is
actually catered for in practice in VWRAP, rather than just in theory.


Morgaine.






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

On Tue, Sep 1, 2009 at 11:06 AM, Magnus Zeisig <[e-mail]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Sorry to crash in and sorry if my below rambling is useless, a
> misinterpretation, or, even worse, only mess up things even further. But I
> believe an example might clarify things a bit to at least some readers. If
> my below example is wrong, perhaps someone with a better understanding than
> me could correct it or provide another example.
>
> I think one of the problems with the definitions of "virtual world" and
> related terminology on the list is that it's easy to lock it to the existing
> models, like Second Life or OpenSimulator, and not realizing that future
> models might be quite different. If I understand the intents and early
> definitions on this list right, a very small but still rather complex
> OGPX/VWRAP model might look like this:
>
> Protocols
>
> * Five geographically adjacent simulators/regions in a rectangular grid:
> "R11" (top left), "R12" (top right), "R21" (middle left), "R22" (middle
> right) and "R3" (bottom left and right, since no requirement for equal-sized
> or -shaped regions exists).
> * Four avatars: "A1", "A2", "A3" and "A4".
> * Three simulator/region owners/managers: "M1" handling "R11" and "R22",
> "M2" handling "R12" and "R3", and "M3" handling "R21".
> * Three asset/inventory service providers: "S1" catering to "A2", "A3",
> "R11", "R22" and "R3", "S2" catering to "R12" and "R21", and "S3" catering
> to "A1" and "A4" (one region owner may employ more than one asset service,
> like "M2" does with "S1" for "R3" and "S2" for "R12").
> * Two authentication service providers: "L1" catering to "A1", "A2" and
> "A4", and "L2" catering to "A3".
>
> Note that some of the above entities may be the same company or site
> providing different services, e.g. "Virtual World Services, Ltd." managing
> both "M1", "S1" and "L1".
>
> Policies
>
> All simulator/region owner/managers, asset/inventory service providers and
> authentication service providers share a common domain of trust, with the
> following exceptions:
> * "M2" doesn't trust "S1" (e.g. owing to previous experiences of malicious
> content).
> * "S1" doesn't trust "M3" (e.g. owing to "M3"s refusal to sign an IP
> agreement).
> * "M1" doesn't trust "L2" (e.g. owing to a too loose control when accepting
> new users).
>
> Results
>
> Seen from the avatars' points of view, this means:
> * "A1" can move freely with all attachments and inventory through all the
> regions.
> * "A2"  can move freely through all the regions but can't bring attachments
> and inventory to "R12" and "R3" owing to "M2"s distrust for "S1", and "R21"
> owing to "S1"s distrust for "M3".
> * "A3" can only move to regions "R12", "R21" and "R3" owing to "M1"s
> distrust for "L2", and can't bring attachments and inventory to "R12" and
> "R3" owing to "M2"s distrust for "S1", and "R21" owing to "S1"s distrust for
> "M3", i.e. is not fully operational in any region. Also, the world is
> geographically split since "R12" and "R21" is only connected through a
> corner where it can't cross but require teleportation.
> * "A4" can move freely with all attachments and inventory through all the
> regions.
>
> So, to "A1" and "A4" this is a great virtual world with five fully
> functional regions, to "A2" it's a hobbled world where it's ruthed (forced
> to some generic appearence) in three out of five regions, and to "A3" it's a
> lousy, splitted world with only three regions in which it's all ruthed. But
> what really constitutes the geographic "virtual world" in this example? The
> five regions "R11", "R12", "R21", "R22", "R3", the three regions "R12",
> "R21", "R3" where all avatars can go, or no region since there is no region
> that is fully functional to all avatars?
>
> I guess this is part of the reason why the exact definition of e.g.
> "virtual world" and "interop" is not made, because the aim of the working
> group is to provide the technical specs necessary to enable, but not force,
> the communication between such entities as mentioned in the example above,
> while policies might make up a totally different infrastructure and
> impression of what the "virtual world" or "virtual worlds" and "interop"
> are, or at least appear to be to the end-users (avatar owners).
>
> Best regards,
> Magnus
>
> -----BEGIN PGP SIGNATURE-----
> Version: 9.8.3 (Build 4028)
> Charset: utf-8
>
> wsBVAwUBSpzyJ+5MlU9XyaiSAQgTyQf+MjeSs8iKdSWHKKPASzwa9KjmYtj8ojUg
> +nqiaGtaB7lWC/Lq1PUGxMXdJvUd4AhCL96wvawWQzxAQmYYk7n0hjvs6RKub2cm
> bhuvhHbEtn/9uD1tdBJvm0x+Q1ZFr6nqE2XV9cXEwlGx32/wl9aP0/wejAouqCZM
> a9YQv5ceE5B3zJn54TdbFPXX8V6OZ7jtiUplP2erhUg0hkzOjVYkwt1f5G9NJhW8
> p2YcTYibC0mnnu/ATzVojMhxMiQpwxRH7695TobDUdBCz48+ix1tZvkLdk9o2t2u
> JodGIkTtd+mFdYOtUNbaScrTs02exahKfqD81gaEYCcLfO+J14XkkQ==
> =FsIQ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>