Re: [mmox] Rough draft of the Cable Beach Core protocol is online

[Morgaine <[e-mail]>]

On Thu, Jul 2, 2009 at 4:01 AM, Hurliman, John <[e-mail]>wrote:

>    * Give virtual world administrators more flexibility, not less. *No use
> case is viewed as more or less valid than another, and the system does not
> favor any particular setup.* Building a walled garden is just as easy as
> building a completely decentralized world, or any combination of the two.
>
>
One use case (aided by the CB model) which I have always found interesting
but which is not covered by any known OGP plans nor current Opensim
functionality is what I call the *Free Worlds Tourist* use case (plural *
Worlds*), which results from the conjunction of two elements ---  the first
easy, and the second either slightly harder or *much* harder:


   1. Travel requires no prior arrangement.  Armed with nothing more than an
   Internet-based identity (eg. through OpenID), no registration with target
   worlds is required, so you can visit places in arbitrary worlds with a
   single click on a suitable URI from whatever source.
   2. Your avatar is defined by you, not by the target worlds, and it
   appears in those worlds with no prior arrangement.  This implies that your
   avatar data is present on your client machine and is uploaded to the visited
   world for distribution to other participants in the same area as yourself,
   or else that it is present on an external asset provider service from which
   it is distributed to those other participants directly.


Part 1 is already handled by Cable Beach, and in principle also by the
OpenID Relying Party support in Opensim.  (This checkbox can probably be
considered ticked.)

Part 2 is fairly easy when all visited worlds employ the same avatar
representation(s), so that new avatar data can use the same avatar rendering
code that already exists in viewers.  All that's required then is to extend
the login-and-rez-avatar functionality with a new obtain-avatar-data
mechanism, so that instead of a new visitor appearing in new resident's
apparel on entry, the previously-defined avatar appears instead.  (Note that
this can work with multiple predefined avatar types, not just one.)

Part 2 becomes much more complex in the full MMOX scenario of diverse
interoperating VWs however, because now we require new avatar data to be
accompanied by new avatar rendering code as well.  There are many ways of
approaching this.  One way is to send rendering code along with the avatar
data not unlike how Javascript accompanies web pages today.  Another
approach is to use plugins which are fetched on demand whenever a new
renderable object type is encountered, either signed trusted plugins from a
respected clearinghouse or else arbitrary untrusted plugins which run in a
constrained VM sandbox/jail environment.

The result of implementing this *Free Worlds Tourist* use case would be to
release the shackles on avatar diversity, allowing any given open world to
experience the creativity found in other worlds through their world-hopping
visitors.  It would undoubtedly be a multi-cultural spectacle, and a source
of huge interest in the virtual arrivals lounge. ;-)

In addition to high avatar diversity, this use case provides great ease of
use as well, since no aspect of travel requires prior arrangement.  As such,
it could fuel an explosion of popularity for virtual worlds.


Morgaine.






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

On Thu, Jul 2, 2009 at 4:01 AM, Hurliman, John <[e-mail]>wrote:

> http://code.google.com/p/cablebeach/wiki/CableBeachCore1_0
>
> From the Cable Beach website:
>
> Introduction
>
> Virtual worlds are made up of a complex stack of services that operate
> together to deliver a complete immersive experience. The approach that
> virtual worlds have taken so far is to build an entire vertical stack of
> services including user account management, content distribution servers,
> inventory hosting, simulation servers, simulation coordinators, and more. As
> virtual worlds grow in both popularity and complexity, it is no longer
> always desirable to only build so-called "walled gardens" of services. Cable
> Beach provides the glue to bind virtual world services together, whether
> they exist alongside one another in a data center or across the Internet run
> by different administrators that have no preexisting relationship. The
> primary focus of the architecture is on the following:
>
>    * Let service providers specialize in what they do best. To address the
> growing scalability demands of the web, service providers have evolved into
> providing narrow but high quality services. You wouldn't expect a social
> network to also provide the best search engine service on the web.
>    * Use existing standards. Many of the challenges in virtual worlds are
> broad issues that are also being addressed by the web community. Instead of
> creating new parallel solutions, Cable Beach attempts to leverage as much
> existing technology as it can to enable better compatibility with other
> architectures, both today and in the future.
>    * Give virtual world administrators more flexibility, not less. No use
> case is viewed as more or less valid than another, and the system does not
> favor any particular setup. Building a walled garden is just as easy as
> building a completely decentralized world, or any combination of the two.
>
> The core of Cable Beach is the definition of a world service, a virtual
> world login protocol, and a standard method of defining virtual world
> services. The implementation available at this site consists of a server for
> a world service and another server for assets and filesystem services.
> Initially, this implementation is targeting compatibility with the OpenSim
> project using a custom OpenSim extension called ModCableBeach. Additional
> connectors for other virtual world systems are in the planning phase.
>
> ---
> John
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
>