MMOX and Social Architecture

This week I subscribed to the MMOX listserve. MMOX is a proposed IETF working group that is an effort to collect best practices and develop consensus based standards for virtual world and MMOG interoperability. The mailing list is intended to host technical discussions related to the MMOX objectives.

I've written in the past briefly about interoperability and most people know I am passionate about this topic, but most don't know why so I thought I'd share. I was asked why I oppose interoperability so allow me to clear that point first.

I do not oppose interoperability, quite the contrary. However, I have particular sensitivities - not oppositions - about interoperability standards based on my background and experience. Those are my biases based on what I've done in the past, and we all have them.

Be an informed participant
I'm encouraged that the technical conversations about interoperability will take place within a formal and established framework, but before you run off and join the list be sure that you understand and appreciate at least two important points:

1. This working group is wholly focused on developing technical specifications toward a common goal.

2. The IETF is a respected and long standing institution largely based on common engineering practices with rules that you should take time to read and educate yourself before diving into the deep end. This is not about exclusion, but it is informed inclusion that leads to the most productive discussions. For example, if you don't know what NOTEWELL means, you are not adequately informing yourself, and in some cases that can lead to distracting and detrimental contributions.

Embrace Diverse Perspectives
I'm writing this post mostly to get my biases from my head to bits, since unfortunately I haven't nearly the time or professional directive to dive into MMOX in detail everyday, but hopefully this will be a helpful contribution.

I trust that the MMOX community will draw in resources from a diverse base disciplines so as not to be trapped in an echo chamber. Most notably, the modeling and simulation community has made significant strides toward understanding the technical implications of interoperability. If you are interested, please refer to the Simulation Interoperability Standards Organization, or SISO.

I am not a MMOG or virtual world developer, my experience is drawn from developing large scale real time simulations to support development, training, test and evaluation and from being an active VW resident and researcher. I am passionate about the future of virtual worlds and this is my contribution toward that end, which starts with some background.

Interoperability Lessons
In 1996 , the Defense Modeling and Simulation Office developed the High Level Architecture (HLA) to address the need for interoperability among new and existing DoD simulations. At the inception of the HLA, there were already working interoperability standards such as the Distributed Interactive Simulation (DIS) and Aggregate Level Simulation Protocol (ALSP), but by the power of DMSO, HLA was the anointed standard, compliance was mandatory and most importantly it is still a living and internationally adopted architecture.

HLA is defined under IEEE standard 1516-2000 and is defined by three components: the Object Model Template (OMT), an Interface Specification, and the HLA rules. A federation of interoperating simulations consists of: federates (all participants and object representations), a distributed OS called the run time infrastructure (RTI) and a common set of six primary RTI services.

1. Federation Management: Creation, dynamic control, modification, and deletion of federation execution
2. Declaration Management: Generation and subscription for object attributes and interactions
3. Object Management: Creation, dynamic control, modification, and deletion of objects and interactions (note: this is the network traffic driver)
4. Ownership Management: Allows federates to transfer ownership of object attributes to other participants in the simulation
5. Time Management: Time services for setting, synchronizing and modifying clocks. This is tightly couple with Object Management so that state is managed appropriately
6. Data Distribution Management: Provisions for efficient data routing between federates

Start at the right place
Note that the HLA RTI services look strikingly like those that might be applicable to MMOX. Also note that since these are services and not protocols, and implicitly federations must be designed toward a particular purpose.

I think we can all agree that we are but on the fringe of truly understanding the implications of virtual world interoperability but we can imagine future scenarios of purpose. That set of scenarios will help highlight misconceptions, presumptions, etc. about what interoperability might mean.

Lesson #1: Develop a set of working scenarios for interoperability that covers what you might imagine - you won't get it all, but at least start somewhere. This will also help set the consideration set.

HLA was designed as an open architecture with a set of rules to be future proof; it's impossible to anticipate every use case toward interoperability and intended use, therefore modularity and extensibility were important architectural factors to allow for growth. It was based on a set of rules that govern specific execution and implementation.

Lesson #2: Outline a set of questions that will lead to rules that must be addressed toward interoperability. Here's my very short list:

• Identity Management: How does an avatar's identity originate and translate across worlds? Could there be federate for identity creation that resides outside all worlds?
  
• Object Management: How do object properties including permissions as well as behavioral traits such as animation or movement get set and interpreted?
• Time Management: Under what scenarios is time critical?
  
• Data Distribution: What scenarios require routing spaces?

For those people who were successfully executing interoperable simulations under the DIS protocol, HLA was like choking on a chicken bone. HLA provided a standardized set of services that required active agreements among participants, whereas with DIS all one had to do was adhere to the protocol and - poof - you were interoperable. However, there were real limitations with the DIS protocol that include lack of scalability, lack of causality, latency and inflexibility.

MMOX conversations must start at a much higher level than LLSD and OGP if it is to be a useful exercise. Specific implementations and protocols, while they exist today, serve to limit thinking about what might be done over what could or should be done. Context is already king here, not the incumbent working draft of a prince.

Lesson #3: Start with architecture and requirements, then follow with protocols. Protocols are often optimized toward a particular end such as ease of use, which may have long term implications and limitations and without context, are deadly.

This is getting quite long winded, and most of you have gone to tl;dr but I wanted to make one last and possibly most important set of points.

Technical - and - Social Architecture = Interoperability
I mentioned at the top of this post that MMOX is for developing technical standards, which are a necessary but not sufficient part of shaping the future of VW interoperability. What's missing is the really hard part, the people - residents - users - content creators - business owners - and the implications of what interoperability might mean to them, personally.

Paired with the "Technical Architecture for Interoperability of Virtual Worlds" should be a "Social Architecture for Understanding Interoperability of Virtual Worlds". The former will move ahead but the latter is really difficult because of the legal, social and cultural complexities and even the lack of an IETF-like entity for the Social Web.

However, it's imperative that the complementary dialogue about Social Architecture occur, and I would argue that it is in MMOX's best interest to consider a means by which social architecture be considered. A technical standard without a basis of use and context is pointless.

Consider on-going examples such as Facebook's Beacon project, or the reversal on the Facebook Terms of Use. These are examples of perfectly legitimate and well formed technical statements that were met with a backlash of social outcry, despite their technical correctness and legitimacy within the Facebook architecture.

Furthermore, Social Architecture highlights the important elements of interoperability from the point of view of a person. What kinds of things might be important to someone traversing virtual worlds?

• How is my privacy protected?
• Who am I when I go from one place to another?
• Can I be in two places at once?
• Can I control my identifier AND my identity?
• What guarantees do I have that my IP is protected when it moves from place to place?
• What are the legal implications of going from one set of servers, hosted in one country, to another?
• How will my personal data be protected?
• What if I don't want my avatar, belongings, creations, etc to be exposed to other federates?
• Can I control visibility and/or interaction?
• Are there provisions for "border control"?
• Will my status and state be preserved across boundaries?
• What types of transactions can cross boundaries? How are those mediated?
  

This is but a short list of non-trivial considerations that require more than merely technical specification.

I can participate in this discussion but I can't actively lead due to other time constraints. But now that Robin Harper (formerly known as Robin Linden) has some time on her hands, perhaps she could lead this part of the discussion...

... one can dream.

Share Some Grace: