• Art sits alone "at home" in his recently redecorated virtual living room. (Actually, Art is dialing in from a hotel in New York to an ISP which supports Art's virtual home from a server in Dallas). The new "etchings" on the living room walls are courtesy of a subscription service in London, which automatically updates Art's art every Friday afternoon.
  This scene is not (yet) multi-user, but it is already multi-developer. Note how the distinction between "scene authoring" and "scene use" is blurred when the scene may be composed dynamically from different sources.
   
• There is a knock at the door: Betty and Chuck have come by for a visit. Sitting at her desk in Chicago, Betty clicks her mouse, knocking on Art's door.
  How does Art's laptop in New York "hear" Betty "knock" from Chicago on a door that is "really" in Dallas? When Art opens his door, he sees two figures outside; they also see him, and over his shoulder, his living room; the sound of his stereo, previously muffled, is now much clearer. How does all that happen?
   
• The figure that both Art and Chuck see as "Betty" was bought off-the-shelf at Avatars 'R' Us. Chuck has a custom avatar which he built himself, using the new Acme Avatar Builder. And he has brought along his new "dogbot," which he promptly unleashes, so that it runs around Art's living room, sniffing in all the corners.
  Avatars are independently designed objects inserted into a scene. This further undermines the author/user distinction, and raises any number of data-integrity issues. How does this insertion happen, and under whose control?
   
• An animated discussion ensues (in at least two senses). While Art and Betty type chat-style messages to one another, Chuck makes vocal comments on their spelling and style.
  How does one system find out whether another has voice capability? How do the necessary synchronizations (e.g. changing an avatar's expression to match an emoticon, merging Chuck's voice with the background music) get handled? 
   
• To clarify a point, Art draws a figure on his virtual whiteboard. Both Betty and Chuck can see what he draws, but Betty can also edit the drawing, since her PC has the special pen-pad hardware required by the whiteboard application.
  The whiteboard, separately purchased, is now an integrated part of Art's living room. It depends on aspects of Art's system never anticipated by the designer of the living room (a virtual interior decorator in Berlin). Art cannot know in advance whether a given visitor will have a system able to use the full range of the whiteboard's capabilities. So how and when and where do the several systems involved discover and hook up the capabilities they share?
   
• Dawn arrives, bringing her "Virtual Monopoly" set, which uses the new Zapp-O Virtual Dice, certified by VeriPlay (an independent testing organization) to produce a statistically random "roll."
  A different kind of external reference here: a re-usable, in fact portable, object guaranteed by a third party to fulfill a certain specification. Other examples suggest themselves: a deck of cards certified to shuffle thoroughly and always deal from the top; a cash register which guarantees secure and anonymous transactions. How do we provide for functionality which overrides or enhances or constrains what is pre-defined in the scene (e.g. locking a door, or making a wall transparent)?
   
• Dawn's game has two different modes of play: in addition to the familiar board-and-pieces mode, which prevents players from moving out of turn and always moves them the right number of steps in the right direction [Remember: the dice, the counters and the game were all developed independently], there is also an "immersive" mode, in which the players shrink down so that the houses and hotels on the board seem life-size.
  How does the browser know how much to shrink the avatars, and how to adjust their location and speed of motion? Alternatively, if the "shrinkage" is simply realized by transporting the players into a different scene, how are the actions in that scene replicated on the board in Art's living room?.
   
• Two days after the memorable Monopoly game, Art discovers that the dogbot has left him a gift: a lumpy brown object behind the sofa. Note: Chuck's avatar brought the dogbot into the scene; this imported object then created a new object which remained in the scene after its (uninvited and unmanaged) creator left. When clicked, the brown heap turns out to be -- not what you thought, but a puppy, which runs around like mad and leaves bright yellow stains on the furniture.
  If this is beginning to sound like a virus, then our point is made. Multi-user virtual worlds, like any shared application, will require a full range of reliable mechanisms for protecting their content from inappropriate access and manipulation.

This scenario exposes the complexity of the "distribution" that must be managed to make immersive social applications possible. Virtual online communities will not be designed by single authors, they will not be constructed entirely in any one language, and they will not be under any one operator's control. Rather, they will have to support continual negotiations among objects created without any knowledge of each other, some of which will be "driven" (at times) by unpredictable humans, and the effects of multiple, independently authored, more or less arbitrarily interacting application programs.

Ten Technical Requirements

We can distill our scenario into a double handful of technical requirements that will have to be met by any interpersonal/interopable VRML environment. These include the ability to:

1. Insert/Delete objects (e.g. avatars) in scenes at run-time
   (more generally: to modify the structure of the scene graph)
    
2. Merge multiple sound streams from distributed sources into the
   shared scene's current ambient sound (e.g. voices over music)
    
3. Track and communicate the state/behavior of objects in real time
   (this implies a database of "who needs to know what how often?")
    
4. Allow (sets of) objects to be "driven" by users in real time
   (i.e. provide a UI as well as an API to runtime object control)
    
5. Let imported objects become persistent
   (i.e. make them a permanent part of the scene)
    
6. Protect the scene from damage by imported objects
   (ultimately, this implies the whole range of data-integrity issues)
    
7. Assign objects to a series of different "owners"
   (to insure control over access to object behavior)
    
8. Support persistent roles (for people) and rules (for scenes)
   (i.e. a use-model for scene/object access controls)
    
9. Link objects dynamically to external data/functions
   (in particular, to support authentication certificates)
    
10. Support the free exchange of information among objects
    (from chat and business cards to arbitrary data containers/streams).

The Living Worlds initiative aims to provide standard VRML interfaces to support all these features; the Open Community work proposes a data model and an API with which they might be implemented as a set of interoperable components.

- Bob Rockwell