NG Design Document/realXtend Platform

From Rex community wiki

Introduction

In order to support the vision of realXtend as a future platform for distributed 3D virtual worlds, and 3D Internet, we have identified several key properties the system must have. They are described in overview here.

Requirements

The realXtend platform is designed to be a framework upon which any 3rd party can create rich new interactive 3D applications. realXtend will neither host worlds, nor develop special-purpose market-ready applications itself.

We intend to ship a basic framework, that implements all the essential features expected from a virtual world platform such as exploration, construction, communication, integration, and infrastructure. This will be enough to allow anyone to get started, but not enough to ensure a complete user experience that might form the basis of a solid business enterprise.

Deployments

The realXtend Server should be deployable as small stand-alone worlds, or in large scalable grids serving thousands of people.

The realXtend Viewer should be deployable as an unbranded, open-ended, generic world viewer; or as a branded, feature limited, special-purpose front-end.

Design Goals

Internet Scalability Properties

The Internet is the greatest advance in human communication since the invention of the Printing Press, and all applications which run upon it have certain distinguishing features. We assert that for VWs to become industry changing platform for human communication on the Internet, they must first acquire those properties.

1. Open: the system imposes no artificial bounds on the number of nodes that can join the network. It is interoperable.
   • Open specification, with an open-source reference implementation.
   • Specification should be able to evolve to meet the needs of all stakeholders over time.
   • Use existing standard networking protocols when appropriate.
   • Define means of adding well-behaved nodes to the network, and allowing information to move among nodes.
   • Enable interoperability amongst its nodes, and amongst existing applications such as Web, E-mail, and IM.
2. Decentralized: the system should never rely on a centralized point of control. It plays no favorites.
   • Nodes are governed at the edges. No central bureaucratic entity should control the functioning of the network.
   • Content is created at the edges. Any node is capable of publishing any content in a policy free manner.
   • Ability to arbitrate contention between nodes in a policy free manner.
3. Scalable: the system must be able to handle loads appropriate for a world where almost every human has a connection. It doesn't degrade unacceptably under load.
   • Caching and Load Balancing is built into the system.
   • Tolerance for failure is built into the system.
4. Dynamic: the system does not hard-code policy or other assumptions
   • Semantics are simple, modular, and extensible.
   • Accepts a wide range of input data and events, from a wide set of formats and sources.
   • Data model is exported using a robust scripting API.

Distributed 3D Virtual World Properties

A lot of things go into making this next generation platform.

Distributed

• Delivers acceptable scene coherency, so that all users are able to roughly agree on a shared perception of events; so that it delivers an acceptable user experience.
• Not require excessive bandwidth; for those internet users who must pay directly for their bandwidth.
• Facilitates and encourages a growth of user-specific grids that are freely able to establish their own policies.
• Provides a mechanism for negotiating changes in policy as users cross grid boundaries.
• Provides a mechanism for negotiating copyright policy of assets as users cross grid boundaries.
• Provides a security model capable of preserving the integrity of user assets and executing code.
• Provides a security models capable of reserving a subset of permissions to a subset of users over a subset of virtual locations.

3D

• Behaves as a general purpose 3D simulator, with fully functional physics, animation, scripting, and data formats support; so that it is useful for niche stand-alone applications.
• Delivers acceptable frame rate and latency under load; so that it always provides an acceptable user experience.
• Accepts a wide variety of asset formats for 3D geometry, images, video, sounds, animations, and scripts.
• Support gatherings of small or large numbers of avatars, from one-on-one communication, to large public displays.

Virtual World

• Provides a means of building a social network of avatars, and is capable of interconnecting with existing social networking sites.
• Provides a means of enabling text chat with other avatars, and is capable of interconnecting with all existing IM protocols and applications.
• Provides a means of enabling voice and video chat with other avatars.
• User interface should be easy to understand and manipulate for a wide class of users.
• Uses spatial and visual intuition to enhance communication.
  • Supports level-of-detailing and attenuation to help filter communication volume
  • Animations and Icons deliver non-verbal messages
  • Facilitates easy expression of behaviors and emotional states

System Properties

In order for such a platform to see wide adoption, it needs to be first implementable, and second adaptable to prevailing market conditions.

• Should run on a wide range of available hardware; from small devices, such as cell phones and appliances, to dedicated workstations.
• Should be modular, to allow the flexibility to adapt to new platforms and new use cases.
• Modules should be encapsulated from the rest of the system, so that they can evolve or be replaced independently without affecting the whole.
• Should be open source, to allow the creation of a common, equal, and flexible platform for all firms and individuals to use and innovate from.
• Should be extensible, so that it can evolve as technology and usage patterns mature.
• Should be built with comprehensive community involvement, so the design reflects the needs of all stakeholders.
• Should not be a paper standard. It must have a working implementation.
• Should be designed for the future, but should be able to be implemented now.
• Reuse existing standards and implementations as much as possible. Where an existing technology does not provide what is required, it should be adapted, in preference to rewritten.

Why Open Source

Economics of Platforms

• platforms are not the application itself and do not directly generate profit
• platforms create networks of users, and thus benefit from increased adoption according to Metcalfe's Law
• new entrants are subject to vendor lock-out, as changing platforms means losing applications

Therefore increasingly the only strategy for creating a world-class de-facto standard for any platform is through open source. Giving away the razor to create a market for your blade.

Industry Cooperation

Open source is a proven way to do more with less, exceeding your singular capabilities by harnessing the collective skills of a number of cooperative parties around the globe. It provides a framework over which otherwise competing companies can cooperate in a fair way. In many respects it's the only way small companies, or small groups within larger companies, can hope to accomplish anything significant.

Open Source in Practise

However open source is more than a license, it is a way of thinking and acting while developing software. It means that an altered work-flow in order to encourage growth of a community.

Communication

• The community must know what you are thinking, planning, and doing. This gives the community the opportunity to formulate their re/actions to changes in the project, and let you know if they have a better idea.

• Significant changes or features must be proposed semi-formally on the mailing list before hand for limited discussion. The process also serves as a form of project documentation and history. (See Python PEPs)

Participation

• The community must be given the chance to participate directly in decision making, otherwise they will feel disenfranchised and used. This means something of a loss in autonomy for realXtend, but is really nothing more than extending the consensus process we already use to make sure everyone internally agrees on a common plan.

• This doesn't mean a loss of focus for realXtend. When you begin inviting participation you must outline a set of fundamental principles, and make participation contingent on agreement with those principles.

• The community will eventually have commit access to the repository.

Governance

• Decisions are fundamentally based on meritocratic principles. It is not a democracy. It is not an aristocracy of core contributors.

• Decisions must be based on a consensus model. A large majority of agreement must be arrived at in order to proceed with controversial decisions. Occasionally some decisions may be forced through by a "Benevolent Dictator", but that power should be used sparingly, and at last resort.

• Everyone must be prepared to formulate and clearly express an argument to support their ideas, present them to the community, and be prepared to concede defeat to a better proposal.

• Responsibility to commit is based on a trust network. At first only the top programmers from within realXtend are trusted. They in turn give out commit access based on their trust. Eventually when community members have proven trustworthy, a trusted developer may choose to trust them. However if there is a mistake, it ripples back through the network, and may result in removal of privileges. Trust must be handed out carefully.

Support

• When someone starts on a new code-base, they have a lot of questions and problems. At first it may seem like time sink to help answer their questions and debug their problems. However it is a long-term benefit to the project because those people often mature into productive community members, and will in turn help others.

License

The where realXtend owns the copyright to code used in this project, the license will be Apache 2.O License.