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.
Basically the Kmetaconn=request?Kflags=... will ask both world and user to send the values of flags that they request, or provide, respectively. This check will result into one of the five behaviours of Kmetaconn command, as seen above: denial of access, warning, automated correction, manual correction, and access grant.
Usually the authorisations of the world are public, save some exceptions like ban lists, private group belonging, vouchers, etc. A group may be managed by the world, by the Character Hosting Company, or by an Internet site.
Many of the flags and data of the user are legally private, such as a password, sex tastes, private group belonging, physical life data, etc. Some of these informations will always be stored by the Character Hosting Company (such as physical identity, age, disciplinary issues), so that the user's viewer will not actually need to send them. Some flags will always be stored by the user (such as password, a Metaverse political refugee statute...) At last some flags may be stored by any of the two, depending on the wish of the user. But the presence of private data like group belonging or sex tastes, or even of life safety data like a Metaverse political refugee statute, justifies that the Authorisations Management Connection is secure, at least as much as https://. If not, the Kmetaconn command should have its own encryption. As it does not contain messages of the user, there is no legal forbidding at using a strong encryption method, as to a bank account access.
Usually the world and the user will not send their flags to each other, in order to keep these informations private. There are however some cases where a world requests a password that the Character Hosting Company must not know, or when it checks the name of the character against its own members list or ban list. In this case, the world will send a command:
Kflags=~checks
It is to be noted that the Kflags parameter uses the same syntaxt than the format line of a trajectory, especially the tilde ~ to differenciate flag names from flag values.
to the Character Hosting Company. (This may made useful the Kmetaconn=authorisations statute). To the user it will send a more accurate request:
Kflags=~checks,~password,request,~voucher,request,...
In this case, the user must reply to the world only, with a command:
Kflags=~password,****,~voucher,VoucherID,....
Then the world performs its own matches, and send one of the five result to the Character Hosting Company, with:
Kflags=~ok,
Kflags=~automatedModification,
Kflags=~manualModification,
Kflags=~warning,
or Kflags=~deny.
The last case of course stops the Kmetaconn process.
In order to avoid the Kmetaconn to wait for checks by the world when the world does not need any, the world will send a Kflags=~nochecks by default.
It is understandable that informations like the physical race, gender, religion, sex tastes, etc. of an user are private data, and must not be disclosed in world. But there are some exceptions, such as dating services, some administrations, etc. where the world may request to know such or such private data, from their very purpose. For instance the race is totally irrelevant and illegal for a job application, but perfectly legitimate to ask in a matrimonial service. In these cases, the user is warned that the world is asking for them, and he must give his consent. Without disclosing the private data, the service may be unable to run properly, or the world may not accept the user.
There can be so many kinds of flags, authorisations, white lists, ban lists, etc. determining if the user can be accepted or not in a world, that it is difficult to make a comprehensive list, with all the criteria and peculiar cases. So the Kflags format has to be made extensible at will. It takes the form of a table with variable number of fields per line. Lines are separated by semicolons, fields by comas. Each line is for a different criteria. Each line has the criteria in the first field, followed by the list of allowed values for this criteria. The criteria name itself starts with ~, and it uses the hierarchical naming system, to be able to cope with as many sub-cases as desired.
For instance we may have the actual values for an user:
Kflags=
~character.name,"John Doe";
~gender,male;
~specie,semi-human.furry;
~ageCategory,adult;
~clothing,ordinary;
and the list of authorized values for a world:
Kflags=
~gender,any;
~specie,human,semi-human;
~ageCategory,teen,adult;
~clothing,covered,ordinary,light,bikini;
We see that when the user describes only his own actual condition, the world allows for several conditions. There can be very restrictive worlds, thought, such as in a roleplay with only one predefined specie.
If the user has:
~AgeCategory,child;
while the world has:
~AgeCategory,adult;
then the user will be denied access, as law requests it.
If the user has:
~clothing.nude;
while the world has:
~clothing.covered,ordinary,light,bikini;
then the user will get an automated correction or manual correction as to add some clothes.
The user may have many ways to set the reactions of his viewers to warnings or automated correction requests. If he has a ready outfit fulfilling the world's conditions, it can be exchanged automatically, with or without a warning. If the user does not have a ready outfit, he may be led to the antechamber for a manual outfit adaptation. And if the user wants to remain naked, then he just has to refuse the teleport, or even set his viewer so that such teleports must always be denied. A noob user will always have his options set in a way to give him the full choice at each step.
At last, some information, like the physical identity, will apply to the user, who is a physical person living in the physical world, while others apply to the character. So some flags will have general prefixes telling which case applies:
Kflags=~physical.name,"John Doe";
Kflags=~character.name,"Tarzan";
Of course, any ~physical or ~legal data has to be checked. Unchecked players will not have such data.
Similarly, prefixes tell if the flag is about a legal situation, opposed to a roleplay situation. This is to differentiate things such as a contract being legally binding, and a game contract. But it is NOT to mean that virtual worlds are not «real»: a legal contract has the same legal value in the virtual as in the physical world, or it is not a legal contract. For instance intellectual property is as well protected in the virtual as in the physical world. Or «roleplay» can be in the physical world too. So here «legal» and «roleplay» simply don't match «physical» and «virtual».
Kflags=~legal.covenant.marriage
Kflags=~roleplay.covenant.marriage.polyamorous
A third case will be useful to define rules of places, or rules of a roleplay. Violating rules is not a legal issue, only a discipline issue (unless the violation is serious or repetitive enough to fall under a legal definition, such as for instance in stalking). Here is a group charter flag:
Kflags=~rule.covenant.charter
The difference between a rule.charter and a roleplay.charter is that a violation of the first is cheating in a game, and will usually bring the exclusion of this game. But cheating with the second is part of the plot of the game, and then will not bring exclusion of this game. But it may bring exclusion of a guild, or other retaliation into the game, by the other players, as part of the roleplay.
~physical.specie,... tells the specie of the user into the physical world. Contrarily to what may be expected, there are four values:
human, when the user is simply a human being.
robot. This value is set automatically when the WEM viewer receives automated commands from another software. Depending on worlds, robots will be banned, have a visible robot tag, or some robots will be allowed without robot tag.
Robots designed as commercial hosts, presentations, guides, etc. will get a robot.host flag, as long as they don't make any actual transaction or money uses. Robots intended to do such transactions will need a robot.vendor, robot.business, or robot.buyer flag. At last robot.monitor could be used into some distributive economy systems, in order to grant goods or record work.
A robot.helper is a helper for users who are new in the virtual, or have some disability. The user can make them visible or invisible, use them to send warnings to other users, as translators, etc. Experienced users may still use them for performing tasks, but in this case worlds may forbid them, or make them mandatorily invisible to the other users.
cyborg is for an human user with some computer enhanced reflexes or smart aid. This can be for roleplay, professional activities, etc. This value may be forbidden as a cheat, into games, sports, etc. This tag arises some difficulties, as there is no safe automatic criteria to sort out a cyborg from a pure robot (A cyborg will appear as an human to robot detection tests). So, many worlds will apply a caution principle, and request to disconnect the cyborg functions. An human with a prosthesis replacing a missing body part or ability, without enhancing it, has no obligation to wear a cyborg or robot tag. For this, prosthesis must not send automation tags, in order to remain private in all cases, and not deprive their owner of any legitimate right. A second field such as cyborg.physical, cyborg.reflexes, cyborg.speed, cyborg.memory, cyborg.intellectual, may bring some more precision on the kind of enhanced capacities, to avoid things like excluding a fast runner from a chess contest.
animal. This value may look surprising, but into some years exoskeletons will make possible the immersion of animals, leading to many fun or useful applications. An animal exoskeleton will set this value automatically. It must be mandatory for animals to wear a visible animal tag warning the other users of their nature and possible unexpected reactions. A second field may tell the degree of hazard or taming: animal.autonomous, animal.gentle, animal.tamed, animal.wild, animal.dangerous, the later flag being able to be actually dangerous if he uses an exoskeleton. Similarly to robots, animals may be banned or restricted in different worlds, depending of the hazard they bring. An animal of course will not be allowed in sex places. Similarly, he cannot use money, with few very peculiar exceptions.
Of course any robot or animal account will have a human user legally responsible of its use. This human is especially responsible to set the physical.specie flag properly. Cheating with the value will always be considered a strong disciplinary offence, and in many cases a legal offence. For instance most users will feel raped if they find out that they had a sex interaction with a robot, not to speak of an animal. This is enough to fulfil the legal definition of a rape by cunning or cheating.
~character.specie,... tells the specie of the character into the virtual world. There can be a nearby infinite number of values.
So ~specie is the specie of the outfit that the character is actually wearing. It may be modified when the character changes his outfit, forcing a partial Kmetaconn to check if this new outfit is appropriate to the place. Or, on the contrary, a Kmetaconn may force an automated change of outfit when entering a new place.
(Outfit refers to a collection elements such as a body shapes, skin textures, clothes, attachments, etc. that the character will start to wear globally, into only one operation. Editing the appearance will modify, add or remove individual elements of the outfit. A change of outfit can send a Kmetaconn command, but editing the appearance must work in a smarter way, clothe per clothe, knowing the authorisations applying to the place. For instance we must not be able to remove an underwear in a clothed place.)
Examples of characters:
~character.specie,human.elf.sindarin
~character.specie,hybrid.furry.neko
Example of worlds:
~character.specie,all
~character.specie,human,hybrid
~character.specie,animal.wolf,animal.dog,animal.bear
Here the hierarchical naming of species finds all its usefulness. We create a hierarchical name starting from a general category, to end with the most peculiar description. For instance human may be understood as any specie with a standard human shape, with just adaptations of dimensions, colours, etc. enhanced may be a human with some popular appendages such as tails, antennas, or wings. hybrid will have an overall human appearance, but needing a somewhat different shape (furry, lycanthrop, satyr, etc.). Other categories may be robot, animal, fourLegged, bird, fish, octopus, etc. We always keep with words giving some hint at the global shape, and don't use names like «ET» or «fantastic» which do not give any hint of a shape and can cover anything. For instance a dragon will be a fourLegged.dragon
The specie flag will mainly be used into theme definition, where species are controlled. Especially roleplays will often impose a small list of strictly defined species. Other uses of this flag may be considered racism or specism, see illegal, for instance to discriminate applicants to a job. Virtual worlds are precisely intended to escape this kind of idiotic limitations, and to allow anybody to be what he likes. So professional uses may have only common sense limitations, such as no large or small characters in the work place, no four legged animals, or an appearances adapted to an artistic rôle such as in theatre.
Some value combinations don't make sense, such as: angel.demon, although such a mistake would be common today... Rather use human.angel or hybrid.demon which give a hint of the general shape of the character, and which at least are not self-contradictory.
The hierarchical naming of species must go from the general to the peculiar, as the first values will be used for general screening in softly themed worlds. For instance robot is not fit in a fantazy world, whatever follows. But furry may fit in this theme. The last values of the hierarchical name will on the contrary be used in intensive roleplay places to tune precisely the mandatory species:
~character.specie,human.elf.noldor
~character.specie,hybrid.orch."Uruk Hai"
It would be technically sound to just append the race of the user to his specie, such as:
~physical.specie.human.white.arab
but we must account with the risk of racism. Racism is still a prevalent mental disease, which needs strong corrections to get rid of it. To take the measure of it, just know that, in Second Life, most Black users have White characters, to escape any segregation. However Second Life characters do little segregation against species... This difference makes that we must separate the race data from the specie data. But a computer cannot know where to break the full hierarchical name between the public info human, and the sensitive data such as white.arab So it is better to break it by design, so that we have two separate flags, one public, one much more private:
~physical.specie,human;
~physical.race,white.arab;
On the virtual side, we have the same issue, although the race may be visible anyway. So we have the same syntax.
The four main physical races are white, ebony, asian, red. The future versions of the Kailye are encouraged not to go into an euphemism race: those who made "Black" an insult are idiots who spat against the wind and received themselves the ignominy.
Of course, the virtual races are as many as wished, although worlds imitating the physical life will limit to these four.
And if you apply to a job, make a white.clean character for this day... :-D
~physical.nationality,"US","français"
is an example of double nationality.
Usually the physical nationality is considered as a relatively public data. But in some cases, it may become very sensitive, for instance with countries in war. So it is to be disclosed only with the consent of the user, who may also use only automated translators to hide his nationality.
Also, after the «Moral charter of the WEM companies and the WEM management», when a person is victim of political intimidation in the virtual, or his virtual activities are used to trace him in the physical world and threaten him, so this person may get a Metaverse political refugee statute. But it is premature to specify how this works, without an already running WEM management.
In the virtual, the physical nationality may be visible into some special places (administrations...). But usually it will be hidden and considered as private. People will sometimes display a nationality, without warranty it matches the physical nationality. However nationality is a legal thing, so it is not advisable to claim for one we don't have, even for play. This may even be made illegal. So, in all cases, the physical nationality of the user is something which has to be ckecked.
However, in an intensive roleplay, nothing forbids to claim any real or imaginary nationality:
~character.nationality,"roman"
(The Development of this chapter has been removed August 4, 2012, and summarized here:)
~physical.gender,... tells the gender, with its variations and varied behaviours. Gender may be different in the virtual than in the physical life. Physical gender will most often be a private data, for instance in job application. But its presence in the system allows for instance to filter out people with inappropriate physical gender from encounter services.
~physical.name,"John Doe"; is of course the physical name. As it can be ambiguous, and probably never any universal person ID will be provided, we need some other criteria to identify a person:
~physical.adress1,...
~physical.adress2,... ~physical.ZIP,...
~physical.town,...
~physical.country,...
~physical.passportNumber,...
~physical.socialSecurityNumber,...
etc.
Of course all this is private, and can even be illegal to disclose. The uses are for administrative purposes, physical dating, etc. But the main use is to check the uniqueness of an user who may hide under several accounts. This is useful ONLY to 1)automatically thwart cheaters who duplicate or sell characters in games, or 2)thwart banned persons who try too re-enter a world under another identity (How it works is explained in the extended manifesto). Another use is of course to identify an user, on request of a magistrate into a correct judiciary procedure and inquiry.
~character.name,"Sophie Gronénés" is of course the name of the character in the virtual. But it is less obvious that...
~character.name.SecondLife,"Toto" is the name the person has in Second Life (or any other non-standard world not offering federated identity, or imposing an unwanted second name such as Second Life). Such a flag needs a checking, of course. However the users of a world which stopped operating can no longer check. So:
~character.name.Lively.unverified,"Toto";
At last we can define:
~roleplay.name,"Galadriel";
as the roleplay name of the character, into an intensive roleplay session. In this case, the usual ~character.name,... is hidden. It is usually disclosed after the session. This would be useful in fight roleplay, where our actual friends would appear as enemies in the game, for the sake of psychological realism. After debriefing, of course, the fun is to discover who beat us... or during games, to play guesses of who is who, based only on their psychology.
~password,******; is for when a password is required to enter a world. Of course the password is coded. As the coding may vary with evolution of threats, it is not specified here. The preferred method could be the same as with Internet forms, that the world cannot retrieve.
~voucher,"registrationCode",; is for world requesting some entry management other than password, such as being invited, or getting a temporary use. In this case, an authority delivers a voucher that the user must present when entering. Of course it may be coded as the password.
~voucher,"registrationCode",expiryDate; is the same, but an expiry date is specified as an UNIX time in seconds. Future uses may require decimal point values.
~subscription,"registrationCode",expiryDate; can also be more appropriate than a voucher, for worlds requesting a fee, subscription, etc.
~clearance,"clearanceCode","issuingAuthority",expiryDate; is for worlds requesting some professional clearance.
If the character gives false values, then the world replies with ~password,accessDenied; or ~voucher,accessDenied;, etc. More accurate info may be provided with wrongName, or wrongVoucher, or suscriptionExpiry, or InvalidClearance, or bannedCharacter, bannedUser, etc.
Users may specify their religion. Worlds may request this in some peculiar cases, such as temple access, dating systems, etc. So:
~physical.religion,...,...;
allows the user to specify one or several religion. Of course this data must be true, under the responsibility of the user. Religious world owners may want to check it, but this check however is performed under their responsibility.
~character.religion,...,...;
plays the same role for the character, although it does not make much sense to have a different religion in the physical and in the virtual: spirituality is something of the mind, that we necessarily bring with us wherever we go.
However~roleplay.religion,...; is free to be set to any value, real or imaginary.
Belonging to a monastic order can be told by belonging to a group. A ~roleplay group arises no issues, but a real monastic order will have a ~rule charter, and it even must have a ~legal charter if it is legally allowed to receive gifts or heritages. This flag is always visible in the charter of the group, and in the two later case it is a legal responsibility of the order to check belonging of members, to avoid abuses like bad spiritual counseling or improprer gifts.
Similarly, religious groups can get a ~roleplay charter, a ~rule charter, and in some special cases a ~legal charter.
Proposed list of main real religions:
Zoroastrian, Zoroastrian.parsi, Jew, Christian, Christian.catholic, Christian.reformed, Christian.orthodox, Muslim, Muslim.sunni, Muslim.shia, Muslim.sufi, Taoist, Shintoist, Buddhist, Buddhist.theravada, Buddhist.mayayana, Buddhist.vajrayana, Buddhist.tibetan, buddhist.zen, Hinduist, Hinduist.yoga, African, Voodoo, Animist, Precolombian, Atheist, Pantheist, Mystical, NewAge, GreatArchitect, Jedi...
Similarly, users may specify their political belonging:
~physical.politicalParty,"...";
~character.politicalParty,"...","...";
~roleplay.politicalParty,"...","...";
however there is no list provided, as political parties vary from one country to another, and even from a year to the next. Just an user engages his responsibility if he claims to be of a given party. As for religions, it is the responsibility of parties to check the belonging of a character.
These religion and political flags arise the issues of cults, fundamentalism and extremism. However it is not to the virtual worlds management to inquire objectively about who is a cult or not, who is an extremist or not. So access forbidding will occur only on the basis of magistrate requests, or obvious delinquent activities. The WEM management» may take the extraordinary initiative to ban some well known cults, fundamentalist religious groups or extremist political groups. It is however illusory to pretend to ban all their members.
(September 2013 update)
The following part was inspirited by the heated debates which happened in Second Life in the 2008-2009, with heavy concerns about minors encountering sexual content and sexual predators into virtual worlds. At this time, Second Life used age check of new residents, to totally forbid the entry of minors.
However what happened since was totally unpredicted: not only Second Life abandoned age check (which was discouraging many new users), but in more, they now allow in minors as young as 13, with just the legal warning which can be seen on any Internet site with adult content. In theory, they cannot enter adult places, but the system can easily be cheated. And what happened?
Nothing!
No huge invasion of sex-crazy teens, no herds of predators filling public places, No massive increase of minors abuses... Just life continued.
So it appears after all that all this debate was a concern for a problem which did not existed. Probably fuelled by a mixture of puritan views, hate of children, and claim for sexual «freedom» everywhere, all converging into only one scream: «no children here!»
In facts, the law makes an obligation of means, but not an obligation of results. The law makers debated these matters long before the geeks, and they were aware that requesting real check was impossible without greatly hampering freedom. Or perhaps they remembered that children still have parents, sometimes. And they decided that Avoiding children to go in unsuitable places is the legal responsibility of the parents, not of the site owners, not of the world around.
This has two practical consequences. First, virtual worlds which continue to restrict access to 18+ adults now appear as sex sites. They may even lose the market. Second, most of what follows in this part is useless:
(resuming original text) It is a legal requirement to match the age of the user with the content of the visited world. However the many possible cases and exceptions need a more realistic description than just «more than 18».
~physical.age will tell the exact physical age of the user. This private data may be useful for some purposes, such as dating services, administrations, working contracts, etc.
~legal.ageCategory tells the legal age category of the user. It is computed by the Character Hosting Company from the date or birth and the present date. Some secondary values may tell special situations. Here the legal prefix is preferred, as the age category is a legal thing, not a physical attribute. (The ageCategory may even change while the physical age does not, for instance if the legal age limit is changed)
Here is an attempt to define a set of age categories and related world content:
baby, 0 to 3. Accompanied by close relatives, guests and nurses. Protected environment.
child, 3 to 7. Same, but with a further category of professional educators. Monitored visits, roleplay under supervision (this does not mean directed, but just taking care that the situation does not go wrong).
kid, 7 to 11. Same as kid, but with more possibilities. Random encounters monitored, into some public places.
youngster, 11 to 15. Freedom of visiting alone some public places, no sex save education, mitigated violence in roleplay. Encounters monitored.
teen, 15 to 18. Same. However some money freedom and sex authorisation start to appear here, under the responsibility of the parents or legal tutor.
teen.parental this suffix tells that a parental authorisation has been granted for some sex places. This autorisation can be further specified: teen.parental.all;, or for a list of worlds: teen.parental,~ApplicableTo(,"world1","world2",~); or teen.parental.local; where authorisations are stored into the worlds.
teen.21 is the same as previous, but for 18-21 users living in countries where the legal age is 21. This flag is set only for persons in this situation.
adult 18(21) and more. All rights.
adult.elder this suffix can be added for people aged 60 and more. It provides with the same rights than adult, but some places may bring special content for them. This flag may also provide extra warning when entering into places with sex or violence, but does not reduce any access to these places. Showing this flag in profile is optional.
teen.emancipated for legally emancipated teens. Same rights as with adult.
Some suffixes can add a diese or a bemol to the rights of the person:
adult.guardianship For adults under legal guardianship.
.psy for persons under psychiatry supervision. Only protected environment. Stalkers may also get a .stalker, reducing some rights or warning others of the threat they pose.
parent allows the physical parent or tutor to access the place of their children. This suffix must allow the person for a place he would normally have no access, such as for instance a 14 year old mother to see her baby (as alas such situation sometimes happen)
guest is granted by the physical parents or tutors to the user, to allow him the entry in a children place, under their responsibility. This may apply temporarily or permanently, to adult guests or minor friends, to enter into the indicated place(s). In this case the name of the world(s) is(are) added in a further field(s):
guest.list,"Our children's dream","La chambre de Denis";
nurse, teacher, professor, activityLeader, educator, socialWorker, medicalNurse, physician etc. are numerous other possible suffixes for any educational worker.
(January 25, 2011: the tag ~legal.ageCategory,sexDelinquent is removed of the specifcation, due to widespread abuse of the legal «sex delinquent» qualification against young lovers, or its use for sadistic manhunt games).
cyborg users have the same age rights as human users.
robot users will usually get a robot age category, which allows them to enter any place where robots are allowed, but not sex places or teen/children places. Robots specifically designed for sex need an robot.adult age flag. Robots intended to enter children or teen places will have to be granted a robot.guest flag by the place owner. It would be illegal to entice robots with a parent or physician title suffix, but in some times we may get some interesting robot.nurse, robot.teacher, robot.companion, robot.gameMate, and probably some others. Parents and educators have mandatory knowledge of any robot, and allow only recognized ones, to avoid many specific abuses.
animal users can have all the age categories (but not suffixes) up to youngster, depending on their degree of intelligence and autonomy. The animal flag actually excludes them from any sex places. It also forbids them from children places, unless they get an animal.guest flag. animal.dangerous are forbidden in all places up to teen, with little exceptions such as native cultures.
It is up to the Character Hosting Company to physically check the age of the users, their parental relations, special situations, professional clearances or interdictions. They will use common identity check methods and ask relevant organisms for certifications.
For allowing every reader here, the Development of this chapter has been removed August 4, 2012. However there are accurate definitions, such as for instance
~sex,common, which define a common place where sex is not allowed, but without going so far as monastic rules.
Nudity, as much as sex, needs a match in tastes, and sometimes a legal match with age (although this is not an absolute, as naturism legally go against this). However nudity and sex are not the same thing, and confusing them would bring some issues. So they need a separate flag.
~clothing,... tells the degree of nudity allowed. It applies to the current outfit, so that changing outfit or adding/removing clothes will change it, forcing a new Kmetaconn pairing cycle, which may result into acceptance, warning, or denial (of the change only). Entering a new place with different authorisations will similarly result in acceptance, warning, change or denial of entry.
As for the sex tag, we have first a broad category, and then other special items.
hidden where all the body is covered, including face, hands and feet. (for secret societies and other fun plays).
covered Only the face is visible. But it is mandatory that it is visible, to distinguish from the hidden flag.
ordinary are ordinary long clothes, covering most of the body and feet. This may include, or not, scarves, hats, turbans, gloves, sunglasses, etc.
light allows for short skirts, large cleavages, navel visibility, etc.
bikini is the standard swimwear of this name, covering groin, buttocks and women's breasts.
silks where clothing is reduced to the strict minimum to hide the sexual parts and nipples: tassles, thongs, fig leaves, codpieces... Buttocks and most of the breasts are visible.
nude visible nipples, male and female organs. Some transparent veils, ribbons, jewels, etc. can fit in this category, so long as these parts are not hidden. At a pinch, somebody entirely clothed save these parts will keep in this category.
It is to be noted that clothing reduces the male organs to a simple bulge, covered with a clothe texture. Similarly nipples, belly button and buttocks separation are also blurred. A male codpiece will mould the organs in a specific shape. These effects increase with the number or clothes, their thickness. At the extreme, ample clothes like coats will blur and thicken all the body shape, or add fabric folds. All these details must be accounted with in the rendering of the body shape, and changed when a piece of clothe is added or removed.
The behaviour of the sex parts (erection, swaying, nipples showing through) is determined by the value of the ~sex,... flag. This separation between clothing and sex behaviour is logical, as it is about two things which are not automatically linked. And it allows for a great flexibility, while remaining simple for the user to set.
For instance:
~clothing,nude;~sex,null,common; will set the naturist rules, and ensure that no unwanted erection will happen.
On the contrary:
~clothing,hidden,covered,common,light,bikini,silks;
~sex,light,explicit,romantic (Line breaks are not part of the code)
will allow for male bulge to grow, or nipples to show through. And of
course:
~clothing,nude;~sex,light,explicit,romantic; will allow for erection, breasts swaying, etc.
The ~sex,large,hard; categories will allow for the appearance of some special features of these categories, such as «new» genders. These features may be technically clothes, or parts of the body.
It is interesting that each clothe has its own clothing flag, so that it changes the flag of the character when worn (or removed) or we get a warning, or are forbidden to remove it.
Clothes will also have their sex flag, also influencing the one of the outfit. For instance a tight codpiece may not be fit in a place where ~sex,null; , while a holey shirt will need at least ~sex,light;.
Oversized male parts or bulge will need at least ~sex,light; to appear. Curiously it seems that even massively oversized breasts are much better tolerated, up to ~sex,ordinary; or even ~sex,null;. Second Life experience showed that very small male organs and flat women's breasts are also demanded.
Suffixes will allow to specify more precisely. For instance:
~clothing.covered,ordinary;clothing.feet,nude; makes bare feet mandatory and sets the rule of a Buddhist temple or Mosque.
~clothing.top,...;clothing.bottom,...; will set each half separately. Other possibilities are: ~clothing.hat,..., ~clothing.face,..., ~clothing.hands,..., ~clothing.breast,..., ~clothing.loin,..., etc.
At last, clothing may allow to make mandatory some special clothes (or similar category) such as goggles, hats, etc. for a variety of social, game or professional purposes (such as workplace simulation). For instance ~clothing,eyemask; sets a party with mandatory eye masks. In this case it supersedes the broad category ordinary.
A temptative list of possible special clothes, for a huge variety of purposes (sex not included):
hat, turban, scarf, hairProtection, helmet, goggles, hygienaMask, gasMask, dustMask, gloves, handcuffs, safetyShoes, mask, eyemask, welderMask, marriageRing, buoy, respiratoryAid, function suit, uniform, insigna, weapons, shield, scaphandre, etc.
This whole system, especially the automated clothing correction, removes the risk/fear of being inappropriate, or the hassle of checking clothes all the time, while worrying about many rules in many different places. It will especially avoid the dreadful situations which happened in Second Life, when the user enters the mass without being aware that he still has his erect penis attached (or, more cunning bug, the penis is invisible for him, but still visible to others...). Or when we were forcibly «teleported to a neighbouring sim» without any care if our outfit is appropriate for this place.
This flag tells the vibration level of the place, character, outfit, etc. This word was coined by one of the first abstract painters Wassily Kandinsky, when he compared colours to musical sounds arising emotions in the viewer's mind. It has been generalized since to shapes, sounds, styles, materials, activities, etc. so that the word today often bears a judgement of value, nice things arising good vibrations, such as «a good vibration of flowers and love», while evil or dirty things arise bad ones: «bad vibrations of unwashed clothes and violence». So the vibration is probably the most relevant qualifier of the user's experience in a world: what he is looking for, or what he can expect of a place. The presence of such a flag in a system will be a good indication of its quality. This flag works like the ~sex,... flag, by defining some broad categories, that can be made more accurate with the addition of suffixes.
So the ~vibration,... flag defines what kind of ambiance, shapes, sounds, behaviours, actions... we can expect to find in a place:
angelic is of course the most beautiful we can imagine, pure rainbow colours, magnificent and merry music, absolute kindness, not a trace of violence or vulgarity, etc. The sky is always blue with lights and unearthy effects. Note that the world «angel» does not necessarily refers to Christian mythology, it is just a word everybody understands, or which can be translated with «devas», etc.
elvish is also beautiful, but more natural looking, with ordinary materials (wood, stone, etc.) and landscapes (meadows, forests). But we still have nicer colours than in ordinary Earth, magnificent music, kindness, non-violence, no slang, etc. The sky is mostly blue. Note that the world «elvish» does not necessarily refers to fantazy or Lord of the Ring, it is just a word everybody understands.
Note also that Elvish or angelic characters are not necessarily bound to be in these categories, just that in these categories we expect an elvish or angelic world or behaviour, no violence, no vulgarity, and no such roleplay.
strange is something strange, but not specially beautiful or not specially evil or dark.
human is the ordinary life we all experience, without attempt to make it nicer or uglier. The sky may vary. Starting from here, we can have roleplays with violence, war, fights, etc. provided that the ~violence,... flag is set to the good values.
earthy is about nature, its good or less good aspects. The nuance with human is somewhat thin, but it is the difference that civilisation brought when it modified natural places to create human objects and human purposes. A good caution is to associate these two by default, only some peculiar places need to separate them.
Popular is like human, but much more free/familiar language and behaviours are allowed, tickling the limits. Many places will like to have this comfortable way, away of the efforts of keeping on nit-picking rules.
underground may be obscure, strange, scary, violent, but not intrinsically evil.
dark is more intense than underground, as it may involve evil-looking stuff or characters, for roleplay purposes. It is important in the underground and dark categories to keep on a sane approach and recognition of the good and evil, and play evil only as a challenge for other players. Content which purposely promotes evil or confuse good/evil recognition is NOT part of this category.
About purposely vulgar stuff, evil stuff, «shoot'em all» brainless games, demons, fascism, gangsters, etc. it must be kept in mind that the purpose of the creator of the Kailye language is to foster a better life through a better virtual experience. So this goes as with the ~sex,... flag: people who want this stuff or want to propose evil views are not welcome, and it may happen sooner than expected that moral or legal requirements of the society at large also oppose the fostering of evil views in the virtual: fascism, racism, sexism, violence, dictatorship, terrorism, cults, satanism, torture, crimes, vulgarity, etc. if not already done in some cases.
Many suffixes may be added to the categories above, but the difficulty here is not to fall into defining the theme itself, such as fantazy, sciFi, etc. These indications are the purpose of the ~theme flag. So suffixes will probably be custom created for very specific purposes, such as re-creating a fiction universe with a peculiar vibration.
Of course ONLY ROLEPLAY VIOLENCE is allowed in the WEM system, as coded by the ~violence,... flag. Any other violence is a severe disciplinary issue, including disputes between users about in world matters. It will easily become a criminal issue, especially when this virtual violence is connected to violence in the physical world. This even includes pursuing innocent users with physical war into the WEM virtual worlds, the most serious possible offence which entails the ban of all concerned government from the management of the WEM, and life ban of the concerned users into the Character Hosting Company registry.
In virtual worlds, violence is more specifically verbal or psychological: racism, discriminations, mocking, hazing, engaging in tampered roleplay, stalking, following, spying, entering private places, etc. We also find specific forms of violence such as using scripts to force people into unwanted behaviours, like disguised sex poseballs or the famous «Bloodlines» sect which stalked all the places of Second Life. Destruction as such cannot take place, but there are virtual ways to hinder uses of places or waste landscapes, such as placing cumbersome objects or advertising nearby, or replicators which create many objects in order to crash the simulator and lose recent modifications. Physical violence and rape will become possible with exoskeletons, thus considerably thinning the difference with the physical life, and making our WEM legal system really needed.
So, the ~violence,... flag is used to tell what we expect or accept into the roleplay. Laws usually limit it to the more benign values for children users, save for some definite educational purposes. If they don't, it is common sense to protect children from explicit or extreme violence, which may deeply and durably shock them. Any person has the right of being protected from violence, and even from the simple sight of violence. Games MUST NOT BE A PRETEXT to impose the view of violence for those who don't want.
The ~violence,... flag can take the following values:
policed is for places where violence is a non-existent thing, with politeness and detailed rules carefully avoiding any kind of verbal or tiny abuses: children places, religious places, salons, etc.
peaceful is for places where violence is a non-existent thing, while being much more easy going than policed.
ordinary is for ordinary life, where physical violence is not welcome, but where some light or codified verbal sparing may happen in a soft roleplay.
light allows for open verbal and physical fight, but without actually showing injuries or blood. Starting from light, the use of weapons is allowed. Wearing sheathed or inactive weapons may however be allowed in ordinary, depending on the theme.
explicit may show injuries, pain, screams, blood, etc. This may already be difficult to bear.
extreme is present here only for educative purposes. Normal persons never enjoy to look at extreme violence, so it does not make sense to allow it in a game or roleplay, which are intended to experience fun or pleasant emotions.
Suffixes can make accurate what domain the violence can affect:
verbal is for thought sparing
language is about foul languages, insults, racist comments (in roleplay only, of course)...
physical
objects
capture is about restraining, kidnapping
sexual
psychological is about putting on stage psychological conflicts, harassment, etc.
money is to allow theft.
destruction of in world objects. This requires that these objects are designed to be destroyed.
We must not confuse the previous ambiance definition tags, with the theme itself: for instance a theme like «fantazy» can entail any vibration from elvish to dark, and varied levels of violence, while being usually restricted to the lower levels of sex. But a fantazy theme with an elvish vibration does not necessarily implies the presence of Elves, and Elves are not necessarily excluded from a modern or sci-fi theme. Their presence is safely set only by the ~race,... flag. So what is the theme,... flag for?
The theme is a defined and limited set of elements such as species, style, technology level, purpose, culture, etc. telling in what kind of world and overall purpose we are in. Some proposed base values: none, social, party, nightClub, antic, mythological, tribes, fantazy, middleAge, 1900, classic, modern, furries, sciFi, space, religion, spiritual, workPlace, business, administration, medicine, scienceResearch, etc.
An important point here is that theme is not only for roleplay, but also for any possible human activity which may be brought into the virtual, including what we did not expected in the first place: business, administrations, etc.
For this reason, the first name in the theme hierarchical name is the scope, which can take three values: ~legal.theme, for activities like business, administrations, etc. ~rules.theme, for common life and soft roleplay, and ~roleplay.theme for intensive roleplay places.
But a word like fantazy may be too accurate for some purposes, as it requests a defined set of species, styles, etc. For this reason, we may set broad and specific themes:
~social.theme,broad.fantazy; allows for many kind of creatures, even not really fantazy (like furries) but not modern suits, weapons and gear.
~roleplay.theme,specific.fantazy; will allow only for material likely to be found in works like Lord of the Ring style, although not limited to these.
~scope.theme,specific,LOTR; refers precisely to the species, styles and technologies actually present in the Lord of the Rings. This can however be used for social play as well as for soft roleplay.
~roleplay.theme,specific.LOTR; will be used only for intensive roleplay about events and characters likely to be encountered into the Lord of the Rings.
All the previous flags will determine what kind of outfit is allowed or not, and thus provoke a Kmetaconn command when we enter into a place, or when we begin to wear the outfit. To complement their action, for instance when the ~scope.theme,... flag is loosely defined, we can provide with a proper ~outfit,... flag, with some broad values:
free is any, with the only limit of the ~clothing,... value.
none is for outfits where clothing is not required, such as furries, robots, animals, etc. However ~sex will still determine if a furry has visible sex organs.
themed is for body shapes and clothes matching the theme of the world.
formal means that the clothes must be our nicest clothing, uniforms or insignias telling our position in the group, etc.
professional means that the character must wear some function clothing, like a uniform, a magistrate robe, etc. or at least a T-shirt with some company name or function name. But one must remember that there is no sense at «clothing like an manager» or wearing a «serious suit», especially into virtual worlds which are precisely intended to get rid off such pseudo-social stuff, so we are able to come at the office as a furry or Teddy bear. (We must however remember that our outfit reflects our personnality much better than our physical appearance does. So people will still use it to guess our personnality, and comming to a job interview as a Teddy bear is probably not the best idea.)
Bizarre is for all the strange or nonsensical outfits we could see in Second Life, where each user sets a new category for himself alone. Full freedom to add as many suffixes as wanted to this, but no support from the WEM management.
Of course suffixes can be added for tightening the definition.
It is to be noted that in many cases, we can flag something in several way, using one or the other of the flags above. This is not by purpose, but it is a logical consequence of the overlapping definitions of these words. For instance, we can define a clothing with ~outfit, ~scope.theme or ~clothing as well. To avoid being lost, it is better (but not mandatory) to define things with the flag which is the most relevant to the intent in the place. For instance in a Lord of the Rings roleplay, we use ~scope.theme, because clothing styles are important elements of the definition of each role and character. In a social place, we shall use ~vibration, which is irrelevant in a professional place. This one will rather require ~clothing, because there is a need for special protections. At last in a sex place, we prefer ~clothing too, because no peculiar style is required, while the degree of nudity is very important. The same goes for a monastery, where the degree of nudity is too very important :-).
If we don't care, we could get contradictory flag sets, or impossible combinations such as ~clothing,nude;~rule.theme,religion.monastic."Franciscan";. Useless to try this, even as a joke: the result will simply be a denial of access for everybody, including the joker. Only the creator of the Kailye language would laugh.
An important issue is that a computer cannot check if a clothe, object, etc. matches the values of its flags. This needs some human checking when creating them. In most of the case, the creator of the objects or clothes can set himself the right values, as long as he is not intentionally cheating (such as creating a shirt with alpha texture holes showing breasts when the computer thinks they are covered). About outfits in themed places, there must be some human approval process between the character and the world/place managers. Roleplay worlds will require a checking by a human greeter. In soft roleplay places, the outfit is reputed accepted until a world manager remarks that it is not appropriate. He may then discuss the modification of the outfit, or advise for another, so that the character will not get warnings or denials when entering in his favourite place. Between civilized persons, this can be settled easily.
But if the character is not cooperative, we can think at a system for the place owner to force a change of the rating of the character's outfit. However this would arise serious issues, disagreement on the rating, and especially the risk of abuses of this feature, resulting in serious harm of the user when given a wrong rating which would follow him in all the other worlds. We could even get a rating war, when different world owners give contradictory ratings. It must be remembered that world owners are as much likely to misbehave than simple visitors. But, given their powers, this has much larger consequences. Remember that most of the forum issues in the Internet were not caused by abusive individuals, but by tyrannous forum moderators, or worse, by lax forum moderators allowing for anonymous bullying of contributors. The same effect is multiplied in Second Life, where the most frustrating experiences happen with tyrannous sim owner, into a world which is generally much too lax about griefers, copyright theft, gambling, etc. So we must limit the powers of place owners to only their own place, and under their own disciplinary/legal responsibility, so that their abuses have consequences only into these places. So, in case of an unsettlable disagreement on an outfit, let the place owner decide, up to banning a visitor of his place. But at least this ban is not marked in the outfit, so it does not follow the visitor everywhere. And an abusive ban can be traced and prosecuted.
Some better solutions would be that, as an option set by the place owner or manager, any new character entering the place (or changing outfit) gets automatically a new flag appended to his outfit: ~approval,pending,"place";. This can attract the attention of greeters who can set ~approval,ok,"place";. If not, the greeter can interact with the character. If the later is not cooperative, he gets ~approval,denied,"place";. Of course any edition of the outfit erases all ~approval flags. An inconvenience is that the user may have a long list of ~approval flags accumulating.
To have flags appended to an outfit, clothe, etc. needs to appends a ?Kflags=~flags parameter to the resource URL of this element. Attempt to rezz it starts a specific Kmetaconn process.
Otherwise, the system described above is still versatile and powerful enough to cope with many unexpected cases. For instance anybody entering a surgery room is reminded automatically to wear an appropriate hat, mask, handwash and gloves. Or a character wearing a group tag gets automatically a matching suit or outfit. All these accurate and specialized requirements can be set only with standard functions of the system, without the need of any special scripting or design.
Let us remember here that the user can get several kinds or warnings. Some are just warnings, allowing the user to continue his path, or giving him a chance not to enter in a place he doesn't like. Others will require a corrective action, or tell the user that an automatic correction was performed. For instance his outfit ~theme.LOTR.elf.noldor; is automatically worn when the character leaves his workplace to his game place. And his: ~outfit.professional.seriousNitPickingEtiquette.humiliatingGreySuit; will be recovered automatically when he hits the «boss alarm» button.
Another feature is that, in the inventory, we should have common sub-directories for different directories, or things allowing for instance different outfits to have each different clothes, but the same body shape and skin in common. So that when we modify the body shape, all outfits are modified in the same way.
This system should create a «wear and forget» mindset, where we are sure to avoid any Second Life-style blunder like arriving to the mass with a visible penis, or much worse: being invited by a lady without having one.
It is still easy to cheat with this system, for instance with creating a transparent bra. But this will be noticed immediately by the other users of the world, and cannot be considered as a blunder. Unless the system is smart enough to detect such a thing...