Last update: August 4, 2012
Added August 4, 2012
Re-reading this text three years later, I realize that it was placing too much control on people. Sorry, but I was (2009) still shocked by the dreadful rate of griefing into Second Life. Since, nice experiences like Inworldz showed that this dire situation does not happen all the time, but that it was a consequence of some flaw in the way Second Life was managed in this time.
So I removed the most extreme parts of this specification (without telling where) but I do not deny it: some control, like children access to sex places, or in encounter services, will always be necessary.
So many world owners may choose not to use all the controls described here, and they may still have many visitors. But in this case, it is them who are responsible of the safety of their users. Unfair worlds will repell people, while nice worlds will attract more, as it is happening with Inworldz (2012).
Ultimately, electronic means cannot avoid people to come to dispute or divorce. But at least, with the system described here, they don't lose all their friends, life and properties in the affair. And once a repeated offender is spotted, it is still possible to remove him from any place who do not want this kind of people.
The WEM (World Entry Management) proposal is a management system for connecting a user to a world, into a safe and interoperable way. The WEM connexion is a metaconnexion (or upper layer) handling as only one entity a set of different connexions toward the various resources of the world, or abroad on the Internet (world description, chat, broadcasting system...).
The WEM connexion is a triangular connexion between the WEM viewer of an user, his Character Hosting Company and a virtual world. The main purpose of such a system is that, before allowing the character to enter into a world, the Character Hosting Company performs a series of checks for authorisations: group belonging, age and sex content, disciplinary issues, etc. The triangular connexion allows to do so without exposing private data in either ways, from the user or from the world owner, because such data is sent only to the Character hosting Company, an not to the other party. So this system forbids both to cheat, especially with disciplinary measures, which are recorded by the Character Hosting Company. This system brings a built-in protection against many forms of Internet delinquency like anonymous griefing or spamming, exposing children to sex content, copyright theft, etc. But in entrusting a Character Hosting Company with a confidence role (such as storing private data) entrusts it with a legal role similar to a fiduciary office, or even a bailiff when we come to gathering evidences in a judiciary action. The least we can say is that today (2009) Internet Access Providers are not ready for this, despite the blatant need and pressure put on them. But let us start the 3D Internet on a sane basis, to avoid the plagues of the 2D Internet to happen here again, multiplied by 1000, in a system where exoskeletons will allow to physically beat or rape somebody. So we cannot even imagine than, in more, the culprit is impossible to identify...
For this purpose the WEM 3D viewer always maintain a Authorizations Management Connexion between the user, the world, and his Character Hosting Company. This Authorisations Management Connexion is the master connexion of the metaconnexion. But in the very first it performs the preliminary checks when the user starts his viewer and enter a first world. And it will also perform again the same checks each time this user teleports to another world, or goes through an ownership boundary in a world. It will even perform some checks each time a new object, clothe, etc. is introduced. So the Authorizations management Connexion must be always open, so far as we can use it to assess the existence of the WEM metaconnexion, and also use it for more trite tasks like requesting and closing the many connexions to worlds devices and resources. However the safety and reliability requirements of the Authorizations management Connexion make that it will not be appropriate to send bulk data, so that world description, textures, sounds, etc. will require one or several classical http connexions.
Of course the Authorisations Management Connexion uses a secure protocol, and may even use encryption. But the messages can use the Kailye format, with some specific commands and parameters designed for running the WEM activities. But the only trajectory proposed here is when a griefer is chucked out of a world.
It is to be noted that, into the spirit of the WEM system, the Character Hosting Company must establish and know all the connexions between the world and the user, even if they don't actually pass through the Character Hosting Company. This is also true for objects in world which require a connexion to objects in other places of the Internet, in order to protect against the risks of untraceable connexions being used for spam, griefing, etc. For this purpose the WEM enabled simulators make all their connexions pass through a WEM connector module, which also creates and manages these connexions in a simple and hassle-free way for the world designer or simulator designer. A simulator designer just has to add this module as a library or as an independent file. In case an user receives spam or other abuses, while the simulator designer has created another mean to connect out of the WEM connector, then this designer clearly engages his responsibility.
The commands which follow, especially the Konnect and Kmetaconn commands, are not covered by the GNU GPL license of the Kailye, but by the GNU GPL license of the WEM. They must be used only into the WEM safety system, or a closely similar one, obeying the «Moral charter of the WEM companies and the WEM management», or a similar one. This is in favour of the general freedom of expression into an ideologically neutral Metaverse, against all the morons who want to limit this freedom. But it is ALSO in favour of a globally safe Metaverse, against the so-called «freedom» of behaving on the Internet at the expanse of other's well being and interests.
In all what follows, the Viewer, the World and the Character Hosting Company are the Partners of the triangular metaconnexion. The Character Hosting Company is the Master and the two others are the Peers. The Peer which asks for the connexion is the Requester, and the other is the Target. Usually the requester will be the viewer, but in some cases the world may be the requester, for instance when a professional world summons an employee to his task.
In the case of a simple connexion, there will too be a master (the Character Hosting Company), which establishes it, and two partners. We shall also have here the requester, which can be either the viewer, the world, or another Internet resource, while the target can too be either of the three. A simple connexion does not necessary have to pass through the world, and it is not triangular.
The word Resource in a Kailye message stands for an URL or URI, usually of an object, file, etc. In the case of a connexion, it will be the URI of the device or service to connect to. This is written in the URI line in a Kailye message, with at need some parameters to complete it: ?KID, ?KhumanName, etc.
The Konnect command is sent only by the Character Hosting Company to connect two resources. It does this without checking for any authorisation, as this is the job of the Kmetaconn command. So the different values of Konnect will be only about the connection management. The Konnect command is followed by only two objects, the two resources to connect, the requester first, the target in second.
Konnect=request
is the command sent by the Character Hosting Company to each of the partners to initiate a connexion between them. Upon receipt, each partner opens a channel (updates the WEM Connexions Register, and adds a plug or connector instance in the case of a WEM viewer or simulator, ). If everything goes all right, the connexion should start to run.
Konnect=request,"userName","password","paimentReceipt",
"Charactername","Voucher",...
complements the basic command with any kind of parameter necessary to connect to password protected resources, toll or subscription resources, group reserved resources, etc. The appearance of a password here is the reason why the metaconnexion must be secure, at least as much as the https:// connexion used for similar purposes. Some content, or the whole message, could be encrypted.
Konnect=ok
is the message sent by each partner to the Character Hosting Company to tell that the connexion is running correctly.
Konnect=error,"errorCode"
Is the message sent by one or two of the partners when the connection failed for some technical reason. If no automated correction is possible (such as trying another URI), the "errorCode" is handed to the user. This message can also be issued when a properly running connexion goes unexpectedly off, for some technical failure. In this case, the WEM system must automatically try to re-establish the connexion with another URI, and only if this fails, warn the user of the problem.
Konnect=denied,"motive"
is the message sent by one or two of the partners when the connection failed for some NON-technical reason, such as wrong password, etc. If the "motive" is not understood by the WEM system, or cannot be corrected automatically, then the "motive" is handed to the user.
Konnect=useless
is the message sent by any of the two partners to tell the other and the Character Hosting Company that it no longer needs the connexion.
Konnect=close
is the request sent by the Character Hosting Company to close the connexion. It is sent about 10 seconds after a Konnect=useless. This delay is for offering an appeal to the other partner.
Konnect=closed
Is what the two partners reply when they actually close the connexion. While doing so, they also free their instances of plugs and connectors.
Konnect=keepopen
is the appeal method to Konnect=useless. This avoids the Konnect=close, and allows for an idle connexion to be still running and be ready to exchange data without the delay of starting another connexion.
From there, care must be taken to avoid entering into an error mode where dead connexions would accumulate, ruining the performances of the system. For instance, any of the Character Hosting Company or partners sends a Konnect=useless at regular intervals. At a pinch, when such a situation is escalating, the user should be warned, so that he can take the decision to stop himself some of his activities. This will result in a Konnect=close without appeal. High overload of the simulator or viewer could result into the same, with a warning to the user.
Also, while the connexion is running, each of the partners can use connexion control commands such as Kping, Kbuffer, etc.
It is to be noted also that a Konnect command will be used for establishing the Authorisation Management Connexion with a world. The existence of this single connexion tells the existence of the metaconnexion.
At last, closing a simple connexion, and all the more the metaconnexion, should not be attempted lightly. The Internet is full of short failures, or the unresponsive partner may experience a surge of activity (for instance a well known and notoriously bad OS may be uselessly scraping the hard drive without using the DMA channels, so that it needs 45 seconds just to open a menu). So only the receipt of a clear failure message, or several tries and delays, will lead to the decision to close.
After the «Moral charter of the WEM companies and the WEM management», in countries which respect Human Rights and offer a correct judiciary system, basing its decisions on checkable facts and respecting the rights of the defenders, into a procedure or inquiry for truly criminal activities, then a magistrate may issue an order to spy on someone's connexions and Metaverse activities, in accordance with laws on inquiries and respect of private life. When this happens, police officers will be allowed to access to the WEM system, through appropriate interfaces in the Character Hosting Company.
This legal requirement is the reason why the the Konnect command can be issued only by the Character Hosting Company. Any other scheme could be easily tampered by modified viewers or pirate simulators, leading to unknown or unchecked connexions. So, in a more general way, traceability of spam or similar concern also build up on this requirement.
The simplest way to monitor a connexion is to log the activities of the Konnect command, in such a way as to be able to use them as valid legal evidences (again into the frame of a valid judiciary procedure and inquiry). This is already a legal requirement in some countries, for Internet access providers. We can consider a Character Hosting Company a Metaverse access provider, so that the same laws apply.
A second method is to get alerts each time a Konnect command branches toward a given resource.
But the most obvious way is to tap the connexions of the suspect user, using the Konnect command itself for this purpose. This requires, technically, to establish a third partner as receiver of what the two firsts are saying. In this case, and only in this case, the third partner is sent into the Konnect message as a third resource. This looks very simple to do, and the user is not aware. Except that any tampered viewer or simulator is able to detect the existence of this third partner instantly... From here the interest of the method presented in the part: Safe development of softwares, in order to make sure that we have only non-tampered viewers and simulators. However this will probably be a weapon and shield race, and all the more is there is a stake such as this use of the Konnect command.
So the safest way, if not the simplest, is to use the Konnect command just to know the connexion, and then tap it in the neutral Internet network.
Other methods may be used to spy on people, and report chat, sound, images of what they are doing in world. This includes spy devices, or the ultimate, an invisible character able to enter everywhere. As appealing as it sounds, this is just sheer illusion, as any simulator is able to spot them at once. Especially criminals will not miss to use modified simulators and detect such invisible characters and devices. Only platform worlds may be able to use them, as the users don't access the simulators. In more, such methods arise a huge concern of respecting the dignity of the Human being, if anybody is able to look at us or hear us everywhere, record our images and all, without us being aware of it. So using these devices for judiciary purposes will probably create more evil than it will save. They will probably be forbidden, for reasons of respecting human dignity. And anyway, so many people will be tempted to use them, that many cautions will be taken to make them impossible, illegal, etc.
The first function of the Kmetaconn command is the connexion management between a viewer and a simulator. It does so when the user first connects, but also each times the user teleports to another world, when he crosses a simulator or ownership boundary in a world, or even when one single new connection is requested, for instance to a radio broadcast. At each of these occasions, Kmetaconn has to enable all the necessary connexions to the varied resources. So Kmetaconn maintains the list of the necessary connexions into the WEM Connexions Register of the WEM engine of the viewer or simulator. But it does not establish the connexions themselves, this is the job of the Konnect command. The lists of connexions appear as resources in the Kailye message, with some specific parameters.
The second function of Kmetaconn is the authorisations management, by checking the match of all the kinds of criteria to allow the character to enter into a world. This activity will result into five kinds of replies:
-Denial of access. In this case, no connexions are established, and the motive of the denial is sent to the user.
-Warning. The metaconnexion is established, followed but a series of Konnect commands to establish the connections. But a warning is sent to the user as what something may request his attention or change the situation.
-Automated correction. The user is warned that some corrections are needed, for instance to automatically add or remove clothes, to cope with some clothing rule. A warning is sent to the user, to inform him of this action, or to refuse it. If the user accepts the action, then the action is done and the access is established. If he refuses the action, then the action is not done, the metaconnexion is not established, and the entry or teleportation is not achieved, as in a denial of access. Such automated corrections may be about many other things, such as tools, forbidden or mandatory HUDs, etc.
-Manual correction. Same as previous, but an automated correction is impossible, so a manual correction is requested. The metaconnexion is established toward some neutral waiting space, called here the antechamber, where the user has explicit messages about the requested correction, and tools to accomplish it. His initial destination appears as a teleport button or door, with its connexion already established. It is the responsibility of the user to correctly apply the requested correction before going ahead.
-Access grant. Yipeee!
The criteria useful to take these decisions are sent as parameters of the Kmetaconn command, into the same messages as for the connexions management.
The establishment of the connexions and the request for authorisations may evolve independently, at need through several cycles of Kmetaconn requests and replies, until all the questions are answered. This process is called the pairing of the metaconnexion.
These two roles make of Kmetaconn a very powerful command, at the heart of the functioning of the WEM, managing the user's metaconnexion to the world, checking authorisations, and pairing all the connexions required to log into the world. This activity continues as the Character moves in world and enters new places, for establishing new connections, contact new objects, new characters, etc.
The pairing is referred as a cycle, because when a first round of messages does not succeed into establishing all the connexions, or fulfilling all the criteria, then a second, see a third round can be called to find other connexions, manually correct a clothing, etc. Into both requester and target WEM devices, the Pairing cycle corresponds to the updating of the WEM Connexions Register.
The metaconnexion will be initiated by the user, or sometimes by the world, if the user agrees to do so (volunteer, worker under obligation). So the requester sends a Kailye message to the target, and to the Character Hosting company:
Kmetaconn=request?KID=session$name$&Kflags=...
The $name$ will be the name of the metaconnexion, scoped to the actual Kailye session, as several may run on the same viewer, and hundreds on the same simulator. The &Kflags tell the Character Hosting company the various authorisation flags. These flags will be explained in details in the next chapters.
This command is followed by a list of resources that the requester needs to have connected. For instance:
URLofTheResource
?Kfunction.request=authorisationsManagementConnection
URLofTheResource
?Kfunction.request=worldDescription
…
The Simulator Block tells the URI of the requester, and gets the Kfunction.request=authorisationsManagementConnection. The other resources are all the connections this peer will need to get matched, in order to actually immerse the user into the world. In this way, the requester sends to the target its own list of connections, telling for each their address and their function, so that the target can find a match for each.
Here is a list of the functions. Many others may be added with time:
authorisationsManagementConnexion This is for the peer which directly manages this connexion.
worldDescription This is for the 3D description file of the base landscape of the scene. All other objects are mandatorily into sub-directories matching the scene geometry hierarchy. It is important to note that this will usually point at the scene of a monitoring simulator. So several other worldDescription will be required, one per each character or object monitored by this simulator, but hosted or handled by another, not forgetting neighbouring simulators, etc. This can make hundreds of items.
TextChat
IMsystem
voiceChat
VoiceIMsystem
audioChannel when an independent radio broadcast is on the land, so that the user may connect to it.
TVChannel
characterDescription
characterCommands, for character movements and collisions. (This will usually be the same as the authorisationsManagementConnexion, but future implementations, especially with exoskeletons, may require to separate them)
automationsCommands, in both ways (same remark as with CharacterCommands)
InventoryInterchange, for exchanging objects
moneyManagement, which must work for any legal or roleplay currency, and for any exchange system like tickets, distributive money, barter, etc.
groupManagement, which handles group belonging, lists, etc.
Etc.
Other usual parameters can be added to the resources, such as a $name$, etc.
The requester may also go forward in proposing some matches of its own, as supplementary resources in the list:
URLofTheResource
?Kfunction.suggest=TextChat
Contrary to the previous, this is a suggestion about where to connect, but not a resource owned by the requester. World may have such preferences.
What happens after Kmetaconn=request? The first thing is that the KID command (mandatorily appended to it) will have to execute its own dialogue, in order to find a name to the connexion. To avoid several cycles of KID messages, it is recommended to use some specific naming system, for instance starting the $name$ with the character ID, which is unique.
It is important to limit the number of iterations at any time of the Kmetaconn process, as only pinging a message can already take up to 0.3 seconds, more eventually several seconds if the concerned computer is very busy. If tens of iterations are needed, then the connexion time may require several minutes, which is unacceptable. A good idea too is to inform the user of the advance of the connexion process, even if he does not understand those messages. In case something goes wrong, it is still the best method to obtain some smart reaction, or at least the user can inform correctly the customer support.
When the connection name is found, the second action to be taken is a Konnect command on the Authorisations Management Connection. Then this Konnect command will execute its own cycle until a match is found (when an user attempts to connect to a busy server, this server may have thousands of channels, most of them already taken) Usually it should be enough that the target proposes its own resource, if the one proposed by the requester does not work. Several iterations may be an indication of a problem. And of course if the Authorisations Management Connection fails, then all the Kmetaconn process fails and stops here. Even the connexion name is cancelled with a Kmetaconn=close?KID=session$name$,deleted. Of course the user must be informed of the cause of the failure, which is indicated into the last Konnect message.
When the Authorisations Management Connection is up and running, the requester can send its list of requested connexions to the target, which can start to look for matches, and send those matches to the Character Hosting Company, so that it is ready for the next stages.
When the Authorisations Management Connection is up and running, then will first take place the authorisations checks, with the Kflags parameter, that we shall see in details in the following part.
The authorisations check may result into a denial of access. In this case, the Kmetaconn command is stopped and the connexion name is erased:
Kmetaconn=close?KID=session$name$,deleted
The user receives a message explaining the reason of the denial.
In the case the authorisations checks result in a warning, an automated correction or a manual correction, then the user receives a warning or a request for the correction. An automated correction will result into a change in the character outfit. A manual correction will result into a change of the entry point of the world (change of the WorldDescription URL), toward some neutral antechamber room offering the tools for the desired correction (free objects or clothes, scripts, and as far as a shop, although Second Life experience showed that users don't like this way to deal with them) and a teleport point to the originally intended destination. (In some cases, such as removing shoes when entering a Mosque or Buddhist temple, the outfit adjustment will be purposely not automatic, as a conscious act is requested in these situations)
In the case the authorisations check results in access grant, then the Kmetaconn process continues:
The last step of the Kmetaconn process is when the Character Hosting Company issues a series of Konnect commands, one for each required connexion function. Each of these Konnect command will execute its own pairing cycle for a given connexion function, until it finds a match. The activation of each of these connexions makes that the user and the world start to exchange data, thus establishing the immersion of the user into the world. The reception of a Konnect=ok for all the connexions will result into a complete immersion and the completion of the Kmetaconn command, with a Kmetaconn=ok, telling both peers that the metaconnexion is established and running.
Awakening into the world may result into contact with other characters or objects hosted or handled by other simulators, which will each require a round of Konnect (without Authorisation checks at this point, as the items already underwent them when they entered into the world. However some checks can be made for friends, foes or muted characters that we discover at this time. This uses the group features).
The failure to establish one or several of these connexions will usually result into a degraded immersion of the user into the world (no sound, no chat, no image...) In this case, the corresponding Konnect error will have to be handed to the user. Most users will not like to just have a polite but frustrating blank screen, and try anyway the degraded working. So instant choice must be provided to the user to get detailed error info or not, to enter anyway into the degraded immersion or to refuse it. Exoskeletons will not be allowed into some of the degraded modes, from safety.
Each time the user teleports into a new world, goes through an authorisation boundary, rezz new objects or encounters characters, then a new Kmetaconn has to assess the new authorisations, to start new connexions, and close the useless ones, however while retaining the same metaconnexion $name$. In case of a denial of access, the teleport is refused, or the authorisation boundary is translated into invisible collision bounding boxes that the character cannot go through (this was explained with more details about the Kinflex command).
It is important to have some anticipation, to avoid very unpleasant freezes of several seconds when an user tries to pass an authorization boundary. Passing through the boundary to be pulled back later is completelly unacceptable, and may even be illegal, as this can lead to privacy exposure. For this reason, boundaries must be by default impassable, until the character receives the authorisation.
It is also important to check for useless connexions, to avoid them to accumulate during the life of the metaconnexion. For instances connexions to objects are closed when leaving the place, or after some minutes of inactivity. But connexion to chat systems may be up all the time (we can hope that only a small number of chat systems will exist).
If one of the connexions fails during the life of the metaconnexion, then the remaining partner has to send a Konnect=error,"errorCode", and the Character Hosting Company starts a new Konnect pairing cycle. The connexion is declared dead after some tries or alternate links attempts (using the Konnect dialogue syntax).
If the dead connexion is the Authorisation Management Connexion, then a Kmetaconn=close is sent. If it is another connexion, then the user is warned of the error, and enters in a degraded mode. Anyway the user must alway be kept informed of any malfunction, even minor or short, as it is very frustrating to have a system not responding without apparent cause. This also helps to spot deffective connexions or items.
We can set various degrees of activity in world:
Kmetaconn=idle when the character wants to receive messages, without being anywhere in the world. In this case, all the connections about the character, local chat, sounds, etc. are closed.
Kmetaconn=busy, on the contrary, allows the immersion, but closes all message channels.
Kmetaconn=wakup, to forcibly get somebody out of busy mode, for some urgent purpose. This re-establishes messaging connexions. Abuse of this feature may constitute harassment, so it is enabled only on a voluntary or contract basis, or only for a list of authorized characters.
When a character or a script attempts to rezz an object (or a clothe), a Kmetaconn command has to check the authorisations for this object, and match them with the place. If the object is hosted or handled by another simulator, then a new connection has to be established toward its description file. We can even imagine some kind of anti-virus checking of objects, before they actually rezz, to detect griefing tools like replicators, weapons, spammers, money scams, griefing HUDs, etc. For instance such a thing as the «Bloodlines» organized griefing in Second Life would result into blacklisting the griefing HUD and the victims database URL.
It can be discussed as to the need of sending some intermediate points of the Kmetaconn command, telling at which point the process is:
Kmetaconn=authorisations, when checking for authorisations and before sending Konnect commands.
Kmetaconn=automatedModification, as a result of the situation arising from the checks
Kmetaconn=manualModification, idem
Kmetaconn=connecting, when sending the Konnect commands
Kmetaconn=ok
Kmetaconn=errorhandling when an error appears on one of the connexions, and a new Konnect cycle is attempted to retrieve it.
Kmetaconn=error when the metaconnexion is irretrievably lost (main connexions lost).
URLofTheResource?Kfunction.ok=voiceChat tells that the connexion is running properly, or the function has a match.