WEM functions of the Kailye language,
Third part

Last update: December 31, 2009 

 

13 - Kflags for groups and covenants

13.1 - The Groups management

It is striking that nobody tried to make a general sex dating system into Second Life, despite the blatant need of many users :-) . Even an established Internet company like Meetic did not attempted something like this, despite the appeal of numerous exclusive new customers (all those who do not want hazardous contacts in the physical world). In a more general way, we could see no large service created, or no established Internet companies trying to enter Second Life. Not only Meetic, but also E-bay, Amazon, Google Search, Google Ads, all are brilliantly absent of Second Life. For those which tried, none remained durably into Second Life, except some which keep a symbolic presence for studying or supporting the experience without any real sale, such as Cisco, IBM or Manpower (which proposed only ONE job opportunity in two years!). Only PayPal has some successful presence under the form of money distributors.

Non-technical reasons are the cost of a large presence in Second Life, the ridiculous change rate of the Linden Dollar, the random functioning of group IMs and group notices, and the erratic management by Linden Labs, which make Second Life so unfriendly to business, without hope to re-establish the confidence before many years.

 

But the reason of concern for us here, is the group structure. Second life's group structure is by far the most advanced available in all virtual worlds. However it already showed its own limits. Most groups need only simple features, like a mail list, or a chat system, without all the complex permissions checking which are said to load the servers, so that Linden Labs set the (in)famous 25 groups limit. On the contrary, large social groups, and all the more groups for business and companies, need more complex structures, such as specialized communication channels, hierarchical organisation of services, etc. This led most social communities in Second Life to have several groups and their own Internet site, to be able to organize and discuss all their needs. Not to speak of real businesses, which have simply no means to organise, even a simple working contract.

 

But a less obvious and still more stringent reason is the closeness of Second Life: it is impossible to automatically check if an user in Second Life is the same as an user on an Internet site, for instance Meetic. And it is difficult to communicate between the two realms, Second Life and the 2D Internet... All this makes that it is impossible, for instance to put an user of the Meetic Internet site in relation with an user into Second Life. Not to speak of a Social Security office, which has no mean to check the physical identity of the character who claims his rights... and nothing proves that it is a real Social Security office anyway!

 

So the needs clearly are:

-federated identities working for both the Internet and the Metaverse.

-small or simple group structures in world, organized at the level of a platform world, see at the level of a basic world owner.

-large group structures, led from Internet sites owned by the organization, and controlling group functions in world. For instance, chat could be done between the Internet and the Metaverse, Internet documents could be accessed from the Metaverse, group functions could be managed from the site.

The obvious prime condition for this last point is that all the elements of the Metaverse obey the same URL address system than all the Internet elements. This is of course also true for documents and databases describing the group functioning.

 

 

Now that the needs are known, we just have to make the WEM system to automatically cope with such a system. At first, when there is a Kmetaconn round to enter a place, the simulator tells that among the connexions it requires, there is one toward the Internet site of the organisation, in order to check things like group authorisation access, roles, etc. In the case of a small or simplified group running in a platform world, it too appears as an Internet resource on the platform's site. The first consequence is that there is no sense at limiting the number of groups for one user, as only one or few groups are checked at a time.

 

A little difficulty here is that we now have two computers on the world side: the simulator and the Internet site. As automated decisions can be taken into only one place, only one of the two can be the peer in the three-parties WEM link. Then, in this case, the other will be the squire. Starting from here, there are several way to organize them.

The first method is that flags and authorisations are controlled by the simulator, which is then the peer. Then the simulator asks the Internet site for complementary flag values (such as group belonging), so that this Internet site does not appear into the KmetaConn process. Of course this simulator must manage the place where the group rules apply. This method is simple, but slow, as the data has to be relayed. It will be preferred for simple groups hosted in a platform, as the platform will make servers available for this purpose, with a fast link.

This first method can be much bettered if the simulator includes group features and is able to run the group's functions and store its data, with or without dependency on a platform. Ideally this group data should be able to appear on an Internet site run by the same server. This suppresses the need for relaying data. This method is perfect for small or simple groups in the Second Life style. Companies wanting to market individual simulators must keep this important requirement in mind, and propose a correct set of group functions, even on simplified products.

The second method allows to pull more power out of the Internet site, by making it the peer in the Kmetaconn process (in a search, one finds the address of the site, instead of the address of the simulator). It has to manage the members list, the authorisations, flags, etc. The simulator would then be the squire. The squire may still has its word to say, for instance if the group's place is in a platform world, toll world, or a larger community. So the peer will use some Kflags for checking general access conditions, rules, etc. When access is granted, the connexions are established to the world.

This second method will be preffered for large organized groups, companies, administrations, etc. whith a large and complex main site managing many different simulators or places in the Metaverse.

The third method is when we have a themed platform world, where a group or a company is operating, without having its general quarters here. In this case, the themed platform is the peer, but it is clear in this case that there are important data to request to the Internet site of the group or company, which will be then the squire. These requests will use classical Kflags. But It clearly appears in this situation that private data has to be protected from the platform world. This is however a built-in protection featured by the Kmetaconn process, as this data goes directly from the viewer to the squire, without transiting through the platform.

In the case where the world and the site communicate directly without passing through the Authorisation management Connexion, then this is a specific Kailye link established between the simulator and the Internet site. It can use the basic kailye syntax, with at need some specific extensions for group management. Anyway it is a stringent requirement of the WEM architecture that this link is established through the WEM connector.

 

13.2 - The group Kflags values

The most obvious group flag is membership. The role in the group follows just after. Roles may, or may not, be organized in a hierarchy. After, there can be many kind of authorisations, role per role: accessing chat, rezzing objects, managing the group... It is up to the group management system to assess all this, and give relevant replies in a Kmetaconn request, depending on the group and role belonging. And if we want any degree of interoperability, the different simulators will have to react in the same way to each of these functions (or at least to ignore the ones they don't recognize, without obtruding the others).

 

The first thing is to define a group flag:

~group,"humanReadableName","computerID"; defines, in this order, a group. One of the two fields may be empty, because we may have robot-created groups. Both names are between "", because any system may use non-Kailye characters.

~role,"humanReadableName","computerID"; defines a role in a group.

Usually group name and role names go together. So they are combined into only one line of the ~Kflags table:

~group,"Elf Circle",,~role,"greeter",,~role,"bard",;

We note here that the character belongs to two roles, and thus he cumulates the abilities of both. We also note that the "computerID" fields are present, but empty.

If, on the contrary, we find first a role name, followed by several group names, it is that these groups have a role in common, for instance several companies which have a common service (or several roles hierarchy levels having a sub-level in common):

~role,"guardian",,~group,"Elf Circle",,
~group,"Elven Bards and Storytellers",;

In this case the character also cumulates the abilities of all the groups, but if one ability is specific to only one of these group, it remains applicable only about this group's places, characters, objects, etc.

 

If the character interacts with a place, character or object, where his rights depends on the group or role belonging, then the simulator sends the group and role name into the Kmetaconn cycle.

 

And, to the contrary of Second Life, it is the place which looks if the user has one of the groups or roles pertaining to the place. So that only one (or few) check has to be performed, whatever the number of groups the character is in.

 

It is to be noted that most flag checking are done by the Character Hosting Company. But secret info, such as passwords, fly directly between the user and the world, using the command Kflags. This can also be true for secret groups, or if the user does not want to display his belonging.

When the group and role belonging is checked, then the world, or the group management, can assess the rights of the user, with one of the methods explained in the part on groups management. Then access rights are determined, together with all the values of ~theme, ~outfit, etc. allowing the Kmetaconn pairing process to complete.

 

13.3 - The group hierarchical structure

The idea here is to have organized groups as in Second Life. However Second Life groups are not hierarchical, have a limited number of roles and only one communication channel or mail list. For small or simple groups, this is far enough. But experience showed that large social groups, not to speak of companies, need a more complex structure, with a hierarchy and several communication channels. It is in theory not the role of the Kailye specification to define this, but if a given group has to run with several different systems, then a common definition of rules becomes an important interoperability feature. Free, of course, to each system to add specific features, so long as they do not contradict the standard.

 

The idea is to have a hierarchy of roles. Each hierarchy level has one or several leaders, authorized to set roles and rights at his level. However restrictions are cascaded from higher roles to lower roles. Only the highest level can bypass this rule. (only «the highest», and not «a higher», because this would allow a lower level to subvert and control the whole group)

 

Basically a role is defined by a hierarchical naming:

~group,"group name",;~role,"level1"."level2."role",;

for instance:

~group,"Chaussures Grôle",;~role,"direction".
"Services financiers"."comptable",;

or:

~group,"Romantic Loves of Arda",;~role,"Elves"."Sindarin",;

As explained in the groups Kflags values, a role name followed by a list of group names tells that it is a common role for these groups, having the same abilities.

 

The creator of the group has all the abilities when he starts: determining the group name, insignia, roles, members, roles and abilities of the other members. He can also add new leaders, and resign his own position.

Such a group structure, as seen in Second Life, has leader(s) and members, all gathered into one level (the group) The roles are all into this unique level, only the leaders having all the powers.

To add a hierarchy structure, we just need to give to a role the same functioning of a full group, with a role leader(s) and role members. These sub-group leaders and members just have less abilities than the main group members, as restrictions are cascading (save if the group leader decides to grant some extra abilities to the role leader(s) or members). For instance:

-An Elf group has an Elder (leader). He is the leader of the whole group.

-A role is for all the members, where they enjoy only limited abilities of ordinary membership, such as being unable to add new members. This is the classic definition of a non-hierarchical role in a Second Life group.

-Another role, the greeters, have a leader(s). This make of this role a hierarchy level. The members of this role have limited abilities, save a special grant of the Elder of the ability to add new members.

-The greeter leader can manage the greeters as a full group, and for instance create sub-roles in this level, such as apprentices, teachers, etc.

 

The interest of creating a hierarchy level (here the greeters) is that this sub-group will be able to get its own communication channels, documentation and abilities, and evolve of its own, without a need for constant interventions of the Elder. And in software this is achieved only by a recursive use of the group functions.

 

There is some confusion, thought, between words like group, role, hierarchy level, etc. So let us state the following definitions, which wording is part of the standard:

A group:

~group,"group name",;

has roles:

~group,"name",,~role,"role name",;

One of these roles is for the leader(s) role:

~group,"name",,~role,"boss",; of the group, who have all powers on it.

A role without a leader is just a role:

~group,"name",,~role,"role name",;

A role with a leader is no longer called a role, but a hierarchy level. Just as a group, a hierarchy level has a leader(s) role:

~group,"name",,~role,"hierarchyLevel"."boss",;

and roles:

~group,"name",,~role,"hierarchyLevel"."role name",;

Each of these roles can become in turn a lower hierarchy level, as soon as it is given a leader.

 

We note that it is, in fine, the use of a dot character which defines a hierarchy level into the syntax. And of course the hierarchical naming of roles follows the group hierarchy.

We also note in the examples that the computerID fields are empty. In case they are used, the same rules apply, with hierarchical naming too. Any mix of human or computer names is valid.

 

Here is a list or abilities which can be considered as standard and mandatory. This list arises from a critical analysis of the Second Life model.

-Naming the group, managing the group appearance, (insigna, etc.) Top level leader(s) only.

-Assigning new leaders, resigning from leadership, closing the group. Top level leader(s) or vote result.

-Create, delete, edit roles, set their abilities.

-Changing a role into a hierarchy level, adding non-cascaded authorisations to a hierarchy level. Top level leader(s) only.

-Enrolling or ejecting members of the group or hierarchy level, or set free enrolment.

-Assign people to roles, edit role flags and abilities

-Assign places, content, objects, documents, Internet Resources, to the group, role or hierarchy level.

-Access databases, ftp, etc. of simulators or Internet servers belonging to the group or hierarchy level.

-manage places («lands» or simulators) belonging to the group, set land access, land flags.

-edit content of the lands belonging to the group or hierarchy level

-edit and manage objects belonging to the group or hierarchy level, set their flags

-edit and manage documents belonging to the group, role or hierarchy level, set their flags

-edit and manage internet resources (pages, forums, etc.) belonging to the group or hierarchy level, set their flags

-deed or lease objects, land, money, rights, etc. to the group or hierarchy level.

-accounting (real money, fictional money, vouchers, barter, distributive money...) Of course any legal currency must be appear with the ~legal flag. On the countrary, a ~roleplay currency used into a game is illegal to exchange against a ~legal currency. (this is a request of games editors, to avoid character farming, money laundering, illegal work, etc.) Distributive money and other alternative accounting systems may be flagged ~rule, meaning that they have a real value, while having no defined legal existence. They may, or may not, be exchangeable against a ~legal currency. However they still define a legaly valid ownership of goods, and thus abuses can be legally considered as a theft. The Linden Dollar falls under this category, as it has no legal tender, while being exchangeable againt the currency of the user, and usable to buy real property. These definitions are stated here, precisely because existing laws are not clear about these new situations. And it is better that ~rule or ~roleplay currencies never bear the name of a ~legal currency.

-set and manage several mailing lists and chat channels for the hierarchy level (or a larger scope if set by a higher hierarchy level).

-have one-way or two ways chat channels

-organise votes. Votes can be on regular schedule, on leader's decision, or of popular initiative. They can be about decisions, about replacing or challenging leaders, etc. with many sets of possible rules.

All these abilities should be described for each role as as Kailye ~roleAbilities,ability1,ability2,...;. However this is too much an extrapolation for this version zero, and need some experience feedback. Version 1 must have the entire list implemented. Hierarchical naming of new/custom abilities (or modified abilities) must be possible at any time. For instance roleplay abilities may be things like taking prisoners. Technically, prisoners can be a role in a hierarchy level.

 

 

A group is defined in the computer as a set of four entities:

-A database of all the roles, with the abilities, ownership, etc. for each. The index is the Hierarchical name of each role.

-A database of all the members, which of course give for each their role(s), and any other info deemed useful. These two database can also contain Kailye flags.

-A human-usable hierarchical directory tree of documents, organized after the hierarchy levels of the group, with cascading permissions. Each hierarchy level leader can manage his own level, add sub-directories, etc. and can even grant a sub-folder to an individual member. This directory tree contains all the documents belonging to the group: group charter, rules, working documents, contracts, archives, etc. and it can be used as of any computer directory tree.

-A charter text which defines the group, and which can be told in Kailye with the Kovenant command seen further.

Kovenant.rule.charter is a group charter, a document with no legal value, only a discipline value. Kovenant.roleplay.charter is a guild charter in a game. At last Kovenant.legal.charter sets a legal charter, such as for a company, administration, etc. ?Kflags can be added to the Kovenant command.

-Each hierarchy level can also create one (or several) chat systems, mail lists, etc. covering all the members, or only some roles. These systems can be used in one-way of two-ways.

Companies, administrations, etc. all already have structures obeying more or less such an organisation, or can easily adapt it for their own uses.

 

An alternative way to group hierarchy is group associations: when entering in one group, the character automatically gets into a second one, in a transparent way. If he leaves the first, he also leaves the second.

This allows to have mirror groups, allowing for instance a group to have several chat channels, one free to all, and a second with a one-way chat channel, or an emergency call chat channel.

But this also allows for another kind of hierarchy of groups, where power rises from the base instead of descending from the top. For instance several groups with similar purposes, but incompatible management, can have their members into a common larger group, used for things like news channels, emergency call channels, aid resources, etc. In doing so, each of these groups remain master of its own destiny and interests, but it can delegate a chosen part of its resources to a common interests, in conditions that it controls. On its side, the common group(s) have much less power than the basic ones, just for accomplishing its special purpose. In the reverse way, the top hierarchy group will define simple rules for the whole assembly, to which each basic group will refer, free to each to add more specific rules or exceptions. For this, they will call the general group's rules in their charters, with an hyperlink or with an <include> HTML tag.

It is this kind of thing which would happen in the Fantazy Continent in Second Life, if similar themed groups could create a common guard service, event notice service, etc. For instance the «Fantazy Continent Group» would manage common affairs such as placement of lands, growth, etc. Its charter would refer to the Common Behaviour Rules Set, to a definition of fantazy, and forbid public sex and nudity. A peculiar group may refer to the previous, while defining a more peculiar theme (Elves, Faeries, Dragons) or specify an exception such as allowing public nudity into their places.

 

 

Place ownership can be deeded to group. In Second Life, characters can deed land to the group. But in case of a disagreement, the character is always able to recover his land. This is understandable, as he is the one who paid for it. But in recovering his land, the character is, in a way, stealing the notoriety of the group to his own usage. To solve such issues, we need to create a better system. We can allow for full ownership of land to a group (or hierarchy level). But in this case, of course, it needs to pay for it. But, in virtual worlds, there is no such thing as a real «land ownership»: we just pay for the web hosting of some 3D stuff, which can be land, but which can also be a spaceship floating in space. Of course this grants us full usage of it, as in a real ownership. But, as anything on the Internet, it is not really bought, it is paid like a rent to the web hosting company (unless we buy our own server). (The idea of «buying» a virtual land AND renting it is unique to Second Life, and is part of its imposed real estate roleplay). So, technically, changing the ownership of land is just changing the renter, without any real buying or selling: it is a free transaction. This is true with character to character transactions, but also for character to group transactions (and any other): once the renter name is changed and the receiver pays the rent, he is full owner and the first cannot retrieve his good. However there are exceptions, as the place can get a value due to its fame, name, brand name, customer base, users base, content, etc. So in this case, the transaction entails a payment of a one time cost, as in a normal selling. But this cost is for the abstract value, not for the hosting itself. And if a character pays the hosting of a land for the use of a group, and wants to recover his hosting, he can either recover his hosting for free, but nude of anything belonging to the group (name, brand name, repute, users, content), or pay to recover the whole thing, as in an ordinary buy/sell transaction. This is nothing new, it is just what is practicized for domain names, which change ownership for very low or very high price, depending on their fame, and independently of the web hosting itself. A place name in the Metaverse can thus be compared to a domain name, and in practice it will often be actually a domain name.

 

 

It was often said that groups in Second Life were not democratic, from the absolute powers of the owner. This was however compensated by the fact that group leaders need members, quite simply, and just cannot chase all of them with unpopular decisions. The only formal vote feature in Second Life groups were the «proposals», but they were seldom used, (from the huge abstention rate...). However we can implement vote features into groups which want them, with all the variety of possible vote criteria. Of course it must be entirely automated, from secret booths (coded Kailye fields) to the automatic removing/adding or leaders into their position. But, to avoid obvious cheats, this should be a service provided by a third party, not a feature of a simulator owned by the challenged leader :-).

Votes are an example where checked identiies are paramount. The reason is that only one physical person must vote, that is only one ~legal identity, even if this person has several social ~rule identities (anonymized social names)

Also, to be valid, votes must cope with the huge abstention rate of accumulating «dead» members, who are still in the group but no longer come in world. Such members should be automatically removed from voters lists after some time. The best would be that «dead» members are «ghosted», that is placed into an invisible rôle. Should they reappear, they are automatically resurrected. (Banned members too are in an invisible rôle).

 

It is to be noted that white lists, ban lists, companies, contracts, marriages, etc. are technically groups, and they can be managed by the same systems.

 

 

 

13.4 - The Kovenant command: rules and contracts.

The Kovenant command defines a text as a covenant, association, contract, rule, charter, or anything similar. Without entering into why contracts exist, we can say that technically a contract is a text listing several persons or groups or organizations, and describing their rights and duties in this association. This word «covenant» was chosen as being the more general, without bearing the «negative» business connotations of «contract», especially applied to marriage, game, etc.

We are today (2009) far of making a computer able to understand all the possible rules and contracts, and all the more to automatically enforce them. So a contract, rule, etc. will basically remain a text intended for human reading. But it is interesting if this document (human readable) contains a Kailye message (under the source form, so that it remains both human readable and computer-friendly). While doing so, we can automate things such as role belonging in a group, access rights in places, money exchanges, group abilities , etc. with just using Kflags values. Eventually this document could contain no text at all, just listing resources such as the human readable document, official law sites, or worker's conventions. It will also list characters (users) or groups (companies) as URI resources.

 

At first, we must specify the scope of the Kovenant command. The scope has the same three values as the Kflags:

Kovenant.roleplay has its value only into the concerned roleplay, and it may be illegal to enforce as a legal contract. The roleplay rules may consider violating the covenant as part of the game, but cheating in the roleplay rules themselves is a discipline issue. To make this clear, game rules are defined with the following:

Kovenant.rule has a disciplinary value in a place, group, or in a platform world. Violations are not legal offences, unless they are large or repetitive enough to come under this definition, such as for instance stalking.

Kovenant.legal has a real legal value, even if it is purely about virtual stuff.

 

Basically the document will contain a Kovenant command, pointing at the text of the covenant.

Kovenant.scope.charter="text"

or it will define where to find it, with a name:

Kovenant.scope.charter=scope$name$

URI?KID=scope$name$?Kfunction=charter

 

Then we need to define the parties, which can be characters or groups. For each:

URI?Kfunction=member

Kfunction can be many. member is the most general, but we can have many kinds of functions, for characters, groups, documents, etc.

 

URI?Kfunction=law is for a link toward the ad-hoc juridical site. Or:

URI?Kfunction=collectiveConvention

We can also have, for disciplinary rules:

URI?Kfunction=rule

Or, for a roleplay:

URI?Kfunction=roleplayRule

Etc.

 

We already saw the group charter as a type of covenant: Kovenant.roleplay.charter.

 

The simplest covenant is marriage. It is displayed into the character's profile. Of course the profile could display separately the real marriage (of the users) with Kovenant.legal.marriage or a roleplay marriage (of the characters) with Kovenant.roleplay.marriage, if the users deem this compatible. Non-standard marriages (homosexual, multiple...) are also possible, but not legal, so that they can only use Kovenant.roleplay.marriage.large, and in more they will be visible only in places with at least Kflags=~sex,large; and appropriate options. The Kovenant command is followed by the spouses names with URI?Kfunction=spouses, and accompanied with the human syntaxed text describing the union.

 

The most common covenants are working contracts: Kovenant.legal.workingContract. They can list some specifics, like an outfit, automatically log presence times in the working place, and automatically calculate and give the pay. Care should be taken of disguised real work declared as Kovenant.roleplay.workingContract. In this case, ?Kfunction will usually take the values employee and employer.

Business contracts are of the same kind, but larger, and more complex: Kovenant.legal.business (Second Life suffes of a blatant confusion between this case and the following: Kovenant.roleplay.business). They can use the group features to set many roles in the contract, and use hierarchical naming to describe all the positions in ?Kfunction. But the variety and complexity of business contract makes that they are not detailed in this version zero, and probably only some common cases can be implemented in a standard.

 

Land covenants are the only real contracts in Second Life, when an owner is renting land plots (or more accurately hosting computer resources, as land is not a real thing in virtual worlds). This can be useful in platform worlds, or in large social worlds to help share the hosting cost. Many large social groups in Second Life are having large lands by renting most of them to members, with a strict building/use code fitting the group's purposes. Usually the covenant is listing conditions such as a theme, which can be easily translated into Kflags. We can use for this purpose Kovenant.legal.renting, listing first the owner and after the renters. This can be coordinated with a group, if the covenant is made the charter of the group: Kovenant.legal.charter. Of course we can too have Kovenant.roleplay.charter, if the game needs it, or most simply Kovenant.rule.charter.

Often the simplest way to automatise covenant actions is to set a group, with the contract as a charter. Then the Kailye Klags just have to link the persons of the contract to a role in the group.

 

The organic combination of the general methods described here, such as groups, covenants and land ownership, allows to create most of the detailed and accurate situations which can happen, without the need of large management software. They can work with any simulator able to execute the whole set of Kailye commands. This will be enough for most social activities, only companies or administration may need to add special software on their internet site. They however need only standard 3D simulators. Even things like the famous confidential teleconferences requested by companies to be able to work in Second Life, need only to tell a Kailye resource showing the address of this system, with just standard simulators. The system itself can be any off the shelf chat system. A routine Kmetaconn command is then enough to connect to this system, with all the safety and privacy requirements of an expensive specially designed system.

 

13.5 - The ownership Kflags values

At first, any object will exist as a prototype, which is only its description in a file(s) on a mass storage memory, which can be either in a personal space in a Character Hosting Company, a simulator, a copyright server, or any other place on the Internet. But when this object is rezzed somewhere in a world, then it is said that an instance becomes visible in the simulation. In the software it appears under the form of an object (in the sense of object programming: a handle or something) in the RAM, including a reference to the prototype file. The rendering system will call for the prototype to know the 3D description, while the simulator will tell the position and behaviour of the instance.

In the WEM system, this mechanism can happen into three basic modes, depending on how objects are simulated: hosted, handled, or monitored. (A fourth mode, haptic monitoring, works like a simple monitoring from the ownership point of view)

With hosted objects, any new owner gets the full prototype file into his own inventory, with all its elements. When an owner rezz the object in a world, the prototype is added into the simulator's mass memory, and the owner is now technically free to add as many instances as he wants into this simulation, on on his body.

With handled or monitored objects, the prototype file remains stored in an unique place, and only instances will appear in a given simulator. In fact the simulator gets only a geometry hierarchy file, containing only the geometry hierarchical organisation of the object and bounding boxes, but stripped of 3D descriptions and URLs of textures, sounds, etc. This full data goes only from the Copyright Server to the Character Hosting Company, in order to avoid exposure of this data to pirate simulators. In fact, to have an unique prototype and a geometry hierarchy file are options with handled objects, but they are mandatory for monitored objects. (it is to be noted that any hosted object may be at times handled by another simulator, for instance when the first simulator is overloaded and wants to share its load. but we speak here of the basic statute of the objects)

 

This functioning has obvious implications on how ownership and copyright protection can be achieved. And any object creator will have to select one of the three modes anyway.

The hosted, handled or monitored statute is not a flag we set, it is a basic property of the object, which depends on where it is hosted. For instance an object hosted on a Copyright server will automatically get an handled or monitored statute, as the full prototype file cannot be loaded by a simulator. An object created in world, or imported by an user, is stored in a free access internet place, so it gets an hosted statute. But if the creator places his object in his Character Hosting Company, then the object will automatically be handled or monitored. We can even not choose between handled or monitored, since this depends of the ability of standard simulators to animate them or not. The only real choices left to the creator are, for handled objects, to allow for duplication of the prototype, and to use a geometry hierarchy file or not. These choices are imposed for monitored objects. (this is because monitored objects already have a better protection, so it is better to keep this protection untouched)

An hosted object has no intrinsic protection against theft, salvage duplication, etc. In Second Life, free transfer objects were exposed to a special crook activity: reselling them to unsuspecting customers. Even protected objects were still vulnerable to the copybot script (although it was not created for this purpose). So hosted object can be only objects of little value, very specialized (posters, etc.), or widely spread objects... We can still add them some flags such as prohibiting transfer, deeming them to a group, etc. but technically they remain exposed to pirate simulators able of ripping all their content.

An handled or monitored object has a much better built-in control, since parts like textures, 3D description, sounds, etc. cannot be accessed by the simulator (and, in the plain WEM architecture, even the user cannot access them, since he receives only a video, not a 3D scene). In fact this built-in protection is one of the main reasons for the three-parties WEM architecture.

So the WEM architecture fulfils an important requirement of content creators, whatever their motives (business, social, leisure... even free stuff creators loath to see their free gift resold, or worse, wrongly copyrighted).

 

 

Once this mechanism set, we need an ID system for the prototypes and instances. Of course, the prototype file can first get an human readable name:

?KhumanName="Table de nuit"

However a computer ID of the object is different of the ?KID used to name resources in a Kailye message, as it must be universal. A simple way for this is, again, to use an URI. This is enough if we don't want any protection of the object. For instance:

protocol:subdomain.domain.ext/path/filename.ext
?KhumanName="Table de nuit"

is enough to identify the prototype of an hosted object.

 

But handled or monitored object prototypes need more accuracy. First, the URI is into a Copyright Server or a Character Hosting Company, or any other safe place.

The parameters which follow are to set the creator name:

?Kowner.legal=~author.physical.name,"user name";

?Kowner.legal=~author.character.name,"character name";

Then the copyright owner:

?Kowner.legal=~rightsOwner.physical.name,"user name";

?Kowner.legal=~rightsOwner.character.name,"character name";

Of course copyright is a legal thing, so the character name is not here for roleplay, it is only if the user does not want to disclose his physical identity. But this does not prevent the copyright to be a legally valid one. It is also possible to set ?Kowner to ?Kowner.rule or to ?Kowner.roleplay, althought this is seldom useful for prototypes. It will be more useful for instances.

Then we have the ID of the object into the Copyright server, the licence type (free, copyright, GNU, GNUGPL, patent, brand, etc...) and the reference of this licence (patent number, registration number, URL of a copyright evidence...):

?Kowner.legal=~prototype.ID,"ObjectID";

?Kowner.legal=~prototype.licenceType,"type";

?Kowner.legal=~prototype.registrationCompany,"name";

?Kowner.legal=~prototype.registrationCode,"code";

?Kowner.legal=~prototype.registrationCertificate,scope$name$;

URI?KID=scope$name$

 

Now we need an instance identifier. For hosted objects, it can be any which fits the simulator's methods. But handled or monitored objects will need a centralized instance ID allocation for the object. Remember here than an instance is no longer a file, but some kind of handle or index into the computer. However this handle still needs to refer to the URI of the prototype, so we still need the full prototype name. So the syntax is:

?Kowner.character=~instance.ID,"InstanceID";

?Kowner.character=~instance.owner,"character name";

still appended to the URI of the prototype, as a parameter. Of course the character name is the owner of the instance of the object. We can have instead:

?Kowner.physical=~instance.owner,"name"; or:

?Kowner.character=~instance.owner.group,"name"; or:

?Kowner.character=
~instance.owner.group.hierarchyLevel,"name";

This instance ID is attributed by the Copyright Server or a Character Hosting Company, when it serves the object. It may require a fee (buying, renting, etc...) a voucher, subscription, etc. (they use the same syntax as with the name Kflags values). The Copyright Server may also limit the number of instances, down to only one. All this is assessed by the Copyright Server when it receives the Kmetaconn command. This server manages its instance names list.

 

At last we can set some visible Kflags values which set the permissions of the objects:

?Kowner.character=~permissions,

copy.anybody,copy.group,copy.hierarchyLevel,

move.anybody,move.group,move.hierarchyLevel,

edit.anybody,edit.group,edit.hierarchyLevel,

giveTo.anybody,giveTo.group,giveTo.hierarchyLevel,

sellTo.anybody,sellTo.group,sellTo.hierarchyLevel,

nextownerCan.copy,nextownerCan.move,nextownerCan.edit,

nextownerCan.give,nextownerCan.sell,

deedTo."group or hierarchy level name",

Price,sum,sum,legal."currency",

Price,sum,sum,roleplay."currency";

If any of these keywords appears, it means that the corresponding permission is granted. By the way we correct here a confusion into the Second Life system, where «next member can give or resell» has only one check box. If one sum is specified, the other field is left empty. If two are specified, it is a min and max price. Currency can be legal or roleplay. A true roleplay currency is NOT legally exchangeable with a legal currency. Alternative economy currencies, implying a legal ownership, while having no legal tender, get a rule. At last, the flag ?Kowner.character=~permissions can apply to a group, a group hierarchy level, etc. And ?Kowner.physical=~permissions applies to physical owners.

 

Of course these flags are set by the creator of the object, and later by the Copyright Server when instancing the object.

 

We know that all these flags can be ignored or stripped away by simulators not obeying the WEM standards. But it is to be reminded here that it is a legal offence to remove these flags, as it is to strip off the copyright notice of a book, or steal objects, receive or resell stolen objects. If the WEM standard irretrievably links technical requirements and legal requirements, it is for a reason, and if problems arise, the WEM system may ignore non-standard worlds or simulators, or Copyright Servers may refuse to serve objects to these worlds. Worlds not complying to civilized standards like the WEM or similar may even end to be outlawed.

 

Other protections not covered in the Kailye standard would be DRMs, watermarking of objects, textures, sounds, etc. Copyright Servers may also log unauthorized characters or worlds.

A good idea seems that each simulator sends its type, so that we can trace non-standard simulators. However it would be very easy for pirates to thwart such a measure. However we can still have: URI?Ksimulator.type="type","version" for purposes such as maintenance, completing unsupported features, etc.

 

 

13.6 - The privacy Kflags values

One of the barely visible mistakes of Second Life, but with terrible consequences, is the lack of a private statute for places (and also objects, documents, etc.). This lack of privacy appears under the form of people popping into private places (It is easy to enter even in locked houses), or more perfidious, people deporting their viewing point («caming») from a public place to a private place, and, from here, see, hear, spy on chat, and even use objects, steal copyrighted textures, etc. This incredible situation results in the whole Second Life having de facto the juridical statute of a huge sex club (or worse), including the public places and all the places which are intended to be free of any sex. But rather than correcting this mistake, Linden Labs prefers to forbid the access of Second Life to minors. A forbidding which, in such conditions, is widely considered a blatant discrimination.

It is then obvious that a flag must set the privacy statute of any place, object, document, etc.

?Kflags=~legal.privacy,statute;

There is only a small number of values for statute:

public sets the access free to everybody, without any peculiar restriction, save some general flags like ~clothing. This could be places owned by groups, persons, or general free places (nature, parks, malls, railway stations, etc.) set up by platform worlds, see by states or by state unions. It would however be a contradiction to set this flag together with children or sex flags. So places having such flags cannot take this value, only some of the values under.

public.themed is the same as previous, but this place is controlled by a group or organisation with a given purpose, which allows for some restrictions such as in ~theme. Theme can be any, such as an epoch, a specie, a business, children, etc.

private.open is owned by a private group or person which has the right to restrict access to a given purpose, or set more restrictive disciplinary rules. However anybody fulfilling the criteria can still enter without asking a permission. This can be for roleplay groups, commercial places, children places, sex places, with all the corresponding access restrictions.

private.limited is the same as previous, save that the access is no longer automatic, but relies on a white list of authorized persons. Eventually guests could be teleported or invited for a one time visit (they cannot re-enter after on their own initiative). This statute is for homes, companies, workshops, schools, clubs, etc.

secret works like private.limited, but the stake is to protect vital administrative data, industrial secrets, etc. So a violation of this is a much more serious legal offence than just a home violation: it is spying.

the suffix state tells that the place is state owned. Similarly we can have union and even UN. We can make them more accurate: state."name", or union."name" (USA, EU, etc.) Of course these flags can be set only by the real organisations, after case per case checking by agents of the WEM management. roleplay representations of these bodies are allowed, if their use does not fall into defamation or abuse of confidence.

 

It is important to note here that these flags do not have a roleplay value, but a legal value: public or private, whatever the motive for this public or private statute. Violation of this privacy must result in the same criminal penalties as in the physical world, as they provoke the same troubles: seeing nudity, sexual activities, private opinions, private religious activities, health issues, violating human dignity, etc. These troubles are the reason why privacy is protected by laws in the physical world. When these trouble happen in the virtual, they have the same consequence, so the law also applies in the virtual. And any discussion on this is void, even by Google: as soon as the place owner sets a ?Kflags=~legal.privacy,private; on his place or object, it means that he uses his legal right to consider a place as legally private, resulting in the place being legally private, period. Violating secret is still more serious, as it entails spying in the primary sense, for instance spying on industrial processes, journalist's rights, etc.

 

The ?Kflags=~legal.privacy,private; can also apply to a chat: in this case, the flag is added to the Konnect command, and it applies to all the resources which follow (in this case, a chat between URI or addresses). The ?Kflags=~legal.privacy,private; can also be followed by a list of characters (as URIs). In this case the characters in the list are allowed in the privacy, and others are not.

 

Of course we can have ~privacy.roleplay,statute; and in this case it is only in the roleplay, so that the trespasser only has to fear virtual arrows and swords.

Dividing land or space for setting privacy (or any other flag) can be made in two ways:

1) setting a land division as a private plot. If a place is private, the privacy will translate in the virtual space as a set of non-penetrable invisible bounding boxes. (which eventually can be clothed with visible stuff)

2) directly setting an invisible bounding box. This will allow to set privacy rates or other flags at the level of a storey, a room, or even a single furniture, a box.

In a general way, any flag set for a place is valid for any subdivision of this place, unless another flag sets a different value for the subdivision.

 

 

13.7 - The Kovenant command

 

Rules are for discipline into the world. Their violation may entail various degrees of ban, but will not result in a judiciary action (unless it is repetitive or serious enough to legally constitute a harassment or other abuse). In a roleplay, breaking the rules is also a discipline issue. But of course this does not apply to cheat, treachery, etc. into the frame of a game plot. This is not a discipline issue, even if, into the game, they can result into a roleplay trial or punishment of the roleplay character.

During a Kmetaconn process, when entering a world or when moving to a new place, the world sends to the user:

Kovenant.rule.placeRules="text"

in order to tell the rules for the place. Of course other Kflags also tell some rules like clothing, theme, privacy, etc.

As seen in the part on covenants, we can also have:

Kovenant.roleplay.placeRules="text"

or

Kovenant.roleplay.placeRules=scope$name$

URIofTheText?KID=scope$name$

Such rule set should be kept short (512 characters in Second Life, at best 1024) so that people can read them easily without waiting for minutes each time they go though a property line. There should even be a box do check «don't remind me» for familiar places. This is an important issue, as very commonly people don't read long set of rules, especially if they are written into some abscond legal style.

However people may ignore what are for instance «chivalry rules» if they encounter such a rule set. And the full description will need much more than 512 characters. So the idea is to have HTML links to longer and more specific documents, that the user can read if he needs, or ignore if he already knows. For this reason the rules dialogue box is a simplified Internet browser: Rules are written using a small subset of HTML/CSS tags, and hyperlinks. Hyperlinks without target open in the rules dialogue box, and display text with simple presentation, while hyperlinks with a target open in the web browser of the user's computer.

 

Also, most rules are common to nearby all the places, such as no spam, no harassment, no drama, etc. So these rules would appear under the form of a link to a Common Behaviour Rules Set, the Metaverse equivalent of the Netiquette, an universal document than only newbies will have to read. This Common Behaviour Rules Set will have three parts:

-Be nice with other users.

-Do not cheat in roleplay.

-Respect the theme of the world.

In most of the case, linking to this document saves repeating basic common rules (no attacks, no nudity, no spam, etc.), and left as only need some words to define the theme of the world, list the species, set clothing, etc. This theme may need to link to a more specific document, such as «chivalry rules», or in more complex cases, to a full Internet page describing the storyline or purpose of the place. Some places may also state exceptions to the Common Behaviour Rules Set, for instance to allow nudity, or in capture roleplay places where attacking somebody is allowed (Of course the potential victim must be warned of what can happen).

The Common Behaviour Rules Set is not mandatory, but it is a very convenient tool. Trying to create a competing document will go against the purpose of simplicity, and muddle the mind of the user about which rules set actually applies to the place. So the standard IS that there is only ONE document. If people disagree on some points, the normal way is to add other rules or exceptions in their own places, at a pinch to ignore this document, but never attempt to muddle with other place's rules.

Kovenant.rule.placeRules="text"; can also have for main function to simply welcome people in a place, give some news or mood, etc. while the rules are only at the bottom, or even absent.

The WEM browser should have a menu or button reminding of the rules or laws used in the place, and some basic visible displays telling the most common flags (combat, children, sex, nudity, building...) For instance the nudity icon is a pink human shape with black clothes indicating the body parts to cover.

 

 

By default, International Laws apply in the Metaverse, as it is non-local. This also entails the basic documents such as the Human Rights Declaration, children rights, etc. Only a contract with a platform, Character Hosting Company or web hosting is in the laws of their country.

However the flag:

Kovenant.legal.law="countryName" can set the laws of a given country or Union into a place. This should however be used carefully, as international visitors will generally ignore the peculiar or exotic laws that most country are rigged with. So any visitor will have to get a warning that a local law system is used. At need the WEM management may maintain a list of countries which visit may arise issues of bizare, unfair or anti-human rights laws. Countries which openly violate Human Rights may be forbidden to use this flag.

At last the ~physical.nationality of the user must not be displayed without the consent of the user in a place with physical.laws. A place with physical.laws may restrict its access to only users of the same nationality, but not make a selection of allowed nationalities and forbidden nationalities: the purpose of the WEM system is not to import physical conflicts into the Metaverse, and so a test against a nationality list shall not be implemented. Character Hosting Companies trying to implement such tests will be banned of the Register. Same rules also apply to physical religion, race, etc. These delicate issues are dealt with into the next chapter.

 

 

13.8 - The Character Hosting Company check

All along these definitions, Character Hosting Companies are entrusted with a high confidence role, see a legal role. However nothing guaranties that actual Character Hosting Companies will all deserve such a confidence. And world owners may want to deny users from bad Character Hosting Companies. The Character Hosting Company can be identified, as it needs to sends its name (URL or IP) in the resource field of its Kmetaconn messages. However URLs or IPs can more of less be hidden or tampered.

 

As explained in the technical and legal functioning of the WEM, the Character Hosting companies have a Register, which records their addresses. This Register is primarily intended to trace a game cheater or a multiple account abuser with world wide requests, while not exposing the user's personal data. But the Register also records the Character Hosting Companie's level of reliability and user's protection.

The worlds which take care of their users can check the Register for allowed addresses each time they get an entry request from a new visitor, and block the request if an unregistered or blacklisted address appears. It is better if this is done on a separate link to the Register, and not with the Kmetaconn request. Worlds would use a service similar to SpamHaus.

The degree of confidence may allow for some gradation into the response: warning the user, considering him as unchecked, rejecting him, together with a warning explaining the situation, and advising to move to a better Character Hosting Company. As basically it is a right of world owners to refuse unknown or unchecked visitors. The idea is very odd of accepting unknown persons, let them commit crimes and after allow them flee anonymously.

 

On the contrary, users victims of criminal threats or government abuses, citizens of dictatorship, or considered as «enemies» in a war, may get a protected Metaverse political refugee statute. In this case, they may be allowed to fake their Character Hosting Company name (for a good one), and other data such as their physical identity and nationality, in the same way as endangered persons are hidden and protected by their government.

This also applies to recognized good users who cannot access a correct Character Hosting Company, and thus would get a bad checking level.

This feature can work with re-routing the user's connexion through the Register, to a reliable Character Hosting Company, which is then allowed to send camouflage data, to the world or to the bad Character Hosting Company. It is noted that these cautions are taken in such a way that the Metaverse Refugee statute does not appear to the world, and, ideally, does not go through the bad country of bad Character Hosting Company.

Such decisions should be taken legally. However experience shows that, when new stakes appear, legal or democratic powers often react too slowly and in inappropriate ways, as seen with the copyright piracy issue. So the WEM management could be more efficient, as soon as it is led by psychologically balanced persons able to take rational and humanly sound decisions accounting with all the aspects of a situation.

 

Next page: Kailye characters table