Nos projets concernant les autorisations organisationnelles sur les espaces
Traduction de Habitat & permission spaces for organizations par Habitat team, 12 juin 2026
Chez Habitat, nous développons une couche de propriété des données pour les organisations. Au cours des dernières semaines, nous avons travaillé d’arrache-pied à l’étude de la conception des espaces à accès restreint et avons progressivement porté notre précédente implémentation de données à accès restreint (cliques!) vers ces espaces. Nous apprécions la conception proposée par l’équipe, ainsi que le niveau de précision du protocole par rapport à ce qu’il laisse à la discrétion des développeurs. Dans ce Leaflet, je vais aborder les contraintes d’Habitat concernant les données soumises à autorisation et les couches que nous avons l’intention de construire par-dessus le protocole de base des espaces.
Autorisations organisationnelles
Les autorisations organisationnelles / d’entreprise / commerciales ont des formes et des exigences différentes de celles du cas des réseaux sociaux grand public. Heureusement, le protocole Spaces est suffisamment basique pour que nous puissions construire des solutions répondant à ces exigences par-dessus.
On a beaucoup parlé dans l’écosystème d’une spécification commune pour les communautés ou les groupes sur les espaces à accès restreint, comme la spécification Arbiter de Roomy. En ce qui concerne les cas d’utilisation organisationnelle, ce genre de chose est non négociable : il faut un concept d’équipes et de rôles qui reste stable d’un produit à l’autre. Ce n’est pas le cas aujourd’hui : certains produits essaient peut-être de se synchroniser avec une liste de groupes de courriel Google, mais en général, chaque produit (par exemple Figma, Notion, Asana) a sa propre façon de définir les équipes et les autorisations organisationnelles. Ces systèmes se désynchronisent régulièrement (qui n’a jamais dû se battre pour configurer les autorisations d’un nouveau membre de l’équipe dans chaque application ?) et sont souvent gérés de manière ponctuelle, plutôt que par un processus central au sein de l’organisation.
Habitat répond également aux besoins des développeurs qui créeront des produits sur notre plateforme. Par exemple, dans notre éditeur de documents, nous souhaitons prendre en charge des autorisations plus riches que « dans le document » ou « pas dans le document » . Nous aimerions prendre en charge les rôles de propriétaire / éditeur / lecteur / commentateur sur un document : ceux-ci devraient être définis par l’application et traduits en espaces en arrière-plan. Ces rôles pourraient également s’hériter les uns des autres (si vous pouvez modifier, vous pouvez commenter), et seraient idéalement interopérables, afin qu’un autre produit de gestion de documents puisse récupérer, comprendre et réutiliser ces rôles dans son produit. Les autorisations sont l’un des aspects les plus complexes à bien mettre en place (venant de Figma/Glean, on est bien placés pour le savoir !), donc plus Habitat pourra bien gérer les éléments de base ici, plus les développeurs pourront se concentrer sur la création de la meilleure expérience produit possible. À un niveau très approximatif, ce à quoi nous pensons que cela ressemblerait, ce sont des XRPC permettant aux développeurs de produits de définir des rôles sur des entités, probablement modélisés à l’aide de relations OpenFGA. Ces relations peuvent ensuite être exposées sous forme d’enregistrements au sein des espaces pour assurer l’interopérabilité avec d’autres applications.
D’un autre côté, répondre aux besoins des organisations et des communautés qui disposent déjà d’une structure de gouvernance simplifie d’autres aspects pour nous. Par exemple, pour tous les espaces définis dans Habitat, l’organisation devient l’hôte de l’espace. La manière dont l’organisation gère l’espace lui appartient, et nous pouvons proposer des paramètres par défaut utiles, éventuellement à l’aide de DID gérés. Il existe également un niveau de confiance plus élevé entre les espaces et les applications demandant des identifiants d’espace : dans les espaces à autorisation proposée, il y a un compromis entre l’interopérabilité (toute application peut-elle lire un espace) et la confidentialité (si j’écris un enregistrement dans un espace, toute application capable de lire cet espace peut le voir, y compris celles que je ne souhaite pas). Dans un contexte organisationnel, les applications sont généralement approuvées par les administrateurs informatiques ou des ressources humaines et doivent respecter des politiques de sécurité et de confidentialité de base ; les espaces peuvent donc être interopérables en sachant qu’il existe un processus de vérification pour les applications qui y accèdent.
Développer sur Habitat
À la base, Habitat est une plateforme, et nous voulons donner aux gens les moyens de créer eux-mêmes, donc notre plateforme doit être indépendante des types de produits ou d’applications qui peuvent être développés dessus, à l’instar de la relation entre le protocole AT et ATmosphere. Les premiers groupes à développer sur Habitat créent des logiciels sur mesure pour leurs propres communautés, et nous-mêmes commençons tout juste à réfléchir à notre premier produit pour le milieu de travail basé sur Habitat.
Cela signifie que notre plateforme de développement doit être excellente, tout comme le protocole AT. Je voudrais ici aborder quelques éléments clés que nous développons pour étendre le protocole AT à la plateforme de développement d’Habitat.
Mais d’abord, un peu de « bike-shedding » pour mettre les choses en contexte. On a l’impression que le terme « PDS » (Personal Data Server) est un peu surchargé en ce moment, car on s’y réfère souvent comme s’il s’agissait d’une correspondance 1:1 avec un dépôt (par exemple, on dit « mon PDS » par opposition à « ton PDS » alors que, techniquement, nos dépôts pourraient très bien se trouver sur le même PDS). Ce fait n’a pas vraiment d’importance pour ATmosphere en général, puisque tout doit fonctionner de la même manière, peu importe quel dépôt se trouve sur quel PDS, y compris les configurations comme les dépôts auto-hébergés. Mais pour Habitat, les dépôts des membres d’une organisation sont toujours hébergés derrière le même serveur, ou PDS, puisque l’organisation détient pleinement les dépôts de ses membres. En d’autres termes, par conception, toutes les données d’une organisation sont hébergées (conceptuellement) sur un seul serveur. Nous pouvons tirer parti de cette distinction pour proposer des API utiles aux développeurs.
Comme tous les dépôts résident sur un seul PDS (ou ODS, un serveur de données organisationnel, si vous préférez), nous pouvons offrir des fonctions pratiques pour des opérations telles que le remplissage rétrospectif et les mises à jour en temps réel à l’échelle de toute une organisation (ce qui se fait aujourd’hui via des points de terminaison par utilisateur / par dépôt). Aujourd’hui, dans le protocole AT public, les relais agrègent les données entre les référentiels en appelant /xrpc/com.atproto.repo.subscribeRepos, et demandent individuellement des mises à jour à chaque utilisateur. Les AppViews communiquent avec les relais ou le jetstream afin d’éviter d’avoir à effectuer elles-mêmes ce travail d’agrégation. Spaces propose une conception similaire, où les synchroniseurs doivent agréger indépendamment toutes les données afin de maintenir une vue à jour de l’espace. Cependant, dans Habitat, puisque tous les dépôts membres se trouvent sur le même PDS, nous pouvons proposer un point de terminaison unique /xrpc/com.habitatproto.spaces.subscribeSpaces qui fonctionne comme un relais intégré à notre PDS, agrégeant les mises à jour à l’échelle de toute l’organisation.
Pour mettre en œuvre l’autorisation à cet effet, nous attribuons à chaque organisation un DID (Decentralized Identifier) organisationnel et introduisons le concept d’identifiant d’organisation, qui fonctionne comme un jeton OAuth pour l’ensemble de l’organisation. Étant donné que chaque espace au sein d’une organisation a le DID de l’organisation comme hôte d’espace, ce jeton OAuth peut être présenté à /xrpc/com.habitatproto.spaces.subscribeSpaces pour obtenir un flux d’événements pour l’espace entier. Il s’agit d’un jeton OAuth standard dont les portées sont similaires à celles des jetons OAuth utilisateur dans le reste du protocole AT : il peut demander des portées pour des lexiques ou des types d’espaces spécifiques, mais nous pouvons également l’étendre pour demander des dépôts spécifiques.
Les mécanismes de backfill dans les espaces autorisés (getRepoOpLog, listSpaces, listRecords dans la proposition relative aux espaces autorisés) fonctionnent presque de la même manière dans Habitat. Dans les espaces autorisés, pour l’authentification, ces points de terminaison prennent en charge soit le jeton OAuth personnel d’un utilisateur, soit les informations d’identification de l’espace. Les jetons OAuth d’autres utilisateurs ne peuvent pas être pris en charge, car un dépôt ne peut pas valider le jeton s’il provient d’un autre PDS et ne peut pas valider l’appartenance si l’hôte de l’espace se trouve sur un autre PDS.
Dans notre cas, puisque tout ce qui concerne un espace donné se trouve sur le même PDS, nous pouvons lire à travers les espaces et les dépôts avec n’importe quel jeton OAuth émis par le PDS. Comme un identifiant d’organisation n’est qu’un jeton OAuth, les clients de synchronisation peuvent l’utiliser pour parcourir l’ensemble de l’organisation. Les applications construites sur Habitat disposeront d’un flux d’autorisation où les administrateurs de l’organisation approuvent et émettent un identifiant d’organisation que l’application utilise pour synchroniser les données pertinentes.
Pour mieux prendre en charge les mises à jour d’événements et les remplissages rétrospectifs, nous développons Sap (du nom de Tap). Sap appelle subscribeSpaces et diffuse toutes les écritures effectuées dans l’organisation avec des événements de métadonnées d’autorisations supplémentaires. Il émettra des autorisations aplaties afin que les applications puissent construire leur propre index répliqué des autorisations. De plus, si les applications souhaitent déterminer si un utilisateur dispose d’une autorisation pour un espace ou comment il l’a obtenue (ce pour quoi nous utilisons OpenFGA en arrière-plan), elles peuvent interroger directement notre API et les enregistrements de relations que nous stockons pour assurer l’interopérabilité.
Nous n’avons pas encore exploré cela en profondeur, mais il semble qu’il y ait des implications pour l’activation d’applications « local-first » au-dessus d’Habitat, car l’agrégation entre les dépôts d’utilisateurs repose sur un modèle beaucoup plus simple. À terme, nous pourrions même réintroduire notre mécanisme de synchronisation à partir de cliques entre les PDS, mais pour le cas d’utilisation des organisations, afin que celles-ci puissent synchroniser leurs données entre elles sans passer par un serveur tiers.
Questions, commentaires et préoccupations
Cet article était assez long, et tout ce que j’ai écrit ici est en cours de développement. Nous mettrons en place une spécification et une documentation appropriées, et nous apprécions tout commentaire ou question sur la conception d’ici là !