Le groupe

Suite au post du 7 août.

Le groupe est une notion assez générale qui désigne un certain nombre d’objets reliés entre eux par un seul objet. Ces objets pouvant être des entités.

Il y a deux façons de l’implémenter, en fonction de ce que l’on veut en faire :
– le groupe uni-polaire
– le groupe multipolaire

Le groupe uni-polaire

En pratique, le fait de lier deux objets entre eux crée un groupe. L’objet méta reste un peu à part dans le fonctionnement même si techniquement il fait potentiellement parti du groupe aussi. Un objet lié à plusieurs autres objets peut donc être vu comme un groupe.

Pour se rapprocher d’une utilisation courante, on peut créer par exemple un objet contenant le nom du groupe. Cet objet est lié (par une entité signataire) à différentes entités. Lorsque que l’on consulte les liens de cet objet, on retrouve en fonction de critères de recherche les membres du groupe. Une autre entité peut (re-)créer un objet contenant le même nom de groupe, et créer ses propres liens. La validité du groupe dépend aussi de l’entité ou des entités à qui on fait confiance.

Cette façon de gérer les groupes est donc une organisation arborescente hiérarchique, et répond aux mêmes contraintes, avantages et défauts.

En cas de  »perte » de l’entité signataire d’un groupe, celui-ci n’a plus de validité, il n’est plus utilisable.

Le groupe multipolaire

Poussons un peu la réflexion à partir du groupe uni-polaire. Et si on prend le cas un peu extrême où une entité est créé spécialement pour gérer les liens depuis elle-même vers d’autres entités?

Cette entité est le groupe. Elle est contrôlée par une entité parente.

Et si cette entité (c’est à dire les clés publiques et privées) étaient contrôlé par les entités qui lui sont lié? Cela veut dire que le groupe est contrôlé par ses propres enfants!

Cela devient de fait une entité commune (ou identité commune) à plusieurs entités.

Une entité du groupe peut utiliser l’identité commune pour signer des objets. Elle peut aussi vouloir ajouter des nouveaux membres au groupe. Pas de problème, ils doivent recevoir aussi les clés publiques et privées pour disposer de l’identité commune.

Et si on veut retirer une entité du groupe? Il n’est pas possible de lui soutirer les clés que l’on lui a transmit. Il faut donc faire diverger le groupe existant vers un nouveau groupe (nouvelle entité commune). L’ancien groupe est révoqué, et le nouveau et diffusé à tous ses nouveaux membres.

Une entité qui n’appartient plus au nouveau groupe ne peut plus s’y ajouter, mais elle peut tenter de faire diverger de son côté le groupe. Qui a raison, qui à tort… les autres entités seront les seules à pouvoir trancher.

Comment une entité peut-elle se retirer elle-même du groupe? Elle peut invalider le lien que le groupe a vers elle, et supprimer l’identité commune du groupe.

Conclusion

Ces deux façons de voir les groupes correspondent à deux gestions différentes.

Le groupe uni-polaire a un comportement hiérarchisé fort mais sa cohérence ne dépend que de la disponibilité de cette hiérarchie.

Le groupe multipolaire est une forme auto-gérée coopérative et sans point de disponibilité unique.

Les deux formes sont utilisables dans nebule en fonction des besoins.