Last update: Sept 14, 2009
This page describes the functionning of the WEM (World Entry Management), which is the whole set of systems which will allow an user to connect to a virtual world of his choice, and then to teleport into any other world, while keeping his identity, his virtual appearance, his objects, and all what is needed for his virtual life.
So the WEM includes a set of standards and technical devices, but it also implements some built-in protections against the classicals abuses of the Internet and virtual worlds: copyright theft, harassment, spam, identity issues, etc.
It does this in a non-dual way with the preservation of freedom of expression and the respect of the persons.
Many technical choices being dictated by these human, see legal matters, this description will entangle technics, usage, discipline and laws, part per part. The actual plan will rather follow the steps of a connexion, some parts arising more issues being more developped.
The WEM is in the same time a connexion protocol, a monitoring system, a philosophy, a set of softwares (browser, connectors...) and a set of organisations (Character Hosting Companies, worlds and platforms, Management of the du WEM...)
On this page:
Definition of the WEM protocol
Architecture of the WEM browser
The Authorizations management connexion
The safety issues
Safe developing of the software set
The Character Hosting Company
Le Register of the Character Hosting Companies
Functioning of the WEM
Entering the world
Travelling into the world
Copyright and ownership management
Interoperable communication between simulators: the Kailie language
The 3D rendering
Fast communication with the NRMP protocol
Related page: Moral charter of the Character Hosting Companies
and of the WEM management
Related page: Intellectual property statute of the WEM architecture,
elements and future versions
Friday September 11, at 12 PM SLT: Conditions and tools for virtual worlds. Place: The Shedrupling University, in Andraca/248/202/50/ (If you have a Second Life account, this link will lead you to the place. Otherwise you will have to click on the orange button, top right of the page, to install the software and open a free account. Don't wait for the last minute, you need several hours to have the system in hands)
The very idea of the WEM is to use the Internet as it is, without a need to modify the networks and routers. But, due to the complexity of the 3D exchanges with a virtual world, it is much better to split the load between several different specialized connexions, each with their own purpose and appropriated protocol, such as http, mail, stream, etc. So the WEM is rather an upper layer on the existing internet system, overhauling as only one entity a set of several different connexions. This one entity is called here the WEM metaconnexion.
Basically the WEM engine is a software module at the heart of the 3D viewer, in charge of starting or shutting down all the devices of the viewer and all the connexions. It will ask to the virtual world which connexions are required, maintain a list of open connexions called the WEM Connexions Register, and actuate accordingly the data routes into the computer, so that all the devices in the viewer can communicate with appropriate addresses in the world or in the Internet at large.
The WEM is intended to be a free protocol available to all, just as were Internet protocols such as the http. This is to ensure that similarly we shall obtain a fully interoperable system without any monopoly or blockage. On the other hand, it is likely that many simulator systems will appear. But all can work with a standard viewer, provided that they use the same protocol.
For this reason this text itself is protected under a GNU GDL license. It is also a proposal for the W3C, which is the recognized authority for the evolution of the Internet, by keeping it normalized.
The rationale behind the architecture described here is interoperability, safety, ease for support and evolution. But there is another reason: Some childish companies may start a protocol war, and launch their own WEM2 incompatible with the WEM described here. If such a thing happens, free implementations of the WEM engine just have to immediately add the WEM2 system, in order to remain compatible with all the worlds. So there is no real interest to start a protocol war, as nobody will use WEM2 viewers giving access to only some worlds when WEM viewers give access to all. However the most likely winner in a protocol war will be the one offering worlds with the best variety and quality, together with properly implemented basic features and all the set of conditions necessary for a good virtual life.
We could wonder why not to use the Second Life protocol, which is open source. There are several reasons for this, especially that it is already used for dishonest purposes into hacked viewers. For the same reason, it may be necessary to modify at times the functioning of the WEM, and the communication protocol of Second Life already falls under this necessity. But nothing forbids to add to the the WEM engine new modules emulating peculiar protocols requested by some worlds, and thus the WEP viewer would become virtually universal even if a 3D Internet which would not be.
The viewer is built around a module of software called the WEM engine, around which run various other modules called devices, such as the 3D rendering, the chat system, the menu manager, the navigation system, etc. All these elements are independent executable files, which can be each of a different developer. New types of devices can be added at will, in the future, for instance smell synthesizers, simply with adding a file in the devices directory.
When we start the browser, we in fact start the WEM engine, which in turn will start all the modules it finds into the devices directory.
Once started and connected, devices run independently of the WEM engine, and do their job until some modification is requested in their connexions. This allows for separate evolution of devices, and also for multiple sources of devices.
In the WEM engine, the logic which starts or shuts down each device receives inputs from the user, the world, and the WEM engine itself. For instance the 3D rendering is started automatically by the WEM engine, the chat is started on user request, an object in world sends a request for a gift, the audio stream device is shut down when the character enters an area with no audio stream, etc.
The WEM engine manages all the connexions between the viewer's devices and the various services in the world or in other parts of the Internet. It can start connexions automatically, or receive connexion request by the devices in the viewer or in the world.
Each connexion has a protocol, and each protocol is a implemented in a communication device, called here a plug, of which many instances can run simultaneously.
When it starts, the WEM engine establishes data routes between plugs and devices, into the computer memory and bus. It is to be noted here that the WEM engine is the only part of the viewer which requires adaptation to the many configurations of computers (multiple cores, graphic card processor...). So the installation of the viewer software should adapt automatically the WEM engine to the computer configuration, setting devices and plugs in appropriate places and determining best data routes.
On the other hand, devices and plugs run each on a single core and its local memory. This makes that no adaptation is necessary to a given computer architecture, and these elements can be developed with simple tools and are easily portable, without the complexity of multi-core programming (because this complexity is managed by the WEM engine).
For ease of modification and adaptation, devices and plugs must all be independent executable files, stored into specific directories. When the WEM engine starts, it loads them in appropriate memories, and sets the data routes. The WEM engine itself is an executable file, the one which is started when we start the viewer. This allows for very simple upgrading of the viewer, with just adding new files and automatically downloading them. There is no need for a global rewriting and extensive testing of the viewer at each minor modification. This also allows for easy custom modifications of devices. The WEM engines must include APIs for all popular languages, in order to easily create new devices recognized by the WEM engine. When starting, the WEM engine will automatically try to add to its device list or plug list all the files present in the appropriate directories, and ignore those it cannot recognize. This way is very simple to work with, even by persons with poor computer skills.
A world may request to add devices in the viewer. This can be made by automatic download and acknowledgement to the WEM engine. However this practice arises quality and safety issues, and if should not be authorized without any control.
When starting, the WEM engine first establishes a connexion with the Character Hosting Company of the user, where his authorizations are stored. It then connects to the server hosting the world. This first connexion is triangular, it is the Authorization Management Connexion. Here are dealt all the safety issues and authorisations of the user into the world, so of course it uses a tight secure protocol.
Its main purpose is to compare the authorisations of the user and the requirements of the world (for instance age and sex flags, disciplinary ban of a world, etc.). This comparison will result in an agreement of entry, a denial of entry, or actions such as adding clothes or giving warning messages.
Access rights are thus assessed between the world and the Character Hosting Company, because a viewer can always be tampered with false authorisations. But it is the viewer which sends the requests and receives the authorizations or denials (with their motive). From here the triangular link.
The Authorization Management connexion must always be open, as It will have to recheck authorizations at each teleport. In this way we can say that a WEM metaconnexion is present or not present, depending on if the Authorization Management Connexion is present or not present. So that we can also use the Authorisations Management Connexion to send all the trivial service messages, connexion requests and negotiations. The Authorization Management connexion is the control connexion.
Griefing and varied abuses using anonymity or hacked viewer software are the main problem in Second Life, and the main limitation into the enjoyability of virtual worlds. So we must from the very beginning have a tough safety policy and no-loopholes methods.
Safety concerns make that no salvage connexion must exist between a device in a viewer and a world. Such salvage connexions may be used to send spam which sender could not be found. So the WEM engine in a world must accept only connexions which are requested or acknowledged by the WEM engine of the viewer, which are traceable to a character, and approved by the Character Hosting Company. So all connexions will be triangular. Even the connexion to the bank of a money management device must be acknowledged by the WEM system and the Character Hosting Company.
Direct connexions may exist between users (chat, messages, exchange of objects or documents). In Second Life it was a constant requirement from business people to have these behind a firewall, so that other users or the world owner could not spy on them. (This demand was never fulfilled, explaining why there is no companies or administrations in Second Life) Direct user to user connexions offer much more safety, as they don't go through the world. But their existence must be acknowledged by the WEM system (to avoid, for instance, untraceable spam). Teleconference systems already used by companies just need to appear as devices in world, which will request and manage such safe connexions between users, through the WEM engines of each viewer.
These requirements make that the WEM engine must NOT be open source. It must be edited and modified only by a strictly controlled panel of professionals and counsellors. There is anyway no need for world designers to edit it, as it is only a communication system, transparent to the user and not involved into world design itself. But of course full freedom must remain for world developers to add legitimate devices in their worlds, in order to enrich the simulation and its possibilities.
A special device will be for money management. The bank of the user may provide its own. This will allow for direct use of real money in world, in place of needing a virtual currency. But this must not forbid virtual currencies.
In short, worlds have more rights than users, and Character Hosting Companies automatically arbitrate them in a neutral way. In case of persistent disagreement, matters must be brought to human judges. World owners however have full rights on their creations, through their viewer. They also must be able to add connections between devices in their worlds and varied internet services. Abuses by world owners will usually result in users fleeing and recreating their project elsewhere, but severe cases may be prosecuted. In this case only the Character Hosting Company will be able to bring reliable evidences.
Animations (series of predefined movements or actions) can be files read by a device in the viewer, or selected into the world.
(This paragraph was revised in Sept 10, 2009) Automation (intelligent decisions by a software, without immediate control by a human user) makes of the character what is usually called a bot (robot). Robots are very interesting and necessary elements of the metaverse, but they can also be used for many kinds of abuses, mainly by trying to make them appear as human users. More subtle cheats would be things like adding extra reflexes to an human user. From here the need for some controls. The most common is that the viewer (the WEM engine) sends a robot flag, to tell the world that the character is a robot. For an external software to take control over one or several devices of the viewer, requires that the devices have APIs for all common languages. So, when a device receives controls on its APIs, it automatically sends the robot flag to the WEM engine, which sends it to the world, and maintains it until the WEM metaconnexion is closed. In this way, cheats become traceable. But for this to work needs that there must exist no hacked versions of the WEM viewer.
(This part was separated of the previous on Sept 10, 2009, revised and brought to a more conclusive end.)
Many will ask for devices being open source, to allow for a variety of implementations and custom modifications, device per device (one device per function, such as 3D rendering, chat, etc.). However such an openness may be a source of severe problems with tempered or bugged devices. Hacked versions of the Second Life viewer allowed for many abuses, including sophisticated tools for stalking or copyright theft. So there are strong safety arguments in favour of not releasing the devices algorithms and the APIs of the WEM engine.
The same is true for plugs, except that there are no needs for modifying well working plugs. Anyway plugs are under control for quality and safety.
A good point would be that device files have coded WEM device identification labels, that tempered devices could not provide. Then the WEM engine would send reports to the Character Hosting Company, on the devices used by a viewer. This private data may be of use in case of a law suit on misbehaviours bringing suspicion of tempered or hacked devices. Also the whole WEM system could receive security alerts and block devices with given identification labels.
Another good way to avoid tempered devices is that the interfaces (API) of the WEM engine are kept confidential, and changed when problems arise, forcing the re-download of all the viewer software.
There can exist several implementations of the WEM engine itself, but all under strict control for safety. Public test suites must be provided for the users to control how their devices and WEM engine work, as for the Acid series.
Anyway, again, there is no need for both world designers and users to modify the viewer, once it works properly. It is a breeze to adapt to a (good) viewer, compared to the hell of managing a herd of many viewer versions. Never again the HTML browsers war! (the today (2009) anarchy is not better, where we must adapt to a new version every three months!)
It would be much better for safety, and the most sane economic model, that all the companies involved into virtual world hosting and design may fund a single entity developing an unique viewer, but as best as possible (WEM engine and devices). In this way confidential safety data has much less chances to spill, rather than if it is present in many competing companies and workshops. But this implies that the managers of this entity are psychologically able to accept user's requests and critics to improve this viewer, or add options, without bringing useless upheavals at every new version. If they are not psychologically able, then really it is better to let them compete together under an effective pressure of the users.
So the solution proposed here is an Internet site where companies, or even individuals, wanting to develop or modify devices, could use compilers able to create devices files, working with the WEM engine APIs, without releasing these APIs to these persons or companies. These APIs appear as functions that the programmer can use, but not edit. Compiled devices files are at last recovered by the person, or distributed thanks to the automatic update system of the WEM browser. In case of a security update of the APIs, the file is automatically recompiled, and all the users who have it receive an automatic update.
This system allows for some open sourcing of devices, as any abusive feature is now traceable: the resulting compiled files would receive WEM device identification labels, for safety control. But these labels could also be used for statistics, and measure the success of a given version of a device. So we get a better innovation and a reasoned amount of competition, even in a unique and centralized structure, but still without compromizing safety.
On the other hand, world designers must be able to freely create software and scripts they need to run their worlds. In order to still remain into a safety approach, these software and scripts will communicate with the WEM engine of the world, only through a connector. A connector is a standard WEM device, dedicated to communication from all the scripts and software a world designer will have to invent, in more of the other standard devices provided with the WEM. It uses the secret WEM APIs, and also public APIs for software and scripts into the world. When such a software wants to interact with a user, then the connector establishes a triangular connexion between itself, the user and his Character Hosting Company. It sends to the later the private data on the identity of the world owner, or at least the URL of the world. So, in case of abuse, we can find who did it, or at least automatically block connexions or worlds which don't provide such information.
The WEM engine may also communicate with an anti-virus and other safety software, mainly for detecting tempered devices which could be used for abuse, spam, etc. The reason is that it would be relatively easy to create tempered devices, and install them or make unsuspecting users to install them. To twart such a devices control system, a delinquant would have to create a tempered WEM engine, a much more difficult task (multi-core, secret protocols, coded messages, frequent security updates...)
The very first thing a virtual world viewer does when starting is to connect to the Character Hosting Company, which is the 3D equivalent of a 2D internet access provider. Let us remember that one user (a physical person) has a subscription to a Character Hosting Company, but he may have several characters. We speak here of one connection of a physical person to one character. Characters must have a virtual federated identity, as soon as they are available and working properly. If not, the WEM system must at least propose one unique identity for all the worlds
The Character Hosting Company server stores all the elements of the character: the profile, the inventory of objects, the body shapes, clothes and attachments, texts, images, sounds, etc. It is to be noted that these elements are themselves 3D objects, so that the user may store them in a personal virtual scene offered with the subscription to the Character Hosting Company. Such a scene can be a personal virtual living place, but it can also contain a 3D storage offering on shelves all the objects to see. It is an open choice to have these elements on the local computer, in the Character Hosting Company server, in a company server or in any other safe vault somewhere on the Internet. Inclusion functions in the 3D description language will also allow to have this personal scene, on a given server, included in a wider world on another server.
However the main WEM function of the Character Hosting Company is to store the authorisations, rights of access, and pending disciplinary measures of the character. This must be on a neutral server, otherwise it would be much too easily tampered. Use of federated identity must make these authorisations portable from a Character Hosting Company to another.
This makes that when the viewer starts, it needs at the very first to establish the Authorizations Management Connexion, as seen above. It them needs to connect some devices to various services of the Character Hosting Company: splash screen images, HTML, RSS, chat, music stream, etc.
Added November 23, 2011:
A better and simpler way to manage identities and abuses is using the three levels of identity described in 12.5 - The name Kflags values, which are ~Physical (legal), ~character (social) and ~roleplay (in a game)
Within this system, any person has the right of having one ~Physical (legal) identity, which is public, and can be used for administrative purposes or public purpose. However, any person can also have an unlimited number of ~character (social) or ~roleplay (game) identities, which are by default anonymized: the connection with the ~Physical identity is governed by laws on private data. However, all the information on access rights, pending bans, etc. would be gathered by the Character Hosting Company under the only ~Physical identity.
So, when the person attempts to enter in a social place, or game, under one of his ~character (social) or ~roleplay (game) identities, the WEM checks this identity in the Character Hosting Company. The later checks about pending bans or duplicate access into the ~Physical (legal) identity, and send a «yes» or a «no» to the social place or game, without disclosing the information on the ~Physical identity.
This system avoids a banned person to re-enter under another identity, or a cheater to have several characters in a game, while not disclosing the ~Physical identity to the world owner. However this ~Physical identity can still be found by a court action.
Some will say that this system is exceedingly legalist or moralizing. To address this concern, we still can have ~character (social) or ~roleplay identities unconnected to any ~Physical identity. It is then up to the world owner to accept them or not, and ultimately to the world user to accept to enter in a world where he may encounter these. If so, he may be exposed to various abuses without legal protection. But experience shows that many people prefer this solution, rather than being constantly monitored. Others prefer to be monitored, rather than constantly abused.
As there will be several Character Hosting Companies, they need to communicate and exchange informations, in order to check the uniqueness of each user, or his disciplinary records, while protecting his private data.
But nothing can warranty that ALL the Character Hosting Companies will be as fair and reliable as required. We think at pirates creating a fake Character Hosting Company, using it to host griefers and delinquents, attack other users or the whole WEM system. But less visible threats are still more dangerous: governments, cults, companies, political parties or secret organizations may create or buy a large and well famed Character Hosting Company, and discretely control their members, or, still more subtle, use only a few number of accounts for delinquent activities. Add to this that Character Hosting Companies may be hundreds, hiding their databases in all kinds of countries with different laws...
This issue is not benign, and it involves redoubtable problems. There is no magical solution and no simple method which can wipe out all these risks in one stroke. In more, the whole topic takes the logical form of a Yin/Yang non-duality between safety and freedom, which makes that all forms of one-way thinking or ideologies are doomed to worsen things rather than bringing any relief.
So the proposal here is a set of two tools:
The Character Hosting Companies Register, which is a directory of all the Character Hosting Companies, holding records on their safety level and neutrality achievements. Any check on a given user will mandatorily start here.
As each Character Hosting Company keeps records of the private informations entered by each of its users, it becomes possible to automatically find for instance that two accounts are for the same passport number. Such a request send by a game may propagate world wide and find a cheater user in some minutes. In the reverse way, when a griefer is banned in one Character Hosting Company, this information will be passed to all the others, faster than he can open another account. However this makes of the Register a very powerful tool, and thus dangerous if it gets controlled by dirty hands, especially dictator's hands. It could be used, for instance, to trace refugees in other countries, or to systematically harm some categories of users. So this needs some cautions:
-Limit the ability of Character Hosting Companies with lower safety/neutrality records to do such requests.
-Do not expose private data into requests or replies. These requests are used only to check the uniqueness of an user, or his disciplinary records.
-There is no centralised databaseof the WEM users. There is even not an unique index or ID of the users. We must rather think at each Character Hosting Company as a cell in a tissue, where each cell is autonomous and has its own data set. Good cells are free to communicate together, but are wary of bad cells. So the WEM Technical management may more or less restrain the channels toward unreliable Character Hosting Companies. Of course these restrains are all gathered and indicated into the Register.
-In order to keep a plurality of opinions, each Character Hosting Company is able to add its own restrains.
-In the very end of the process, each world owner still has the freedom to decide which cell he can trust or not, in specifically blocking some Character Hosting Companies.
-Users coming from bad Character Hosting Companies have their identity checking level lowered. But on the reverse, users who are victims of dictatorship or other government abuses, may get a special protected statute, allowing them with a good identity check without exposing their privacy or actual location.
But this is still far from perfect, as a tempered Character Hosting Company may for instance spread false disciplinary records in order to harm a person or a category of persons. This, and other cheats, are beyond the possibilities of an automated control. So the second tool is:
The WEM Technical management, which is supervised by the International Virtual Worlds Management Council. The first body has for function to ensure a smooth working of the Register and other WEM systems, facing routine issues such as failures, attempts to break or control it, etc. The second body has for function to check for emerging Human Rights issues, or to take extraordinary decisions for «situations which must not happen», such as attempts by a legal power or government to abuse the system.
When it starts to connect, the WEM engine must produce a list of necessary connexions (It can propose some, and the Character Hosting Company may propose others).
This list is in a small database, the WEM Connexions Register, containing, for each connexion:
-the device requesting it
-the protocol (http, stream, RSS, mail...)
-the memory info on where the involved instances of the device and plug are
-the destination address (URL or world device identification).
-service flags (active, idle, closed but available at once for other uses without having to re-load it from the hard drive)
-error flags, that the concerned device may display to the user.
All this must be in human readable form, for easy dumping and troubleshooting.
The main function of the WEM engine is to update the WEM Connexions Register, with adding new connexions in the list, or closing others, depending on needs or requests for connexions or closure.
Then the WEM engine actuates the WEM Connexions Register. This means that it will place or delete instances of plugs and devices into the memory, with their data routes.
At last the devices and plugs start to run independently, connecting to the address they are indicated and managing this one connexion.
The WEM engine is now idle, but ready to accept new connexion request of looking at dead connexions to close them.
After connecting to the Character Hosting Company, the user chooses which world he wants to enter.
Let us remind here that all worlds must be identified by the same Unified Resource Locator (URL) system already used in the 2D internet. Just some fields have a different meaning, for instance the «path» corresponds to the hierarchical structure of the world content (grouping nodes of the VRML). This is also true for all secondary resources used, such as inventory, audio stream, etc. The URL of the world is used to define the WEM metaconnexion. It can be used to establish the Authorizations Management Connexion, which address will start with «wem://». The 3D content can also use the same URL, as it will be in a different non-secure protocol, and so it will start with «http://». Other connexions to devices in this world use the same URL system, but with a path and file name identifying the device they should reach. Other connexions, such as for instance an audio stream, will use their own URLs in other places of the Internet.
Also we must be able to combine 3D elements of different sources into the same world, by a rational use of coordinate origins and scales. This is the case for the body shape, stored by the Character Hosting Company, away of the world itself.
Connecting to a world is done using the Authorization Management Connexion. When entry right is recognized, the world server must send to the viewer the list of connexions it needs to establish. This list is added to the WEM Connexion Register of the viewer, and the WEM engine of the viewer actuates them. When these connexions are established, then the devices into the viewer and devices into the world run normally and exchange messages, using mostly http, streaming, IM, mail or others. The character is now into the world!! And the WEM engine gets idle, just waiting for connexion requests or closure requests.
New devices encountered into the world may request new connexions.
Teleportations are to the 3D internet what hyperlinks are to the 2D internet. When a teleportation is requested, toward another world on another server, the WEM engine of the viewer has to re-check for authorisations for this new place. This must be done BEFORE the attempt to teleport, and in case of a denial, the user must be informed, with the motive. Only after authorization is granted, the WEM engine has to update and actuate the WEM Connexion Register, establishing new connexions, and shutting down dead ones. This realizes the teleport.
To actively clean up dead connexions to devices may be a necessary requirement, for instance to avoid draining simulator power for a visitor who is gone, or a device which has become still. This also occurs when for instance the character moves away from a streaming sound source: beyond some distance the connexion to the streaming service has to be shut down, and the device and plug used to something else. But also, connexions can be unexpectedly severed by technical failures of the internet. So a non-responding connexion may also be assumed dead and shut down. However, in this case, the user must be warned, and a system may try to create another connexion with another route. High reliability worlds may propose backup connexions as soon as the first connexion, into the Connexion Register.
(Modified in Sept 11, 2009) Also, as the character moves in world, he may go unaware through an invisible boundary, where the content is hosted on a different server far away on another continent. This situation is a frequent source of severe problems in Second Life. The WEM addresses this situation with the possibility of having several connexions running simultaneously toward different servers, as the list of WEM connexions can be extended at will, on the fly. So, thanks to the correspondence between URL paths of objects and their geometric hierarchy, we can easily combine objects or landscapes of different sources into only one scene. Just devices of the viewer must be able to handle multiple connexions, at need with several instances of the plug. On the simulator side, this situation is adressed with the Kailye interconnexion system and language, which allow neighbouring simulators to interact on each other or to combine their objects.
Another invisible boundary type is between zones where different authorizations apply. Such authorisations can be many, such as not using scripts, not rezzing objects, behaviour limitations, no fight, no nudity, etc. They can result of varied conditions, such as group belonging, disciplinary issues, age and sex tags, etc. Authorizations can also apply to parts of the character, for instance entering a no nudity zone automatically adds clothes, to avoid embarrassing situations to arise.
These situations are the reason why the Authorization Management Connexion must run all the time. The checks must also be completed before a teleportation starts, or before entering a new zone, to avoid blunders or incidents, voluntary griefing, or bugs such as a character being pulled back. This requires some anticipation: when the character approaches a boundary, or a teleporter, or when he selects a landmark: the authorizations are checked and translated into geometry limits the character cannot go through, as of an invisible wall. No trespassing must be possible before the authorization is received.
Some world owners may prefer to manage themselves the authorizations, for instance to have their own group list or ban lists. Such systems may be tampered or abused by the world owner. But they can be tampered anyway (for instance declaring a sex place as open to children, or very simply by arbitrarily banning people they don't like), so this can still be an option left to world owners. No more than the user the world owner is expected to be a saint. Just Character Hosting Companies are expected to be neutral.
Anyway the user must always be informed when a trespassing or teleport is refused, of who took the decision, and why.
Uploading 3D objects or elements such as textures also opens a connexion to the local computer.
Exchanges of objects between users may need to open a temporary connexion, which may be of several types.
The experience of Second Life demonstrated that it is important to ensure respect of ownership, together with respect of the various copyright licences, with specific tools forbidding systematically any illegal replication or transaction. More, facing the astounding amplitude of piracy on the 2D Internet, it is very clear that appropriate measures must be taken from the very beginning, so that such a situation will not happen again in the 3D Internet, where soon most of the art files exchanges will take place.
(Added Sept 11, 2009) So the solutions proposed here try as well to prevent or trace fraudulent downloading or duplicating of files, but also to provide authors with legally opposable evidences of their first ownership. But an important thing too is that the WEM is for everybody, not only for large companies or «majors», so that the solutions proposed here will provide small or independent artists with exactly the same tools and protections.
What follows can apply to full objects, or to elements such as textures and images, sounds, complex 3D shapes, texts, software, etc. These elements must be archived each in an unique and safe place (more safe copies and caches), where property rights and copyright will be traced, element per element, object per object. This is a Copyright Server. Copyrighted objects will be downloaded from Copyright servers, and nowhere else. So all protected element are available in this place, whatever it is for free, subscription or buy, downloading, streaming or channel, but always to the condictions edicted by the rights owner, and any other source is clearly illicit.
We can think at an unique identifier for each copyrighted element or object, even if these elements are included into millions of objects into the whole 3D Internet. This identifier will feature a fixed and unique radical, dated. It will feature a prefix telling in clear text its URL into the Copyright server, where to fetch the element. The identifier will also feature suffixes telling the copyright owner, the licence type, etc. As these affixes may vary, it is enough to remove them to find back the unique identifier for each art work. When instancing or duplicating the object, an unique instance identification is added.
The access to the Copyright server is done with a WEM plug, probably in HTTPS, while indicating the name of the character requesting the element. This system can also be used for the 2D Internet, and even to buy elements. The name of the character is then added to the list of owners, on the copyright server.
We must however keep in mind that, from the very nature of the 3D immersion, users who are not owners of the element will be led to see or hear it, and thus to download it into the cache of their viewer. And a pirate will always be able to copy these elements from the cache of the viewer, see from the memory, with a pirate software. The element will soon freely wander on the Internet.
To thwart this, several palliative cautions may be thought at:
- A secret marking into the image or sound files, with the name of the copyright owner, most often the person who uploaded it. So it is easy to tell precedence, and to find the person who re-uploaded the element on a server.
- Store proof files on the Copyright Server with a good quality, and send on Internet only degraded and watermarked versions. Then, even if a pirate put them into a physical form, and then re-digitalize them, we can still find to whom they were stolen, with comparing them with the proof copy.
- Use DRMs. This solution was sabotaged into the 2D Internet, with the refusal of interoperability. This however was an obviously mandatory condition, as people like to copy their files into several computers or readers. However this problem does not arise with the built-in interoperability of the WEM, as the objects are non-local, each downloading their elements at the same source, and seen with the same viewer.
- A log of transactions allowing to find fraudulent vendors or distributors.
- Analysis of the Copyright Server logs can trace objects which download copyrighted elements they should not.
However more radical measures can be thought at:
- Merge all the copyrighted textures into one meta-texture, which is the only one sent to the viewer. We can now scramble this meta-texture, rotate and scale each face differently into the texture map, so that to recover a copyrighted element is more work than creating one. We must however think at re-loading only the modified parts of the meta-texture, when a new texture appear. To be noted also that a world owner cannot either recover the unscranbled texture, as he too receives it scrambled from the copyright server.
- Do the 3D rendering computing into the premises of the Character Hosting Company, and send only a video to the user's viewer. This is called the plain WEM architecture, by opposition to the classical reduced WEM architecture, wich performs the 3D rendering on the local computer. This will be possible in some years, at the expense of a larger bandwidth consumption. This solution basically eliminates any downloading of copyrighted elements, so it may prove afterwards less costly for everybody. It also allows us to get rid off ever changing graphic cards, archaic 3D rendering libraries and bad operating systems. This will also present the same rendering to everbody, whatever the system or budget. At last it will open virtual worlds to portable or low power computers which are the trend into the future.
- (Added Sept 29, 2009) The copyright server sends the sounds in streaming with a variable and unpredictable sample frequency. This does not harm quality, but any attempt to record the work in a file (or resampling the analog output) produces a frequency beat which makes appear a parasitic sound (the frequency modulation). This sound can be an anti-pirats message, or any other noise suitable to make the record impossible to enjoy. A similar process could make appear tell tale texts into images, textures or videos.
- Of course the WEM will have to exclude any site or protocol specifically designed for piracy, such as the P2P, bit torrent, etc.
This list of protections is not limited, given the adaptivity of pirates. However technical solutions can all be more or less made ineffective. The resolution of this problem will pass through law, and by the denunciation of the reactionary ideologies of egocentric «freedom» which appeared into the 1980 years. That, at last, piracy will not be considered as normal by the majority.
(Added on July 25, 2009)
It is unlikely that everybody agrees on an unique simulator, with an unique language for describing worlds. So we need from the very start a capacity for interoperability between different languages and simulators. A second reason is that different simulators will have to animate neighbouring regions of the same world, in sight of each other, without speaking of characters served by their hosting company, or objects presented by a copyright server, etc. We shall then have to render objects belonging to different systems, written into different languages. A third reason is that a static description of the world must be complemented by unpredictable movements of the various objects or characters. So the simulators have, implemented internally, a mean to describe these movements. But each simulator will also have to inform the other simulators of what it is doing. The purpose of this sub part is to solve these two problems with a proposal for a standard for exchanges between simulators, the interconnexion language Kailye.
The very first requirement is that the scene is perceived by everybody in the same way, except for transmissions delays. Even if it is buggy, everybody must see the same bug. For this reason, scripts and animations must run in world, on the simulator, and not into the browser. This is especially true for fast animations such as dance or fight, but also for random generators of elements (trees to go around...) or events (waves to surf...) which must give an unique scene for all. For the same reason, the actions of the user must be first actuated on the simulator, and then the actuated result, whatever it is, sent to the browser. A given scene must be calculated only in one place.
However we cannot sent to the browser an actuated scene for each frame. Thus the simulator will calculate for object objects its trajectory, which is a prediction (and technically an animation, of a series of predefined movements). The simulator will use these trajectories for its own purposes, but it will also send them to the other simulators, so that each simulator could account with what the others are doing, especially near the boundaries. But especially it will send these trajectories to the browser, under the fort of animations running into the browser.
But if an unforeseen event happens, such as an action of an user or a script, then the already planned trajectory must be modified starting from a given date: it is an inflexion point. Then the simulator calculates a new prediction, which is sent to the other simulators and to the browser. This new trajectory crushes the previous, starting from the date of the inflexion point. All the fineness of the simulation will thus be the ability of the simulator to actuate these trajectories in a fast and realistic way: easy walk between walls, machines obeying the laws of mechanics, ball bouncing differently depending on the sport, etc.
To clarify this vision of trajectories, we can compare with the «interpolators», which are the animations of the VRML/X3D. Interpolators are written by the creator of the world, and they contain a series of coordinate called key points, coming the ones after the others in a relative time (from 0 to 1). They run on the browser, starting on request, for a duration set by a timer. Then the browser interpolates at each frame between the key points. The Trajectories would work in a similar way, but they are created on the flight by the simulator, without any action of the world creator. In more they are in absolute time, and never stop, even if the object is motionless. So the browser and the other simulators will be able to receive series of key points into a circular buffer, where future values will crush the past ones. Each key point (inflexion or not) will feature an absolute date and coordinates (or a speed, an acceleration, see the derivate of acceleration). So we could get trajectories of movement, rotation, colour, texture map, deformation, scalar, command parameters of NURBS, etc. The same system can also be used to send texts, logical states, etc. For instance a door will have to open at a given date. Generators of random elements could use the same system: to send only the seed numbers and run on the simulator with the same results as on the simulator. The important point to get is that, even if each browser (and other simulators) runs the trajectory locally, there is only one place where this trajectory is calculated. So we have an unicity of views, as long as the connexion is not severed.
So the problem we have to solve can be summarized into sending to the other simulators and to the viewer the description of an object, accompanied of the planned trajectory. Why not to make the two into only one message.
The first standard to establish is about naming the objects («object» here is to me understood in a wide variety of meanings, including landscapes, characters, scripts...). It must be done with an unique identifier. However such a naming system automatically providing a unique name for each object already exists: it is an URL. An URL is a character string including:
Http:// A protocol to fetch the description (can be any)
met.domaine.extension as for the 2D Internet, but «met» plays in the metaverse the rôle of the «www» in the Internet.
/path/ is a path into the directory system of the server which hosts the object, which matches the geometrical hierarchy of the object (grouping nodes of the VRML)
file is the name of the object, which includes a unique creation identifier, the description of the copyrights, an instance owner identifier.
.extension should be enough to tell the description language, without having to open the file to read mime types. The later can be indicated as a parameter.
?Parametre1=value¶metre2=x,y,z... tells all geometrical or physical data of the instance of the object: coordinates, state, position of the joints, human readable name, etc.
This name is an URL, which tells where to download the description of the object. After, .extension tells to the browser which parser to choose, object per object. Then for each object, whatever the server of the language, we know where to get it, and which parser module to use. So we can have all the possible mixing, object per object, system per system, server per server, and boundaries between different systems are no longer a peculiar case.
The second standard to establish is about the format of the trajectories. They are basically tables where time is the index. We must provide a mean to tell if the key point is the position or one of the derivatives. Even if we use derivatives, it is good to reset the position at times.
The third standard to establish is about a language for exchanging messages between simulators. Example of messages:
«Simulator 1 to Simulator 2: A character is coming into your landscape according to this trajectory.
«Simulator 2 to Simulator 1: There is another character at such place, you must change the trajectory following this inflexion point.
«Simulator 1 to Simulator 2: Done, here is the new trajectory.
«Simulator 1 to Simulator 2: Can you handle this character?
«Simulator 2 to Simulator 1: No, there is a party in my premises and I am already quite laggy.
«Simulator 1 to Simulator 2: then give me the URL of your landscape.
«Simulator 2 to simulator 1: Here it is.»
This example clearly shows that each message will include:
-The name of the simulator which sends it, which will be, here again, its URL.
-A message ID, containing a time stamp
-The name of the concerned object, as above, which is, again, its URL
-The trajectory of the object
-A command telling the purpose of the message: question or reply, modification of the trajectory, handling, sharing of tasks, adding or suppressing an object, etc. Possible evolutions of the language will happen here, with the addition of new commands, different or more global.
The name of the simulator, as any URL, will begin by the protocol to use, which then does not need to be the same for everybody. We can think to a format like instant messaging, but much faster, directly connecting the simulators together.
Manoeuvres such as placing a simulation besides another can be achieved using Kailye messages telling to each simulator the coordinates of the other. This is also true for teleporting characters, mobile homes, spaceships, etc. into another world. We can even easily implement things like stargates or portals.
In facts the Kailye would be an extension of the static description of the world, accounting for unpredictable events and movements. This system is infinitely more adaptable than the classical animations of the VRML.
It is quite clear that no serious interoperability can take place without such a standard. But also, once it exists, the systems which will refuse to comply will be quickly chucked out of the Metaverse.
(Added on July 25, 2009)
(For the reasons seen into the above part on Copyright and ownership management, it is much better to compute the 3D rendering on the server of the Character Hosting Company, a method called plain WEM architecture. Thus, copyrighted elements such as sounds, texts or textures, go directly from the Copyright Server to the server of the Character Hosting Company, without passing through a third party simulator which may be modified by pirates. This gives to this server the statute of a full fledged simulator, le Character Simulator, centered on the body ot the character, but which may also contain objects belonging to him, see a personnal world in the way of Google Lively. The adaptivity of the Kailye then allows this Character simulator to interact witht he other simulators, when the character enters a world. However, for understanding, we shall continue to say «browser» to speak of the Character Simulator. It is enough to transpose. This was added on July 25, 2009).
The Kailye will also be useful as an interchange format between the browser and the simulator. As a matter of fact, we cannot actualize the movements at each frame of the browser. But it is enough to add a trajectory to the description of the object, which will run as an animation into the browser. However these animations are calculated by the simulator, in a way unique for everybody. They will be modified only when the simulator adds an inflexion point.
With this system, the browser knows the protocol and language for each object, so it is able to download each object wherever it is, and choose the right parser.
These different parsers will then have to agree to write into an unique memory space for the description of the scene. This is an important standard, however it is specific to the considered WEM browser. This memory space being used by different parser modules, eventually written into different languages by different teams, its description must be available under the form of a library in several languages, in object programming. Care must also be taken that one parser doesn't crush the writings of another.
At this step, it is no longer a matter of text languages for describing worlds, such as the X3D, but of a description coded in a machine readable form, and specific to the considered browser. However we shall still encounter here several types of objects: meshes, NURBS, lines, points, primitives, 3D textures, fogs... that different modules will compute and write into the Z buffer and into the video memory where the 2D image is being built. So we similarly need the description of this memory and how to write in. Having several modules able to use the Z-buffer and video memory simultaneously also allows for more multi-core computers or adaptations to graphic cards. The collection of modules able to write into the video memory will make all the flexibility and wealth of the 3D rendering of the browser.
For these reasons the Kailye should be a part of the WEM standard, even if it is possible to let it evolve independently.
Standards like the WEM and the Kailye described here are the key, as nothing will be possible without them. But also, once created, they will be difficult to modify. So it is important to test them, and prepare a versions system, which will have to be used sparingly, to correct bugs or to fill missing features. We can consider for the WEM and the Kailye some zero versions for studies, without warranties, a version 1 for evaluation, usable but not definitive, a stable version 2 usable for business purposes. However what the heck with a new version every three months: Versions 3 or more are to be used only to add technical innovations which are today unforeseeable, once every five-seven years minimum. Ascending compatibility must be warranted starting from version 1. A letter at the end of the WEM version number will tell the version of the secret protocols, which on the contrary must be able to evolve very fast, independently of the other standards that we want fixed.
(This part was rewritten in Sept 14, 2009)
(The NRMP was first called NCCS)
Things like exoskeletons, or the Kailye system itself, require a fast and lossless transfer protocol, even at a low bit rate. There are some ameliorations of the HTTP, adapted for a higher speed. The DCCP is a popular example, used for streaming and VoIP. It is fast, but at the cost of losing part of the data if the traffic is congested. Used for the Kailye, it would produce a haphasardous functionning, in the Second Life style. Used for exoskeletons, driving fast vehicules, etc. it would produce accidents or injuries, not to speak of activities such as telesurgery.
From here the need to get rid off the random behaviour or the HTTP. To achieve this, our traffic must have its own routes, without buffering at each node, and using constant and optimized paths.
But it should be noted that, due to the speed of light, the fastest possible link already needs up to 150 milliseconds to communicate to the antipodes, time to be doubled for force return or feedback. This sets the fastest possible communication rate on the Internet, and will already be a noticeable limitation for close corporeal activities like fight, driving, sex, telesurgery, etc. Remote driving a vehicle in such conditions is equivalent of being mild drunk. So the NRMP protocol must not use geostationary satellites, which add 200 ms each.
So the NRMP would be of the same level as HTTP, but it is a connexion based protocol, rather than a packet system. It is equivalent to a Teletype line, with a low but constant bit rate, arrival in order, and no packets loss. But the only way to get really rid of the random HTTP traffic is to have a fibre or wire fully dedicated to the NRMP protocol. It is a thing we can think at, as today cables contain numerous fibres or wires, so that we can divert one, even for a very low percentage of the total traffic. The modems are the same, only a specific router needs to be developed for that case. The proposed NRMP does not use random packets, but instead a fixed temporal multiplexing of packets. Each node of the network has a calendar into a time frame, containing many time slots. Each time slot is set to one of the multiplexed NRMP connexion, and lasts the time needed to transmit one packet. The calendars for each router in the path are established when negotiating the connexions, accounting with already taken time slots and with the transmission delay of each cable between the routers. So the router knows when it will receive data of a specific sender, and where to send it. It just has to store the destinations in a table (the calendar), count time slots as they pass, and read the destinations in the table. Like this, any packet of data is immediately resent, with no delay and no clashes, all along through the chain of routers. The packet moving along the chain only sees switches all placed into the good position. And now that we understand this, we see that modems are not needed, just the router switches the analog packet waveforms through controlled line amplifiers. In this way, the NRMP connexion is really established and running like a Teletype cable. It is available all the time, up to a maximum bit rate. Time delay is constant and minimum. Data is always in order, and packet loss is 0% (in normal conditions). Also the NRMP has an undisputed priority over HTTP traffic. Such a system is optimal for corporeal activities in 3D, with as only limit the speed of light. In more the routers will consume few energy, and still less if they use wave circulators. So that it would not be a surprise if one day NRMP replaces http.
The calendar of a router will be saturated well before all the time slots are taken (impossible to add a coherent time slots chain along the routers chain) but this is the cost to have a reliable system. Unused time slots can still be used for service messages or HTTP traffic.
Alternate routes may be added for high reliability versions of the NRMP. Basic NRMP version will be fine for games and social activities, high reliability versions could be allowed for remote control of vehicles or telesurgery.
(Added on Sept 14, 2009) At last, the main WEM application of the NRMP, the Authorizations Management Connexion, will require a safe cyphering. So we need, from the beginning, think at a cyphered version of the NRMP. This can be achieved into numerous ways, such as randomly mixing packets or time slots. It would be mathematically very difficult to break a data flux which contains many different messages.
(Added on November 23, 2011) About the subscriber line (the link between Internet and the computer of the user), it is not necessarily required to change its protocol (Most often ADSL). It is enough that the inbound NRMP paquets have priority over the HTTP paquets, and are recognizable. For the outbound traffic, the computer still has to send the NRMP paquets at a constant rate. For this, it needs to be informed of the calendar of the NRMP node it is connected to. Ideally, if the computer can send the paquets in exact time, there is no need to buffer them at the NRMP entry node.
(Added on Sept 14, 2009) We remark here that a technical adaptation of the Internet networks is however wishable for a correct fonctionning of the virtual worlds. This exposes the WEM to blockage actions from ennemies of virtual life. But we can note that a protocol such as the NRMP, especially cyphered, can be useful to many other applications: transfer of administrative data, money transactions, remote control of industrial processes, etc. So a company which would develop a NRMP network could easily make it profitable without waiting for the WEM. While waiting for the availability of a cyphered NRMP network, The WEM can still use the existing networks, with doubling or tripling the connexions, and with cyphering the Kailye messages themselves.
(Added on January 18, 2010) The best candidate for the NRMP seems to be the SCTP, which seems to be designed precisely for this kind of uses. We just need to know in which extend the SCTP transmission delay is stable and close to the theoretical minimum.
(added on May 2, 2014) NRMP and net neutrality. New emerged recently that the growing congestion of the Internet is not caused by a lack of optic fibres, but by the deliberate shutting down of them, in a racket attempt by some Internet companies which want a more expensive but fast Internet. So these companies will be able to show off their childish ego and grey ideologies, while relegating the free Internet to a cheap low quality ghetto.
Into such a situation, the NRMP may look like an attempt to help these companies. This is not the case, since I proposed it before the racket was exposed. Once this situation cleared, it may appear on the contrary that the Internet can run in a very healthy way, with its peak use reaching only a small fraction of its total capacity. If this happens, the NRMP may even not be needed.