Dernière mise à jour: 14 Septembre 2009
Cette page décrit le fonctionnement du WEM (World Entry Management), c'est à dire l'ensemble du système qui va permettre à un utilisateur de se connecter à un monde virtuel de son choix, puis de se téléporter dans n'importe quel autre monde, en conservant son identité, son apparence virtuelle, ses objets, et tout ce qui est nécessaire à sa vie virtuelle.
Le WEM comprend donc un ensemble de normes et dispositifs techniques, mais il assure aussi des protections intrinsèques contre les classiques abus de l'Internet et des mondes virtuels: vols de copyright, harcèlements, problèmes d'identité, spam, etc.
Et il accomplit ceci d'une manière non-duelle avec la préservation de la liberté d'expression et le respect des personnes.
Beaucoup de choix techniques étant dictés par ces considérations humaines voire juridique, cette description mêle technique, usage, discipline et lois, partie par partie. Le plan retenu ici reprend plutôt le déroulement d'une connexion, certaines parties posant davantage de problèmes étant plus développées.
Le WEM est à la fois un protocole de connexion, un système de contrôle, une philosophie, un ensemble de logiciels (navigateur, connecteurs...) et un ensemble d'organisations (Sociés d'Hébergement de Personnages, mondes et plateformes, Direction du WEM...)
Sur cette page:
Définition du protocole WEM
Architecture du navigateur WEM
La connexion de gestion des Autorisations
Les problèmes de sécurité
Développement sécurisé de l'ensemble des logiciels
La Société d'Hébergement de Personnages
Le Registre des Sociétés d'Hébergement de Personnages
Fonctionnement du WEM
En entrant dans le monde
En se déplaçant dans le monde
La gestion des propriété et copyrihts
La communication interopérable entre simulateurs: le langage Kailyé
Le rendu 3D
La communication rapide avec le protocole NRMP
Page proche:
Charte morale des Sociétés d'hébergement de Personnage
et des gestionnaires du WEM
Page proche:
Statut de la propriété intellectuelle de l'architecture WEM,
ses éléments et futures versions
Rencontrons-nous en vrai! Mon nom: Richard Trigaux. Nom d'artiste: Yichard Muni
Tous les vendredis à 12pm SLT (Heure de Californie, PT ou PDT) (France: 21h), rencontres elfiques et histoires
Dans notre region virtuelle Lysaer (Comment entrer)
Dans notre region virtuelle Daur Anarie dans Alternate Metaverse! (Comment entrer)
Elf Dream a son site, il est actif dans dans les mondes virtuels Sovaria, Alternate Metaverse, et présent dans Blue Sky Web, Discord, Facebook. Mewe, Second Life,
L'idée à la base du WEM est d'utiliser l'internet tel qu'il est, sans avoir à modifier les réseaux ni les routeurs. Mais, de par la complexité des échanges 3D avec un monde virtuel, il vaut bien mieux partager la charge entre plusieurs connexions spécialisées différentes, chacune avec sa propre tâche et le protocole qui lui convient, tel que http, mail, stream, etc. Ainsi le WEM est plutôt une couche supérieure sur l'internet existant, prenant en charge comme une entité unique un ensemble de connexions différentes. Cette entité unique est appelée une metaconnexion WEM.
En résumé le moteur WEM (WEM engine) est un module logiciel au coeur du navigateur 3D, dont la fonction est de démarrer ou arrêter tous les appareils (devices) du navigateur ainsi que les connexions. Il demande au monde virtuel quelles sont les connexions nécessaires, entretient une liste des connexions ouvertes appelée le registre des connexions WEM (WEM Connexions Register), et gère en conséquences le trajet des données dans l'ordinateur, de manière à ce que touts les appareils du navigateur puissent communiquer avec les bonnes adresses dans le monde virtuel ou dans Internet.
Le WEM est prévu pour être un protocole libre disponible pour tous, tout comme l'ont été les protocoles internet tels que le http. Il en est ainsi pour obtenir similairement un système entièrement interopérable sans monopole ni blocage. Par contre, il est très probable que de nombreux simulateurs 3D différents apparaîtront. Mais tous pourront fonctionner avec un navigateurs standard, pourvu qu'ils utilisent le même protocole.
Pour cette raison ce texte lui-même est protégé par une licence GNU GDL. C'est aussi une proposition pour le W3C, qui est l'autorité reconnue pour l'évolution de l'Internet, en le maintenant normalisé.
Les raisons qui ont motivé l'architecture décrite ici sont l'interopérabilité, la sécurité, la facilité de maintenance et d'évolution. Mais il y a une autre raison: quelques sociétés infantiles pourraient engager une guerre des protocoles, et lancer leur propre WEM2 incompatible avec le WEM décrit ici. Si cela devait arriver, les implémentations libres du moteur WEM n'ont qu'à ajouter immédiatement le système WEM2, afin de rester compatibles avec tous les mondes. Ainsi il n'y a pas d'intérêt à lancer une guerre des protocoles, car personne n'ira utiliser un navigateur WEM2 qui ne donne accès qu'à certains mondes, alors qu'un navigateur WEM donne accès à tous. Toutefois le gagnant le plus probable d'une guerre des protocoles sera celui qui offrira les mondes les plus variés et de meilleure qualité, avec correctement mis en oeuvre tous les outils et conditions nécessaires à une bonne vie virtuelle.
On pourrait se demander pourquoi ne pas utiliser le protocole de Second Life, qui est open source. Il y a plusieurs raisons à cela, notamment qu'il est déjà utilisé à des fins malhonnêtes dans des navigateurs trafiqués. Pour la même raison il serait nécessaire de modifier de temps à autres le fonctionnement du WEM, et le protocole de Second Life tombe déjà sous cette nécessité. Mais rien n'empêche que le moteur WEM puisse aussi s'adjoindre des modules émulant des protocoles particuliers nécessaires à tel ou tel monde. Ainsi le moteur WEM deviendrait virtuellement universel, même dans un Internet 3D qui ne le serait pas.
Le navigateur est construit autour d'un module de logiciel appelé le moteur WEM (WEM engine), autour duquel tournent différents autres modules appelés appareils (devices), tel que le rendu 3D, le système de dialogue (chat), le gestionnaire des menus, le système de navigation, etc. Tous ces éléments sont des fichiers exécutables indépendants, qui peuvent être de sources différentes. De nouveaux types d'appareils peuvent être ajoutés à volonté, dans le futur, par exemple des synthétiseurs d'odeurs, simplement en ajoutant un fichier dans le répertoire des appareils.
Quand on démarre le navigateur, on démarre en fait le moteur WEM, qui a son tour va démarrer tous les modules qu'il trouvera dans le répertoire des appareils.
Une fois lancés et connectés, les appareils tournent indépendamment du moteur WEM, et exécutent leur tâche jusqu'à ce qu'une modification à leurs connexions soit demandée. Ceci permet une évolution séparée des appareils, et aussi une variété de fournisseurs pour chacun d'eux.
Dans le moteur WEM, la logique qui démarre ou stoppe chaque appareil reçoit des commandes à la fois de l'utilisateur, du monde, ou du moteur WEM proprement dit. Par exemple le rendu 3D est démarré automatiquement par le moteur WEM, le système de dialogue est lancé sur demande de l'utilisateur, un objet dans le monde envoie une requête pour un don, le système de streaming audio est fermé quand le personnage entre dans une zone sans audio, etc.
Le moteur WEM gère toutes les connexions entre les appareils du navigateur et les différents services dans le monde ou sur Internet. Il démarre les connexions automatiquement, ou reçoit des requêtes de connexion d'appareils dans le navigateur ou dans le monde.
Chaque connexion a un protocole, et chaque protocole est implanté dans un appareil de communication appelé une prise (plug), dont de nombreuses instances peuvent fonctionner simultanément.
Quand il démarre, le moteur WEM établit les routes entre les prises et les appareils, dans la mémoire et les bus de l'ordinateur. On notera ici que le moteur WEM est la seule partie du navigateur qui a besoin d'une adaptation aux nombreuses configurations possibles des ordinateurs (coeurs multiples, cartes graphiques...). Aussi l'installation du logiciel du navigateur devra adapter automatiquement le moteur WEM à la configuration de l'ordinateur, installant les appareils et les prises aux bons endroits et déterminant les meilleurs canaux de transfert d'information.
Par contre les appareils et les prises tournent chacun sur un coeur unique et sa mémoire locale. Ceci fait qu'ils n'ont besoin d'aucune adaptation à un ordinateur donné, et ces éléments peuvent être conçus à l'aide d'outils simples et sont facilement portables, sans les complexités de la programmation multi-coeurs (parce que cette complexité est gérée par le moteur WEM).
Pour faciliter les modifications et adaptations, les appareils et les prises doivent être des fichiers exécutables indépendants, rangés dans des répertoires spécifiques. Quand le moteur WEM démarre, il les charge dans des mémoires appropriées, et établit les canaux de transfert d'information. Le moteur WEM lui-même est un fichier exécutable, celui qui est lancé quand on démarre le navigateur. Ceci permet d'améliorer très facilement le navigateur, simplement en ajoutant de nouveaux fichiers téléchargés automatiquement. Il n'y a pas besoin d'une réécriture globale ni de tests complets du navigateur à chaque modification mineure. Ceci facilite aussi les modifications particulières des appareils. Le moteur WEM doit inclure des APIs pour tous les langages populaires, afin de pouvoir créer facilement de nouveaux appareils reconnus par le moteur WEM. Au démarrage, le moteur WEM tentera automatiquement d'ajouter à sa liste d'appareils, ou à sa liste des prises, tous les fichiers présents dans les répertoires appropriés, et ignorera ceux qu'il ne peut reconnaître. Ceci est simple à mettre en oeuvre, même par des personnes sans grande formation informatique.
Un monde pourrait demander d'ajouter des appareils au navigateur. Ceci peut se faire par téléchargement automatique suivi de notification au moteur WEM. Toutefois une telle pratique pose des problèmes de qualité et de sécurité, et ne devrait pas être autorisée sans aucun contrôle.
Quand il démarre, le moteur WEM commence par établir une connexion avec la Société d'hébergement de personnage de l'utilisateur, où sont notées ses autorisations. Il se connecte ensuite vers le serveur hébergeant le monde. Cette première connexion est triangulaire, c'est la Connexion de Gestion des Autorisations (Authorization Management Connexion). C'est ici que l'on s'occupe de toutes les autorisations et problèmes de sécurité de l'utilisateur dans le monde, aussi bien entendu elle utilise un protocole strictement sécurisé.
Sa fonction principale est de comparer les autorisations de l'utilisateur et les conditions d'entrée du monde (par exemple les catégories d'âge et le contenu sexuel, banissement disciplinaire d'un monde, etc.). Cette comparaison résultera en l'acceptation de l'entrée, le refus de l'entrée, ou des actions telles que l'ajout automatique de vêtements ou des messages d'avertissement.
Les droits d'entrée sont donc vérifiés entre le monde et la Société d'hébergement de Personnage, parce qu'un navigateur peut toujours être trafiqué avec de fausses autorisations. Mais c'est le navigateur qui initie la requête et qui reçoit l'agrément ou le refus (avec le motif). De là le lien triangulaire.
La Connexion de Gestion des Autorisations devra être toujours ouverte, car il faudra re-vérifier les droits à chaque téléportation. On peut donc dire que la métaconnexion WEM est présente ou pas, selon que la Connexion de Gestion des autorisations est présente ou pas. On peut donc utiliser aussi la Connexion de Gestion des Autorisations pour envoyer tous les messages de service ordinaires, demandes de connexion et négociations. La Connexion de Gestion des Autorisations est la connexion de commande.
Le «griefing» et autres abus utilisant l'anonymat ou des navigateurs trafiqués sont le principal problème sur Second Life, et la principale limitation à la jouissance des mondes virtuels. Aussi on doit dès le départ s'engager dans une politique sécuritaire forte et des méthodes sans failles.
La sécurité exige qu'aucune connexion sauvage puisse exister entre un appareil du navigateur et le monde. De telles connexions sauvages peuvent être utilisées pour du spam dont l'envoyeur ne peut être identifié. Aussi le moteur WEM d'un monde ne doit accepter que des connexions demandées ou acceptées par le moteur WEM du navigateur, que l'on peut attribuer à un personnage, et qui sont approuvées par la Société d'Hébergement de Personnage. Ainsi toutes les connexions doivent être triangulaires. Même la connexion vers la banque d'un appareil de gestion d'argent devra être connue du système WEM et de la Société d'Hébergement de Personnage.
Des connexions directes peuvent exister entre des utilisateurs (chat, messages, échange d'objets ou de documents). Dans Second Life les entreprises ont constamment demandé à ce que leurs communications soient derrière un pare-feu, de manière à ce que les autres utilisateurs ou le propriétaire du monde puissent les espionner. (Cette demande n'a jamais été satisfaite, ce qui explique l'absence des entreprises et des administrations dans Second Life). Des connexions directes entre utilisateurs offrent bien plus de sécurité, car elles ne passent pas par le monde. Mais leur existence doit être connue du système WEM (pour éviter, par exemple, du spam non-identifiable). Les systèmes de téléconférence déjà utilisés par les sociétés n'ont qu'a apparaître comme des appareils dans le monde, qui établiront et gèreront de telles connexions directes sécurisées entre utilisateurs, par le biais des moteurs WEM de chacun d'eux.
Ces spécifications font que le moteur WEM ne doit PAS être open source. Il ne doit être modifié que par une petite équipe contrôlée de professionnels et conseillers. Les créateurs de mondes n'ont de toutes façons pas besoin de le modifier, car ce n'est qu'un système de communication, transparent pour l'utilisateur, et nullement impliqué dans la conception des mondes proprement dits. Mais bien entendu pleine liberté doit rester aux concepteurs de mondes d'ajouter des appareils légitimes dans leurs créations, afin d'enrichir les simulations et leurs possibilités.
Un appareil spécial gèrera l'argent des utilisateurs. La banque de l'utilisateur peut fournir le sien. Ceci permettra l'utilisation de l'argent réel directement dans le monde, au lieu de nécessiter une monnaie virtuelle. Mais cela ne doit pas interdire les monnaies virtuelles.
En résumé, les mondes ont plus de droits que les utilisateurs, et les Sociétés d'hébergement de Personnages arbitrent automatiquement entre les deux de manière neutre. Si un désaccord persiste, l'affaire doit être portée devant des juges humains. Les propriétaires de mondes ont toutefois pleins pouvoirs sur leurs créations, à travers leur navigateur. Ils doivent aussi pouvoir ajouter des connections entre les appareils de leurs mondes et divers services internet. Des abus par des propriétaires de mondes résulteront le plus souvent en la fuite des utilisateurs, qui recréeront leur projet ailleurs. Mais les abus sévères pourraient être poursuivis en justice. Dans ce cas seule la Société d'hébergement de Personnage pourra apporter les preuves nécessaires.
Les Animations (séries d'actions ou mouvements prédéfinis) peuvent être des fichiers lus par un appareil du navigateur, ou sélectionné dans le monde.
(Cet alinéa a été révisé le 10 Sept 2009) L'automation (décisions intelligentes prises par un logiciel, sans contrôle immédiat par un utilisateur humain) fait du personnage ce que l'on appelle habituellement un bot (robot). Les robots sont des éléments nécessaires et très intéressants du métaverse, mais ils peuvent être utilisé pour toutes sortes d'abus, le plus souvent en les faisant passer pour des utilisateurs humains. On peut concevoir des triches plus subtiles, comme d'ajouter des super réflexes à un joueur humain. D'où le besoin d'un certain contrôle. Le plus commun est que le navigateur (le moteur WEM) envoie une étiquette de robot, pour dire au monde que le personnage est un robot. Pour qu'un logiciel extérieur puisse prendre contrôle d'un ou plusieurs appareils, ces appareils doivent avoir des APIs pour tous les langages courants. Ainsi, quand un appareil reçoit des commandes sur son API, il envoie automatiquement l'étiquette robot au moteur WEM, qui l'envoie au monde, et la maintient jusqu'à ce que la métaconnexion WEM soit fermée. Ainsi les triches deviennent traçables. Mais cela ne peut fonctionner que si il n'existe pas de versions trafiquées du navigateur WEP.
(Cette partie a été séparée de la précédente le 10 Septembre 2009, relue et amenée à une conclusion plus claire.)
Beaucoup demanderont à ce que les appareils soient open source, pour pouvoir offrir un choix d'implantations et de modifications à la demande, appareil par appareil (un appareil par fonction, tel que rendu 3D, chat, etc.). Toutefois une telle ouverture peut être une source de problèmes sévères, avec des appareils bugués ou trafiqués. Des versions piratées du navigateur de Second Life ont permis de nombreux abus, allant jusqu'à des outils sophistiqués pour du harcèlement ou du vol de copyright. Il y a donc de forts arguments de sécurité pour ne pas divulguer les algorithmes des appareils, ni les APIs du moteur WEM.
Ceci est aussi vrai pour les prises, sauf qu'on n'a pas besoin de les modifier une fois qu'on en a qui marchent bien. De toutes façons elles sont sous contrôle qualité et sécurité.
Un point intéressant serait que les appareils aient des étiquettes d'identification d'appareil WEM codées. Le moteur WEM pourrait alors envoyer des rapports à la Société d'hébergement de Personnages, sur les appareils utilisés par un navigateur. Ces informations privées seraient bien utiles en cas de procès pour des problèmes de comportement faisant soupçonner l'usage d'appareils trafiqués ou falsifiés. En plus le système WEM pourrait recevoir des alertes de sécurité et bloquer des appareils avec une étiquette donnée.
Une autre façon d'éviter les appareils trafiqués est que les interfaces (API) du moteur WEM soient tenues secrètes, et changées si des problèmes arrivent, forçant le rechargement de tout le logiciel du navigateur.
Il peut exister plusieurs implantations du moteur WEM lui-même, mais toutes sous contrôle sécuritaire strict. Des séries de tests publics peuvent être fournies aux utilisateurs, pour qu'ils voient comment leurs appareils et moteur WEM fonctionnent, dans l'esprit des séries de test Acid.
De toutes façons, on peut répéter que ni les créateurs de mondes, ni les utilisateurs n'ont besoin de modifier le navigateur, une fois qu'il fonctionne correctement. Il est infiniment plus facile de s'adapter à un (bon) navigateur, que de gérer l'enfer d'une kyrielle de versions de navigateurs. Plus jamais la guerre des navigateurs HTML! (L'anarchie actuelle (2009) n'est pas meilleure, où l'on doit s'adapter à une nouvelle version tous les trois mois!)
Il vaudrait bien mieux, pour la sécurité, et ce serait un modèle économique bien plus rationnel, que toutes les sociétés impliquées dans l'hébergement ou la construction des mondes virtuels, financent ensemble une entité unique, développant un navigateur unique mais aussi bon que possible (moteur WEM et appareils). De cette façon, les données confidentielles ont bien moins de chances de s'échapper, que si elles sont présentes dans une grande quantité de sociétés concurrentes et ateliers. Toutefois cela implique que les gestionnaires de cette entité soient psychologiquement capables d'accepter les requêtes et critiques des utilisateurs, afin d'améliorer ce navigateur, ou d'ajouter des options, sans tout bouleverser inutilement à chaque nouvelle version. Si ils ne sont pas psychologiquement capables, alors effectivement il vaut mieux qu'ils soient en compétition entre eux, sous pression effective des utilisateurs.
Aussi la solution proposée ici est un site internet où des sociétés, ou même des individus, souhaitant développer ou modifier des appareils, pourraient utiliser des compilateurs capable de créer des fichiers d'appareils, fonctionnant avec les APIs du moteur WEM, sans divulguer ces APIs à ces personnes ni à des sociétés. Ces APIs apparaissent comme des fonctions que le programmeur peut utiliser, mais pas éditer. Les fichiers d'appareils compilés sont enfin récupérés par la personne, ou bien distribués grâce au système de mises à jour automatiques du navigateur WEM. En cas de mise à jour de sécurité des APIs, le fichier est automatiquement recompilé, et tous les utilisateurs qui l'ont reçoivent automatiquement la nouvelle version.
Ce système permettrait un taux d'open source des appareils, car toute caractéristique abusive est alors traçable: les fichiers compilés reçoivent des étiquettes d'identification d'appareils WEM, pour les contrôles de sécurité. Mais ces étiquettes peuvent aussi être utilisées pour des statistiques, et mesurer le succès d'une version donnée d'un appareil. Ainsi on aurait plus d'innovation et un taux raisonné de compétition, même avec une structure unique et centralisée, tout en ne compromettant pas la sécurité.
Par contre, les créateurs de mondes doivent pouvoir créer librement des logiciels et scripts dont ils ont besoin pour faire fonctionner ces mondes. Afin de rester dans une démarche sécurisée, ces logiciels communiqueront avec le moteur WEM du monde, uniquement à travers un connecteur. Un connecteur est un appareil WEM standard, dédié à la communication des divers scripts et logiciels qu'un développeur de monde voudra inventer, en plus des autres appareils fournis en standard avec le WEM. Il utilise les APIs secrètes du moteur WEM, mais il offre aussi des APIs publiques pour les logiciels et scripts dans le monde. Quand un tel logiciel veut interagir avec un utilisateur, alors le connecteur établit une connexion triangulaire entre lui, l'utilisateur et sa Société d'Hébergement de Personnages. Il envoie à cette dernière l'information privée sur l'identité du propriétaire du monde, ou au moins l'URL du monde. Ainsi, en cas d'abus, on peut trouver qui l'a commis, ou sinon bloquer automatiquement des connexions, voire des mondes qui ne fourniraient pas ces informations.
Le moteur WEM pourrait aussi communiquer avec un anti-virus ou d'autres logiciels de sécurité, principalement pour détecter des appareils trafiqués susceptibles d'être utilisés pour des abus, du spam, etc. La raison est qu'il serait relativement facile de créer des appareils trafiqués, et de les installer ou faire installer par des utilisateurs à leur insu. Mais pour déjouer un tel système de contrôle des appareils, un délinquant aurait besoin de créer son propre moteur WEM, une tâche bien plus difficile (multi-coeurs, protocoles secrets, échanges codés, mises à jour de sécurité fréquentes, etc.)
La toute première chose que fait un navigateur 3D quand il démarre est se se connecter à la Société d'Hébergement de Personnage, qui est l'équivalent 3D du fournisseur d'accès à l'internet 2D. Rappelons ici que un utilisateur (Une personne physique) a un abonnement à une Société d'Hébergement de Personnage, mais qu'il peut avoir plusieurs personnages. Nous parlons ici d'une connexion d'une personne physique vers un seul personnage. Les personnages doivent avoir une identité fédérée virtuelle (virtual federated identity), aussitôt qu'elles seront disponibles et fonctionnant correctement. A défaut; le WEM devra proposer une identité unique pour tous les mondes.
Les serveurs de la Société d'Hébergement de Personnage stockent tous les éléments du personnage: le profil, l'inventaire des objets, les formes corporelles, vêtements et objets portables, textes, images, sons, etc. On note que ces éléments sont eux-mêmes des objets 3D, de telle sorte que l'utilisateur peut les stocker dans une scène virtuelle personnelle offerte avec l'abonnement à la Société d'hébergement de Personnages. Une telle scène peut être un lieu de vie personnel, mais elle peut aussi contenir un stockage en 3D montrant sur des étagères tout les objets de l'utilisateur. Chacun choisira d'avoir ces éléments sur son ordinateur local, sur le serveur de la Société d'hébergement de personnage, sur un serveur d'entreprise, ou encore dans un lieu sécurisé quelque part sur Internet. Les fonctions d'inclusion du langage 3D permettront aussi d'avoir cette scène personnelle, sur un serveur donné, incluse dans un monde plus grand sur un autre serveur.
Toutefois la principale fonction WEM de la Société d'hébergement de Personnage est de gèrer les autorisations, droits d'accès et mesures disciplinaires en cours pour le personnage. Ceci doit se trouver sur un serveur neutre, sinon il serait bien trop facile de tricher. L'utilisation d'identité fédérée permettra de porter facilement ces autorisations d'une Société d'hébergement de personnage à une autre.
Ceci fait que, quand le navigateur démarre, il doit en tout premier établir la Connexion de Gestion des Autorisations, comme vu ci-dessus. Il a ensuite besoin de connecter des appareils à divers services de la Société d'hébergement de personnage: écran de démarrage, HTML, RSS, chat, streaming audio, etc.
Ajouté le 23 Novembre 2011:
Une façon plus simple et efficace de gérer identités et abus serait d'utiliser les trois niveaux d'identité décrits à 12.5 - The name Kflags values, qui sont ~Physical (légal), ~character (social) et ~roleplay (dans un jeu)
Dans ce système, toute personne a le droit d'avoir une identités légale ~Physical, qui est publique, et qui peut être utilisée à des fins administratives ou publiques. Toutefois, chaque personne peut aussi avoir un nombre illimité d'identités sociales ~character ou de jeu ~roleplay, qui sont pas défaut anonymisées: la connexion avec l'identité légale ~Physical est gouvernée par les lois sur la vie privée. Toutefois, toutes les informations sur les drois d'accès, bannissements, etc. serait rassemblée par la Société d'Hébergement de Personnages, sous la seule identité légale ~Physical.
Ainsi, quand la personne tente d'entrer dans un lieu social, ou un jeu, sous une de ses identités ~character (sociale) ou ~roleplay (de jeu), alors le WEM vérifie cette identité auprès de la Société d'Hebergement de Personnages. Cette dernière vérifie qu'il n'y a pas de bannissement ni d'accès dupliqué, grâce à l'identité ~Physical (légale), et répond «oui» ou «non» au lieu social ou au jeu, sans divulguer l'information sur l'identité ~Physical.
Ce système évite qu'une personne bannie puisse re-entrer sous une autre identité, ou qu'un tricheur puisse avoir plusieurs personnages dans un jeu, sans divulguer l'identité ~Physical au gestionnaire du monde. Toutefois cette identité ~Physical peut toujours être trouvée par une action légale.
Certains diront qu'un tel système est excessivement légaliste ou moraliste. Afin de tenir compte de ce souci, on peut toujours avoir des identités ~character (sociales) ou ~roleplay (de jeu), non connectées à une identité ~Physical physique. C'est alors au gestionnaire du monde de d'accepter ou non ces identités, et ultimement à l'utilisateur de ces mondes d'accepter d'entrer dans un monde où il peut rencontrer de telles identités. Si oui, il peut être exposé à divers abus sans protection légale. L'expérience montre que beaucoup de gens préfèrent cette solution, plutôt que d'être constamment encadrés. D'autres préfèrent être encadrés, plutôt que constamment abusés.
Comme il y en aura plusieurs Sociétés d'Hébergement de personnage, elles devront communiquer entre elles et échanger des informations, afin de pouvoir s'assurer de l'unicité de chaque utilisateur, ou de ses mesures disciplinaires, tout en protégeant ses informations privées.
Mais rien ne peut garantir que toutes les Sociétés d'Hébergement de Personnage soient aussi neutres et fiables que nécessaire. On pense à des pirates créant une fausse Sociétés d'Hébergement de Personnage, et l'utilisant pour héberger des griefers ou des délinquants, attaquer d'autres utilisateurs ou le système WEM. Mais les menaces les moins visibles sont les plus dangereuses: des gouvernements, sectes, sociétés, partis politiques et autres organisations secrètes pourraient créer ou acheter une grande Société d'Hébergement de Personnage de bonne réputation, et contrôler discrètement leurs membres, ou, encore plus subtil, n'utiliser qu'un très petit nombre de comptes pour des activités délinquantes. Ajoutons enfin qu'il peut y avoir des centaines de Sociétés d'Hébergement de Personnage, cachant leurs bases de données dans toutes sortes de pays avec des lois différentes...
La question n'est pas simple, et elle implique des problématiques redoutables. Il n'y a pas de solution magique ni de méthode facile capable d'effacer tous ces risques d'un seul coup. En plus, l'ensemble du problème prend la forme logique d'une non-dualité Yin/Yang entre sécurité et liberté, ce qui fait que toute forme de pensée unique ou d'idéologie ne peut qu'empirer les choses sans apporter la moindre satisfaction.
Aussi la proposition faite ici est un ensemble de deux outils:
Le Registre des Sociétés d'Hébergement de Personnage, qui est un annuaire de toutes les Sociétés d'Hébergement de Personnage, qui détient les enregistrements de leur niveau de fiabilité et de neutralité. Toute recherche sur un utilisateur commencera obligatoirement ici.
Comme chaque Société d'Hébergement de Personnage garde les enregistrements des données privées indiquées par chacun de ses utilisateurs, il devient possible de trouver automatiquement des choses telles que deux comptes qui sont au même numéro de passeport. Une telle requête envoyée par un jeu pourrait se propager dans le monde entier et trouver un tricheur en quelques minutes. Dans le sens inverse, quand un griefer est banni d'une Société d'Hébergement de Personnage, cette information sera passée à toutes les autres en moins de temps qu'il ne lui en faudra pour créer un nouveau compte. Toutefois cela fait du Registre un outil très puissant, et donc dangereux si il tombe entre de mauvaises mains, en particulier des mains de dictateurs. Il pourrait être utilisé, par exemple pour traquer des réfugiés dans d'autres pays, ou pour s'en prendre systématiquement à des catégories d'utilisateurs. D'où un certain nombre de précautions:
-ne pas exposer les données privées dans les requêtes, ni dans les réponses. Ces requêtes servent uniquement à vérifier l'unicité d'un utilisateur, ou ses mesures disciplinaires.
-Il n'y a pas de base de donnée centralisée de l'ensemble des utilisateurs du WEM. Il n'y a même pas d'index unique ni d'ID des utilisateurs. Il faut plutôt voir chaque Société d'Hébergement de Personnage comme une cellule d'un tissus, où chaque cellule est autonome et a son propre ensemble de donnée. Les bonnes cellules communiquent librement ensemble, mais elles se méfient des mauvaises. Ainsi la Direction Technique du WEM peut restreindre les canaux vers les cellules peu fiables. Bien entendu ces restrictions sont indiquées dans le Registre.
-Afin de préserver une pluralité d'opinions, chaque Société d'Hébergement de Personnage peut ajouter au besoin ses propres restrictions.
-En dernier ressort, chaque propriétaire de monde garde la liberté de décider en qui il fait confiance ou non, en bloquant spécifiquement certaines Sociétés d'Hébergement de personnage.
-Les utilisateurs venant de Société d'Hebergement de Personnage peu fiables ont leur niveau de vérification abaissé. Toutefois les victimes de dictatures ou d'autres abus gouvernementaux pourront disposer d'un statut spécial, leur fournissant un bon niveau d'identification sans exposer leur vie privée ou adresse actuelle.
Mais cela est encore très imparfait, car une Société d'Hébergement de Personnage pervertie pourrait toujours répandre de fausses informations disciplinaires, afin de s'en prendre à une personne ou à une catégorie de personne. Ceci, et d'autres triches, ne pourra jamais être contrôlé automatiquement. Aussi le second outil est:
La Direction Technique du WEM, qui est supervisée par le Conseil International de Supervision des Mondes Virtuels. Le premier a pour fonction d'assurer un fonctionnement harmonieux du Registre et d'autres systèmes WEM, face à des problèmes de routine tels que des pannes, des tentatives pour le détruire ou en prendre le contrôle, etc. Le second a pour fonction d'anticiper les nouveaux problèmes de droit de l'homme, ou de prendre des décisions extraordinaires pour les «situations qui ne doivent pas arriver», c'est à dire les tentatives par un gouvernement ou un pouvoir légal d'abuser le système.
Quand il commence à se connecter, le moteur WEM doit produire une liste des connexions nécessaires (Il peut en proposer, et la Société d'hébergement de personnage peut en proposer d'autres).
Cette liste est dans une petite base de donnée, le Registre des connexions WEM (WEM Connexions Register), contenant, pour chaque connexion:
-son nom
-sa fonction
-l'appareil qui la demande
-le protocole (http, stream, RSS, mail...)
-les emplacement mémoire de l'appareil et de la prise
-l'adresse de destination (URL ou identification d'appareil dans le monde).
-drapeaux de service (active, inactive, fermée mais disponibles pour d'autres usages sans avoir à la re-charger depuis le disque)
-drapeaux d'erreur, que les appareils concernés peuvent montrer à l'utilisateur.
Tout cela doit être lisible pour un humain, pour faciliter la sortie papier et le dépannage.
La principale fonction du moteur WEM est de tenir à jour le Registre des Connexions WEM, en ajoutant de nouvelles connexions dans la liste, en fermant d'autres, selon les besoins ou les requêtes de connexion ou de fermeture.
Ensuite le moteur WEM actualise le Registre des Connexions WEM. Ceci signifie qu'il placera ou retirera des instances de prises ou d'appareils dans la mémoire, avec leurs canaux d'information.
Enfin les appareils et les prises commencent à tourner indépendamment, se connectant à l'adresse indiquée et gérant cette connexion.
Le moteur WEM est maintenant inactif, mais prêt à accepter de nouvelles requêtes de connexion, ou surveillant les connexions mortes pour les fermer.
Après s'être connecté avec la Société d'hébergement de Personnage, l'utilisateur choisit dans quel monde il veut aller.
Rappelons ici que les mondes, et tous les objets qu'ils contiennent, doivent être identifiés par le même système d'Unified Resource Locator (URL) déjà utilisé pour l'Internet 2D. Juste certains champs ont une signification différente, par exemple le «path» correspond à la structure hiérarchique du contenu du monde (grouping nodes du VRML). Ceci est aussi vrai pour toutes les ressources secondaires utilisées, telles que l'inventaire, le stream audio, etc. L'URL du monde est utilisée pour définir la métaconnexion WEM. Elle peut être utilisée pour établir la Connexion de Gestion des Autorisations, dont l'adresse commencera par «wem://». Le contenu 3D peut aussi utiliser la même URL, car ce sera un protocole différent, non sécurisé, commençant par «http://». D'autres connexions à des appareils dans ce monde utilisent le même système d'URL, mais avec un chemin et nom de fichier identifiant l'appareil qu'elles doivent joindre. D'autres connexions, comme par exemple le streaming audio, utiliseront leur propre URL en d'autres lieux de l'Internet.
Egalement on doit être capable de combiner des éléments 3D de différentes sources dans le monde, par un usage rationnel des origines et échelles de coordonnées. C'est le cas de la forme corporelle, hébergée par la Société d'hébergement de Personnage, loin du monde lui-même.
La connexion à un monde se fait à l'aide de la Connexion de Gestion des Autorisations. Quand le droit d'entrée est reconnu, le serveur du monde doit envoyer au navigateur la liste des connexions qu'il a besoin d'établir. Cette liste est ajoutée au Registre des Connexions WEM du navigateur, que le moteur WEM du navigateur actualise. Quand ces connexions sont établies, alors les appareils dans le navigateurs tournent normalement et échangent des messages, utilisant principalement http, streaming, IM, email ou autre. Le personnage est maintenant dans le monde!! Et le moteur WEM devient inactif, attendant des requêtes pour des ouvertures ou fermetures de connexions.
De nouveaux appareils rencontrés dans le monde peuvent envoyer des requêtes de connexion.
Les téléportations sont à l'Internet 3D ce que les liens hypertexte sont à l'Internet 2D. Quand une téléportation est demandée, vers un autre monde ou un autre serveur, le moteur WEM du navigateur doit re-vérifier les autorisations pour ce nouvel endroit. Ceci doit être fait AVANT la tentative de téléportation, et en cas de refus l'utilisateur doit en être informé, avec le motif. Seulement quand l'autorisation est reçue, le moteur WEM doit mettre à jour et actualiser le Registre des Connexions WEM, établissant les nouvelles connexions, et fermant celles dont il n'y a plus besoin. Ceci réalise la téléportation.
Activement rechercher les connexions inutiles pourrait être une nécessité, par exemple pour éviter de consacrer de la puissance de calcul à un visiteur qui est parti, ou à un appareil qui s'est arrêté. Ceci arrive aussi, par exemple, quand le personnage s'éloigne d'une source de streaming audio: au delà d'une certaine distance, la connexion au service de streaming doit être fermée, et l'appareil et la prise utilisés à autre chose. Mais aussi, les connexions peuvent être coupées sans préavis par des pannes de l'Internet. Donc une connexion qui ne répond plus pourrait être considérée comme morte, et fermée. Toutefois, dans ce cas, l'utilisateur doit être averti, et un système pourrait essayer d'établir une autre connexion avec une autre route. Des mondes à haute fiabilité pourraient proposer des connexions de secours dès la première connexion, dans le Registre des Connexions.
(Modifié le 11 sept 2009) Egalement, alors que le personnage se déplace dans le monde, il peut traverser sans s'en rendre compte une frontière invisible, où le contenu est hébergé sur un autre serveur loin du premier, sur un autre continent. Cette situation est une source fréquente de problèmes graves dans Second Life. Le WEM résoud ce problème en permettant d'avoir plusieurs connexions simultanées vers différents serveurs, puisque la liste des connexions peut être étendue à volonté, au vol. Alors, grâce à la correspondance entre les path dans les URLs et la hiérarchie géométrique des objets, on peut facilement combiner des objets et paysages de différentes sources dans la même scène. Juste les appareils du navigateur doivent être capables de gérer plusieurs connexions, au besoin avec chacune une instance de la prise. Du côté du simulateur, cette situation est résolue grâce au langage et système d'interconnexion Kailye, qui permet à des simulateurs d'interagir les uns sur les autres et de combiner leurs objets.
Une autre sorte de frontière invisible est entre zones où des autorisations différentes s'appliquent. De telles autorisations peuvent être de nombreux types, comme ne pas utiliser de scripts, ne pas rezzer d'objets, limitations de comportement, pas de combat, pas de nudité, etc. Elles peuvent résulter de conditions variées, telles qu'appartenance de groupe, questions de discipline, étiquette d'âge et de sexe, etc. Les autorisations peuvent aussi concerner des parties du personnage, par exemple entrer dans une zone sans nudité ajoute automatiquement des vêtements, afin éviter des situations embarrassantes.
Ces situations sont la raison pour laquelle la Connexion de Gestion des Autorisations doit être active en permanence. Les vérifications doivent aussi être terminées avant qu'une téléportation commence, ou avant d'entrer dans une nouvelle zone, pour éviter gaffes et incidents, griefing volontaire, ou des bugs tels qu'un personnage tiré en arrière. Ceci demande de l'anticipation: quand le personnage approche une frontière, ou un téléporteur, ou quand il sélectionne un landmark: les autorisations sont vérifiées et traduites en limites géométriques que le personnage ne peut traverser, comme un mur invisible. Aucune transgression ne doit être possible tant que l'autorisation n'est pas reçue.
Certains propriétaires de mondes préfèreront gérer eux mêmes les autorisations, par exemple avoir leur propre liste de groupe, ou leur propre liste de bannissement. De tels systèmes peuvent être abusés ou falsifiés par les propriétaires de mondes. Mais ils peuvent être falsifiées autrement, de toutes façons (par exemple déclarer un lieu sexuel comme ouvert aux enfants, ou bannir arbitrairement des gens qu'ils n'aiment pas), aussi on peut toujours accorder ça aux propriétaires de mondes. Pas plus que pour les utilisateurs, on attend des propriétaires de mondes qu'ils soient des saints. Mais on attend des Sociétés d'Hébergement de Personnages qu'elles soient neutres.
De toutes façons les utilisateurs doivent être informés qu'une téléportation ou une entrée sont refusés, par qui et pourquoi.
Télécharger des objets 3D vers le monde, tels que des textures, ouvre une connexion vers l'ordinateur local.
L'échange d'objets entre utilisateurs peut nécessiter d'ouvrir une connexion temporaire, qui peut être de plusieurs types.
L'expérience de Second Life a démontré qu'il est important de veiller au respect de la propriété, ainsi qu'au respect des différentes licences de copyright, à l'aide d'outils spécifiques interdisant systématiquement les réplications ou transactions illicites. De plus, face à l'ampleur ahurissante du piratage sur l'Internet 2D, il est clair qu'il faut dès le départ prendre des précautions suffisantes pour qu'une telle situation ne se reproduise pas dans l'Internet 3D, où se feront bientôt la majorité des échanges de fichiers artistiques.
(Ajouté le 11 Septembre, 2009) Donc les solutions proposées ici tendront aussi bien à traquer les duplications ou téléchargements illicites, qu'à proposer aux auteurs des preuves légalement opposables de leurs droits. Mais un point très important aussi est que le WEM est pour tout le monde, pas seulement pour les grosses sociétés ou les «majors». Aussi les solutions proposées ici offriront les mêmes outils et protections aux petits artistes ou aux indépendants.
Ce qui suit peut s'appliquer à des objets complets, ou à des éléments tels que des textures et images, des sons, des formes 3D complexes, des textes, des logiciels, etc. Ces éléments doivent être archivés chacun en un endroit sûr et unique (plus les sauvegardes et caches), où les droits de propriété et de copyright seront suivis, élément par élément, objet par objet. Il s'agit d'un Serveur de Copyright. Les objets copyrightés iront se télécharger sur le Serveur de Copyright, et nulle part ailleurs. Ainsi tous les éléments protégés sont disponibles à cet endroit, que ce soit gratuitement, sur abonnement ou contre paiement, en téléchargement, streaming ou radio, mais toujours aux conditions voulues par le détenteur des droits, et toute autre source est clairement illicite.
On peut prévoir un identifiant unique pour chaque élément ou objet copyrighté, même si ces éléments sont inclus dans des millions d'objets dans tout l'Internet 3D. Cet identifiant comportera un radical fixe et unique, daté. Il comportera un préfixe indiquant en clair son URL dans le Serveur de Copyright, là ou aller chercher l'élément. L'identifiant comportera aussi des suffixes indiquant le détenteur du copyright, le type de licence, etc. Ces affixes pouvant varier, il suffit de les enlever pour retomber sur un identifiant unique pour chaque création. Quand l'objet est instancié ou dupliqué, un identifiant unique d'instance est ajouté.
L'accès au Serveur de Copyright se fait par une prise WEM, probablement en HTTPS, en indiquant le nom du personnage requérant l'élément. Ce système peut aussi servir pour l'Internet 2D, et même pour l'achat d'éléments. Le nom du personnage est alors ajouté à la liste des propriétaires, sur le serveur de copyright.
Il faut toutefois se rappeler que, de par la nature de l'immersion 3D, des utilisateurs qui ne sont pas propriétaire de l'élément peuvent être amenés à le voir ou à l'entendre, et donc à le télécharger dans le cache de leur navigateur. Et un pirate pourra toujours extraire ces éléments du cache du navigateur, voire de la mémoire, à l'aide d'un logiciel pirate. L'élément peut alors se balader librement sur Internet.
Pour contrer ceci, diverses solutions palliatives sont envisageables:
- Un marquage secret dans les fichiers images ou son, avec le nom du détenteur du copyright, généralement la personne qui l'a téléchargé vers le serveur. Ainsi il est facile de démontrer les antériorités, et de trouver la personne qui aurait re-téléchargé ces éléments vers un serveur.
- Stocker des fichiers d'épreuve sur le Serveur de Copyright avec une bonne qualité, et n'envoyer sur Internet que des versions dégradées et «watermarquées». Ainsi, même si un pirate les remet sous une forme physique, puis les re-numérise, on peut toujours prouver à qui elles ont été volées, en les comparant avec le fichier d'épreuve.
- Utiliser des DRMs. Cette solution a été sabotée dans l'Internet 2D, par le refus de l'interopérabilité. C'était pourtant une condition aussi évidente que nécessaire, car les gens aiment copier leurs fichiers sur plusieurs ordinateurs ou lecteurs. Toutefois ce problème ne se pose pas avec l'interopérabilité intrinsèque du WEM, puisque les objets sont non-locaux, téléchargeant chacun leurs éléments à la même source, et vus avec le même navigateur.
- Un système de log des transactions permettant de retrouver des vendeurs ou distributeurs frauduleux.
- L'analyse des logs des Serveurs de Copyright peut dépister des objets demandant à télécharger des éléments qu'ils ne devraient pas.
On peut toutefois penser à des mesures bien plus radicales:
- Agglomérer toutes les textures copyrightées en une seule méta-texture, qui est seule envoyée au navigateur. On peut alors brouiller cette méta-texture, tourner et dilater chaque face différemment dans la texture map, de façon à ce que récupérer un élément copyrighté demande plus de travail que d'en créer un. Il faut toutefois prévoir de ne recharger que les parties nouvelles de la méta-texture, quand une nouvelle texture apparaît. A noter qu'un propriétaire de monde ne peut pas non plus récupérer la texture non-brouillée, car lui aussi la reçoit brouillée depuis le serveur de copyright.
- Effectuer le calcul du rendu 3D dans les locaux de la Société d'Hébergement de personnage, et n'envoyer qu'une vidéo vers le navigateur de l'utilisateur. Cela s'appelle l'architecture WEM intégrale, par opposition à l'architecture WEM réduite qui effectue le rendu 3D sur l'ordinateur local. Cela sera possible dans quelques années, au prix d'une plus large bande passante. Mais cette solution élimine radicalement tout téléchargement d'éléments copyrightés, et pourrait donc en finale s'avérer moins couteuse pour tout le monde. Cela nous débarrasse aussi des cartes graphiques toujours changeantes, des librairies de rendu 3D archaiques et des mauvais systèmes d'exploitation. Ce système présentera aussi le même rendu à tout le monde, quel que soit le système ou le budget. Il ouvrira enfin les mondes virtuels à des ordinateurs portables ou de faible puissance, qui seront la tendance dans quelques années.
- (Ajouté le 29 Sept 2009) Le serveur de copyright envoie les sons en streaming avec une fréquence d'échantillonnage variable et imprévisible. Cela ne nuit pas à la qualité, mais toute tentative pour enregistrer l'oeuvre dans un fichier (ou pour renumériser la sortie analogique) produit un battement de fréquence faisant apparaître un son parasite (la modulation de fréquence). Ce son peut être un message anti-pirates, ou tout autre bruit susceptible de rendre l'enregistrement inécoutable. Un procédé similaire pourrait faire apparaître des textes révélateurs sur les images, textures ou vidéos.
- Bien entendu, le WEM devra exclure tout site ou protocole spécifiquement conçu pour le piratage, tels que le P2P, bit torrent, etc.
Cette liste de protections n'est pas limitative, vu l'agilité des pirates. Toutefois les solutions techniques pourront toujours être plus ou moins tournées. La résolution de ce problème passera par la loi, et par la dénonciation des idéologies réactionnaires de «liberté» égocentrique apparues dans les années 1980. Que au moins la piraterie ne soit plus considérée comme normale par la majorité.
(Ajouté le 25 Juillet 2009)
Il est peu probable que tout le monde s'accorde sur un simulateur unique, avec un langage unique de description des mondes. Il faut donc dès le départ une capacité à l'interopérabilité entre langages et simulateurs différents. Une seconde raison est que des simulateurs différents auront à animer des régions voisines du même monde, en vue l'une de l'autre, sans compter les personnages servis par leur société d'hébergement, ou les objets présentés par des serveurs de copyright, etc. Il faudra alors rendre des objets appartenant à des systèmes différents, décrits dans des langages différents. Une troisième raison est qu'une description statique des mondes doit se compléter par les mouvements imprévisibles des différents objets ou personnages. Les simulateurs comportent donc en interne un moyen de décrire ces mouvements. Mais chaque simulateur devra aussi en informer les autres simulateurs. Le but de cette sous-partie est de résoudre ces deux problèmes en proposant une norme pour les échanges entre simulateurs: le langage d'interconnexion Kailye.
Le tout première exigence est que la scène soit perçue par tout le monde de la même façon, aux retards de transmission près. Même si ça bugue, on doit tous voir le même bug. Pour cela les scripts et animations devront tourner dans le monde, sur le simulateur, et non pas dans le navigateur. Ceci concerne particulièrement les animations rapides telles que danse ou combat, mais aussi les générateurs aléatoires d'éléments (arbres à contourner...) ou d'événements (vagues à surfer...) qui doivent donner une scène unique pour tous. Pour la même raison, les actions de l'utilisateur devront être d'abord actualisées sur le simulateur, et seulement ensuite le résultat actualisé, quel qu'il soit, renvoyé au navigateur. Une scène donnée ne doit être calculée qu'en un seul endroit.
On ne peut toutefois pas envoyer au navigateur une scène actualisée pour chaque frame. Le simulateur calculera donc pour chaque objet sa trajectoire, qui est une prédiction (et techniquement une animation, c'est à dire une suite de mouvements prédéfinis). Le simulateur utilisera ces trajectoires à ses propres fins, mais il les enverra aussi aux autres simulateurs, afin que chaque simulateur puisse tenir compte de ce que font les autres, en particulier aux frontières. Mais surtout il enverra ces trajectoires au navigateur, sous formes d'animations tournant dans le navigateur.
Mais si un événement imprévu arrive, tel qu'une action d'un utilisateur ou d'un script, alors la trajectoire déjà prévue doit être modifiée à partir d'une certaine date: c'est un point d'inflexion. Le simulateur effectue alors une nouvelle prédiction, qui est envoyée aux autres simulateurs et au navigateur. Cette nouvelle trajectoire écrase la précédente à partir de la date du point d'inflexion. Toute la finesse de la simulation sera donc dans la capacité du simulateur d'actualiser ces trajectoires de manière rapide et réaliste: marche aisée entre des murs, machines obéissant aux lois de la mécanique, ballon rebondissant différemment selon le sport, etc.
Pour clarifier cette vision des trajectoires, on peut comparer avec les «interpolators», qui sont les animations du VRML/X3D. Les interpolators sont écrits par le créateur du monde, et ils comprennent une suite de coordonnées appelées points-clé, se succédant dans un temps relatif (de 0 à 1). L'interpolator tourne sur le navigateur, et il démarrant à sur demande et pour une durée fixée par un timer. Le navigateur interpole alors à chaque frame entre les points-clé. Les Trajectoires fonctionneraient de manière similaire, mais elles sont créées au vol par le simulateur, sans que le créateur du monde y ait accès. De plus elles sont en temps absolu, et ne s'arrêtent jamais, même si l'objet est immobile. Le navigateur et les autres simulateurs devront donc recevoir les séries de points-clé dans un buffer circulaire, où les valeurs futures écraseront les valeurs obsolètes. Chaque point clé (d'inflexion ou non) comprendra une date absolue et des coordonnées (ou une vitesse, une accélération, voire la dérivée de l'accélération). On pourra avoir des trajectoires de mouvement, de rotation, de couleur, de texture map, de déformation, de scalaire, de paramètres de commande de NURBS, etc. Le même système peut aussi être utilisé pour envoyer des textes, des états logiques, etc. Par exemple une porte devra s'ouvrir à une certaine date. Les générateurs d'éléments aléatoires pourront utiliser le même système: n'envoyer que les nombres-semences et tourner sur le navigateur à l'identique du simulateur. Le point important ici est que, même si chaque navigateur (et les autres simulateurs) fait tourner localement la trajectoire, il n'y a qu'un seul endroit où cette trajectoire est calculée. On a donc bien une unicité de vue, tant que la connexion n'est pas coupée.
Le problème que nous avons à résoudre se résume donc à envoyer aux autres simulateurs et au navigateur la description d'un objet, accompagnée de la trajectoire prévue. Pourquoi ne pas faire les deux dans un seul message.
La première norme à établir concerne le nommage des objets («objet» est ici à prendre au sens large, incluant paysages, personnages, scripts...). Il doit se faire par un identifiant unique. Or il existe déjà un système de nommage produisant automatiquement un nom unique pour chaque objet: ce sont les URLs, qui en plus indiquent où aller chercher l'objet. Une URL est une chaîne de caractères comprenant:
Http:// Un protocole pour aller chercher la description (peut être n'importe lequel)
met.domaine.extension comme pour l'internet 2D, mais «met» joue dans le Métaverse le rôle du «www» dans l'Internet.
/path/ désigne un chemin dans l'arborescence du serveur qui héberge l'objet. Cela correspond aussi à la hiérarchie géométrique des objets (grouping nodes du VRML)
fichier est le nom de l'objet, qui comprend un identifiant unique de création, la description des copyrights, un identifiant et propriétaire d'instance.
.extension devrait suffire pour indiquer le langage de description, sans avoir à ouvrir le fichier pour y lire des types mime. Ce dernier peut être indiqué en paramètre.
?Parametre1=value¶metre2=x,y,z... indique toutes les données géométriques ou physiques de l'instance de l'objet: coordonnées, état, position des articulations, nom lisible par un humain, etc.
Ce nom est une URL, qui indique où télécharger la description de l'objet. .extension détermine alors au navigateur le choix du parser, objet par objet. Ainsi, pour chaque objet, quel que soit le serveur ou le langage, on sait où aller le chercher, et quel module parser utiliser. On peut donc avoir tous les mixages possibles, objet par objet, système par système, serveur par serveur, et les frontières entre systèmes différents ne sont plus un cas particulier.
La seconde norme à établir concerne le format des trajectoires. Ce sont essentiellement des tableaux où l'index est la date. Il faut prévoir un moyen d'indiquer si le point-clé concerne la position ou une de ses dérivées. Même si on utilise une dérivée, il est bon de rappeler la position de temps à autres.
La troisième norme à établir concerne un langage d'échanges de messages entre simulateurs. Exemple de messages:
«Simulateur 1 à Simulateur 2: Un personnage arrive dans ton paysage selon telle trajectoire
«Simulateur 2 à Simulateur 1: Il y a un autre personnage à tel endroit, tu dois modifier la trajectoire à partir de tel point d'inflexion.
«Simulateur 1 à Simulateur 2: C'est fait, voilà la nouvelle trajectoire.
«Simulateur 1 à Simulateur 2: Peux-tu prendre le personnage en charge?
«Simulateur 2 à Simulateur 1: Non, il y a une boume chez moi et je lague déjà pas mal.
«Simulateur 1 à Simulateur 2: Alors passe moi l'URL de ton paysage.
«Simulateur 2 à simulateur 1: La voilà.»
Cet exemple montre clairement que chaque message comprendra:
-Le nom du simulateur qui l'envoie, qui sera, là encore, son URL.
-Un identifiant de message, contenant la date d'émission
-Le nom de l'objet concerné, comme vu ci-dessus, qui est aussi une URL
-La trajectoire de l'objet
-Une commande indiquant le but du message: question ou réponse, modification de trajectoire, prise en charge, partage des tâches, ajout ou suppression d'un objet, etc. Les éventuelles évolutions se joueront là, par l'ajout de nouvelles commandes, différentes ou plus globales.
Le nom du simulateur, comme toute URL, commencera par le protocole à utiliser, qui n'a donc pas besoin d'être le même pour tout le monde. On peut penser à un format genre messagerie instantanée, mais bien plus rapide, connectant directement les simulateurs entre eux.
Des manoeuvres telles que placer une simulation à côté d'un autre peuvent s'effectuer à l'aide de messages Kailyé indiquant à chaque simulateur les coordonnées de l'autre. Cela vaut aussi pour téléporter d'un monde à l'autre des éléments tels que personnage, maison mobile, vaisseau spatial, etc. On peut même réaliser facilement des portals ou des stargates reliant des endroits éloignés.
En fait le Kailyé serait une extension de la description statique du monde, prenant en charge les mouvements et événements imprévisibles. Ce système est infiniment plus souple que les classiques animations du VRML.
Il est clair qu'aucune interopérabilité sérieuse ne peut se faire sans une telle norme. Mais aussi, une fois qu'elle existera, les systèmes qui refuseront de s'y plier seront rapidement éjectés du métaverse.
(Ajouté le 25 Juillet 2009)
(Pour les raisons vues dans la partie précédente sur la gestion des propriétés et copyrights, il vaut bien mieux exécuter le rendu 3D sur le serveur de la Société d'Hébergement de Personnage, ce qui est appelé l'architecture WEM intégrale. Les éléments copyrightés tels que sons, textes ou textures, arrivent alors directement du Serveur de Copyright au serveur de la Société d'hébergement de Personnage, sans passer par des simulateurs tiers susceptible d'être modifiés par des pirates. Cela donne à ce serveur le statut d'un véritable simulateur, le Simulateur de Personnage, centré sur le corps du personnage, et qui peut aussi contenir les objets lui appartenant, voire un monde personnel à la façon de Google Lively. La soupplesse du Kailye permet alors à ce Simulateur de Personnage d'interagir avec les autres simulateurs, quand le personnage rentre dans un monde. Toutefois, pour la compréhension, nous continuerons à dire dans la suite «navigateur» pour parler du Simulateur Personnel. Il suffit de transposer. Ceci a été ajouté le 25 Juillet 2009)
Le Kailyé sera également utile comme format d'échange entre le navigateur et les simulateurs. En effet on ne peut actualiser les mouvements à chaque frame du navigateur. Mais il suffit d'ajouter une trajectoire à la description de l'objet, qui sera une animation tournant dans le navigateur. Toutefois ces animations sont déterminées par le simulateur, de manière unique pour tout le monde. Elles ne sont modifiées que quand le simulateur ajoute un point d'inflexion.
Avec ce système, le navigateur connaît le protocole et le langage pour chaque objet, il peut donc télécharger chaque objet où qu'il soit situé, et choisir le parser adéquate.
Ces différents parsers devront alors s'accorder pour écrire dans un espace mémoire unique pour la description de la scène. C'est une norme importante, mais toutefois elle est spécifique au navigateur WEM que nous considérons. Cet espace mémoire étant utilisé par des modules parsers différents, éventuellement écrits dans des langages différents par des équipes différentes, sa description doit être disponible sous forme d'une librairie dans plusieurs langages, en programmation objet. Il faut aussi veiller à ce qu'un parser n'écrase pas les écritures d'un autre.
A ce stade, il n'est plus question de langages de description textuel tel que le X3D, mais d'une description codée sous forme lisible par la machine, et spécifique au navigateur considéré. Toutefois on y rencontrera encore différents types d'objets: meshes, NURBS, lignes, points, primitives, textures 3D, brouillards... que différents modules vont traiter et écrire dans le Z buffer et dans la mémoire image où se construit l'image 2D. Il nous faut donc similairement la description de cette mémoire et comment y écrire. Que plusieurs modules puissent écrire simultanément dans le Z buffer et la mémoire vidéo permettra de mieux utiliser les multi-coeurs et cartes graphiques. La collection de modules capables d'écrire dans la mémoire image fera toute la richesse et la flexibilité du rendu 3D du navigateur.
Pour ces raisons le Kailyé devrait faire partie de la norme WEM, même si il est possible de le faire évoluer indépendamment.
Des norme comme le WEM et le Kailyé décrites ici sont cruciales, car rien ne pourra se faire sans elles. Mais aussi, une fois adoptées, elle seront difficiles à modifier. Il est donc important de les tester et de prévoir un système de versions, qui ne devra être utilisé que avec parcimonie, pour corriger des bugs ou combler des manques. On peut donc considérer pour le WEM et pour le Kailyé des versions zéro d'étude, non garanties, une version 1 d'évaluation, utilisable mais non définitive, une version 2 stable et utilisable commercialement. Il n'est toutefois pas question d'avoir une nouvelle version tous les trois mois: Les versions 3 ou plus ne devront être utilisées que pour ajouter des innovations techniques actuellement imprévisibles, une fois tous les cinq-sept ans au minimum. La compatibilité ascendante devra être garantie à partir de la version 1. Une lettre à la fin du numéro de version WEM indiquera la version des protocoles secrets, qui peuvent avoir à évoluer très rapidement, indépendamment des autres normes que l'on veut fixes.
(Cette partie a été réécrite le 14 Septembre 2009)
(Le NRMP s'appelait d'abord NCCS)
Des choses telles que les exosquelettes, ou le système Kailyé lui-même, nécessitent un protocole de transfer rapide et sans pertes, quoiqu'avec un débit bas. Il existe des améliorations du HTTP, pour une plus grande rapidité. Le DCCP en est un exemple populaire, utilisé pour le streaming ou le VoIP. Il est rapide, mais au prix de perdre une partie des données si le trafic est congestionné. Utilisé pour le Kailyé, il donnerait un fonctionnement aléatoire à la Second Life. Utilisé pour les exosquelettes, la conduite de véhicules rapides, etc. il pourrait produire des accidents ou des blessures, sans parler d'activités telles que la téléchirurgie.
D'où le besoin d'un nouveau système qui s'affranchisse du caractère aléatoire du HTTP. Afin d'y arriver, il nous faut nos propres routes, sans bufférisation à chaque noeud, et utilisant des chemins constants et optimisés.
Mais il faut noter que, à cause de la vitesse de la lumière, le lien internet le plus rapide nécessite jusqu'à 150 millisecondes pour communiquer avec les antipodes, temps à doubler pour un retour de force ou pour une contre-réaction. C'est la communication la plus rapide sur l'Internet, et sera déjà une limitation sensible pour des activités corporelles rapprochées telles que combat, conduite, sexe, téléchirurgie, etc. Télécommander un véhicule dans ces conditions équivalent à être légèrement saoul. Pour cette raison le protocole NRMP ne doit pas utiliser de satellites géostationnaires, qui ajoutent chacun 200 ms.
Ainsi le NRMP est du même niveau que le HTTP, mais c'est un protocole à base de connexion, plutôt qu'un système par paquets. Il est équivalent à une ligne télétype, avec un taux de transfert faible mais constant, arrivée dans l'ordre, et pas de paquets perdus. Toutefois le seul moyen de s'affranchir du traffic HTTP aléatoire est d'avoir une fibre ou un câble entièrement dédié au traffic NRMP. C'est une demande raisonnable, car les câbles aujourd'hui contiennent de nombreux fils ou fibres, et on peut donc en réserver un peu, même pour un très petit pourcentage du trafic total. Les modems sont les mêmes, seuls des routeurs spécifiques sont à développer pour cette application. Le NRMP proposé ici n'utilise pas des paquets envoyés au hasard, mais un multiplexage temporel fixe des paquets. Chaque noeud du réseau a un calendrier dans une frame temporelle, qui contient de nombreux intervalles élémentaires. Chacun de ces intervalles est réservé à une des connexions NRMP multiplexée, et dure le temps de transmettre un paquet. Les calendriers de chaque routeur dans le chemin sont établis quand la connexion est négociée, en tenant compte des intervalles déjà utilisés et de la longueur des câbles entre les noeuds. Ainsi le routeur sait quand il recevra un paquet d'un expéditeur donné, et où le renvoyer. Il lui suffit de stocker ces destinations dans une table (le calendrier), compter les intervalles comme ils arrivent, et lire la destination dans la table. De cette façon, tout paquet de données est immédiatement réexpédié, sans délai ni tamponnements, tout au long de la chaîne de routeurs. Un paquet se déplaçant le long de la chaîne verra des interrupteurs tous placés dans la bonne position. Et maintenant que l'on a compris cela, on voit que les modems ne sont pas utiles, juste le routeur commute le paquet d'onde analogique à l'aide d'amplificateurs de ligne à gain contrôlé. Ainsi la connexion NRMP individuelle est véritablement établie, fonctionnant comme un câble de télétype. Elle est disponible tout le temps, jusqu'à un taux de transfert donné. Le délai d'acheminement est constant et minimum. Les données sont toujours dans l'ordre, et la perte de paquets est 0% (dans des conditions normales). Et en plus le NRMP a priorité sur le trafic HTTP. Un tel système est optimal pour des activités corporelles en 3D, avec pour seule limite la vitesse de la lumière. En plus les routeurs ne consommeront que peu d'énergie, et encore moins si ils utilisent des circulateurs d'ondes. Au point que ce ne serait pas surprenant si un jour le NRMP remplace le HTTP.
Le calendrier d'un routeur sera saturé bien avant que tous les intervalles soient pris (impossibilité d'ajouter une chaîne cohérente d'intervalles tout au long de la chaîne de routeurs) mais c'est là le prix pour avoir un système fiable. Ces intervalles inutilisés peuvent être utilisés pour les messages de service, ou pour du traffic HTTP.
On peut aussi ajouter des routes alternatives, pour des versions haute fiabilité du NRMP. La version de base NRMP conviendra pour des jeux et les activités sociales, tandis que les versions haute fiabilité pourraient être autorisées pour la télécommande de véhicules, ou pour la téléchirurgie.
(Ajouté le 14 Sept 2009) Enfin, la principale application WEM du NRMP, la Connexion de Gestion des Autorisations, nécessitera un chiffrage sûr. Il nous faut donc, dès le début, penser à une version chiffrée du NRMP. On peut procéder de nombreuses façons, comme par exemple mélanger aléatoirement les paquets ou les intervales. Il serait mathématiquement très difficile de casser un flux de données contenant de nombreux messages différents.
(Ajouté le 23 Novembre 2011) En ce qui concerne la ligne d'abonné (liaison entre Internet et l'ordinateur de l'utilisateur), il n'est pas forcément nécessaire de modifier son protocole (le plus souvent ADSL). Il suffit que les paquets NRMP entrants soient prioritaires sur les paquet HTTP, et reconnaissables. Pour le traffic sortant, l'ordinateur doit tout de même envoyer les paquets NRMP à un rythme régulier. Pour cela, il faut qu'il soit informé du calendrier du noeud NRMP avec le quel il communique. Idéalement, si l'ordinateur peut envoyer le paquet à l'instant exact, alors il n'y a pas besoin de le bufferiser au noeud d'entrée NRMP.
(Ajouté le 14 Sept 2009) On remarque ici qu'une adaptation technique des réseaux Internet est tout de même souhaitable pour un fonctionnement correct des mondes virtuels. Cela expose le WEM à des actions de bloquage de la part des ennemis du virtuel. Mais il faut remarquer qu'un protocole comme le NRMP, surtout chiffré, peut être utile à de nombreuses autres applications: transfer de données administratives, transactions financières, télécommande de processus industriels, etc. Ainsi une société qui développerait un réseau NRMP pourrait le rentabiliser facilement, sans attendre le WEM. En attendant la disponibilité d'un réseau NRMP chiffré, le WEM peut toujours utiliser les réseaux existants, en doublant et triplant les connexions, et en codant les messages Kailyé eux-mêmes.
(Ajouté le 18 Janvier 2010) Le meilleur candidat pour le NRMP semble être the SCTP, qui semble prévu précisément pour ce genre d'utilisation. Reste à savoir dans quelle mesure le délai de transmission du SCTP est stable et proche du minimum théorique.
(ajouté le 2 mai 2014) NRMP et neutralité du net. L'information a émergé récemment comme quoi la congestion croissante de l'Internet n'est pas causée par un manque de fibres optiques, mais par leur fermeture délibérée, dans une tentative de racket par certaines entreprises d'Internet qui veulent proposer un Internet plus cher mais plus rapide. Ainsi ces entreprises pourront étaler leurs égos infantiles et leurs idéologies grises, tout en reléguant l'Internet libre dans un ghetto de mauvaise qualité à bas prix.
Dans une telle situation, le NRMP peut sembler une tentative d'aider ces entreprises. Ce n'est pas le cas, puisque je l'ai proposé avant que le racket ne soit révélé. Une fois ce problème résolu, il se pourrait au contraire qu'Internet puisse fonctionner de manière très saine, avec ses pointes de charge ne représentant qu'une petite fraction de sa capacité totale. Dans ce cas, le NRMP pourrait ne même pas être nécessaire.