Traduction de Habitat & permission spaces for organizations<\/a> par Habitat team, 12 juin 2026<\/p>\n\n\n\n Chez Habitat, nous d\u00e9veloppons une couche de propri\u00e9t\u00e9 des donn\u00e9es pour les organisations. Au cours des derni\u00e8res semaines, nous avons travaill\u00e9 d\u2019arrache-pied \u00e0 l\u2019\u00e9tude de la conception des espaces \u00e0 acc\u00e8s restreint et avons progressivement port\u00e9 notre pr\u00e9c\u00e9dente impl\u00e9mentation de donn\u00e9es \u00e0 acc\u00e8s restreint (cliques<\/a>!) vers ces espaces. Nous appr\u00e9cions la conception propos\u00e9e par l’\u00e9quipe, ainsi que le niveau de pr\u00e9cision du protocole par rapport \u00e0 ce qu’il laisse \u00e0 la discr\u00e9tion des d\u00e9veloppeurs. Dans ce Leaflet, je vais aborder les contraintes d’Habitat concernant les donn\u00e9es soumises \u00e0 autorisation et les couches que nous avons l’intention de construire par-dessus le protocole de base des espaces.<\/p>\n\n\n\n Les autorisations organisationnelles \/ d\u2019entreprise \/ commerciales ont des formes et des exigences diff\u00e9rentes de celles du cas des r\u00e9seaux sociaux grand public. Heureusement, le protocole Spaces<\/strong> est suffisamment basique pour que nous puissions construire des solutions r\u00e9pondant \u00e0 ces exigences par-dessus.<\/p>\n\n\n\n On a beaucoup parl\u00e9 dans l\u2019\u00e9cosyst\u00e8me d\u2019une sp\u00e9cification commune pour les communaut\u00e9s ou les groupes sur les espaces \u00e0 acc\u00e8s restreint, comme la sp\u00e9cification Arbiter de Roomy. En ce qui concerne les cas d\u2019utilisation organisationnelle, ce genre de chose est non n\u00e9gociable : il faut un concept d\u2019\u00e9quipes et de r\u00f4les qui reste stable d\u2019un produit \u00e0 l\u2019autre. Ce n\u2019est pas le cas aujourd\u2019hui : certains produits essaient peut-\u00eatre de se synchroniser avec une liste de groupes de courriel Google, mais en g\u00e9n\u00e9ral, chaque produit (par exemple Figma, Notion, Asana) a sa propre fa\u00e7on de d\u00e9finir les \u00e9quipes et les autorisations organisationnelles. Ces syst\u00e8mes se d\u00e9synchronisent r\u00e9guli\u00e8rement (qui n\u2019a jamais d\u00fb se battre pour configurer les autorisations d\u2019un nouveau membre de l\u2019\u00e9quipe dans chaque application ?) et sont souvent g\u00e9r\u00e9s de mani\u00e8re ponctuelle, plut\u00f4t que par un processus central au sein de l\u2019organisation.<\/p>\n\n\n\n Habitat r\u00e9pond \u00e9galement aux besoins des d\u00e9veloppeurs qui cr\u00e9eront des produits sur notre plateforme. Par exemple, dans notre \u00e9diteur de documents<\/a>, nous souhaitons prendre en charge des autorisations plus riches que \u00ab dans le document \u00bb ou \u00ab pas dans le document \u00bb . Nous aimerions prendre en charge les r\u00f4les de propri\u00e9taire \/ \u00e9diteur \/ lecteur \/ commentateur sur un document : ceux-ci devraient \u00eatre d\u00e9finis par l\u2019application et traduits en espaces en arri\u00e8re-plan. Ces r\u00f4les pourraient \u00e9galement s\u2019h\u00e9riter les uns des autres (si vous pouvez modifier, vous pouvez commenter), et seraient id\u00e9alement interop\u00e9rables, afin qu\u2019un autre produit de gestion de documents puisse r\u00e9cup\u00e9rer, comprendre et r\u00e9utiliser ces r\u00f4les dans son produit. Les autorisations sont l\u2019un des aspects les plus complexes \u00e0 bien mettre en place (venant de Figma\/Glean, on est bien plac\u00e9s pour le savoir !), donc plus Habitat pourra bien g\u00e9rer les \u00e9l\u00e9ments de base ici, plus les d\u00e9veloppeurs pourront se concentrer sur la cr\u00e9ation de la meilleure exp\u00e9rience produit possible. \u00c0 un niveau tr\u00e8s approximatif, ce \u00e0 quoi nous pensons que cela ressemblerait, ce sont des XRPC permettant aux d\u00e9veloppeurs de produits de d\u00e9finir des r\u00f4les sur des entit\u00e9s, probablement mod\u00e9lis\u00e9s \u00e0 l\u2019aide de relations OpenFGA. Ces relations peuvent ensuite \u00eatre expos\u00e9es sous forme d\u2019enregistrements au sein des espaces pour assurer l\u2019interop\u00e9rabilit\u00e9 avec d\u2019autres applications.<\/p>\n\n\n\n D\u2019un autre c\u00f4t\u00e9, r\u00e9pondre aux besoins des organisations et des communaut\u00e9s qui disposent d\u00e9j\u00e0 d\u2019une structure de gouvernance simplifie d\u2019autres aspects pour nous. Par exemple, pour tous les espaces d\u00e9finis dans Habitat, l\u2019organisation devient l\u2019h\u00f4te de l\u2019espace. La mani\u00e8re dont l\u2019organisation g\u00e8re l\u2019espace lui appartient, et nous pouvons proposer des param\u00e8tres par d\u00e9faut utiles, \u00e9ventuellement \u00e0 l\u2019aide de DID g\u00e9r\u00e9s. Il existe \u00e9galement un niveau de confiance plus \u00e9lev\u00e9 entre les espaces et les applications demandant des identifiants d’espace : dans les espaces \u00e0 autorisation propos\u00e9e, il y a un compromis entre l’interop\u00e9rabilit\u00e9 (toute application peut-elle lire un espace) et la confidentialit\u00e9 (si j’\u00e9cris 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\u00e9n\u00e9ralement approuv\u00e9es par les administrateurs informatiques ou des ressources humaines et doivent respecter des politiques de s\u00e9curit\u00e9 et de confidentialit\u00e9 de base ; les espaces peuvent donc \u00eatre interop\u00e9rables en sachant qu\u2019il existe un processus de v\u00e9rification pour les applications qui y acc\u00e8dent.<\/p>\n\n\n\n \u00c0 la base, Habitat est une plateforme, et nous voulons donner aux gens les moyens de cr\u00e9er eux-m\u00eames, donc notre plateforme doit \u00eatre ind\u00e9pendante des types de produits ou d\u2019applications qui peuvent \u00eatre d\u00e9velopp\u00e9s dessus, \u00e0 l\u2019instar de la relation entre le protocole AT et ATmosphere. Les premiers groupes \u00e0 d\u00e9velopper sur Habitat cr\u00e9ent des logiciels sur mesure pour leurs propres communaut\u00e9s, et nous-m\u00eames commen\u00e7ons tout juste \u00e0 r\u00e9fl\u00e9chir \u00e0 notre premier produit pour le milieu de travail bas\u00e9 sur Habitat.<\/p>\n\n\n\n Cela signifie que notre plateforme de d\u00e9veloppement doit \u00eatre excellente, tout comme le protocole AT. Je voudrais ici aborder quelques \u00e9l\u00e9ments cl\u00e9s que nous d\u00e9veloppons pour \u00e9tendre le protocole AT \u00e0 la plateforme de d\u00e9veloppement d\u2019Habitat.<\/p>\n\n\n\n Mais d\u2019abord, un peu de \u00ab bike-shedding \u00bb pour mettre les choses en contexte. On a l\u2019impression que le terme \u00ab PDS \u00bb (Personal Data Server) est un peu surcharg\u00e9 en ce moment, car on s\u2019y r\u00e9f\u00e8re souvent comme s\u2019il s\u2019agissait d\u2019une correspondance 1:1 avec un d\u00e9p\u00f4t (par exemple, on dit \u00ab mon PDS \u00bb par opposition \u00e0 \u00ab ton PDS \u00bb alors que, techniquement, nos d\u00e9p\u00f4ts pourraient tr\u00e8s bien se trouver sur le m\u00eame PDS). Ce fait n\u2019a pas vraiment d\u2019importance pour ATmosphere en g\u00e9n\u00e9ral, puisque tout doit fonctionner de la m\u00eame mani\u00e8re, peu importe quel d\u00e9p\u00f4t se trouve sur quel PDS, y compris les configurations comme les d\u00e9p\u00f4ts auto-h\u00e9berg\u00e9s. Mais pour Habitat, les d\u00e9p\u00f4ts des membres d\u2019une organisation sont toujours h\u00e9berg\u00e9s derri\u00e8re le m\u00eame serveur, ou PDS, puisque l\u2019organisation d\u00e9tient pleinement les d\u00e9p\u00f4ts de ses membres. En d\u2019autres termes, par conception, toutes les donn\u00e9es d\u2019une organisation sont h\u00e9berg\u00e9es (conceptuellement) sur un seul serveur. Nous pouvons tirer parti de cette distinction pour proposer des API utiles aux d\u00e9veloppeurs.<\/p>\n\n\n\n Comme tous les d\u00e9p\u00f4ts r\u00e9sident sur un seul PDS (ou ODS, un serveur de donn\u00e9es organisationnel, si vous pr\u00e9f\u00e9rez), nous pouvons offrir des fonctions pratiques pour des op\u00e9rations telles que le remplissage r\u00e9trospectif et les mises \u00e0 jour en temps r\u00e9el \u00e0 l’\u00e9chelle de toute une organisation (ce qui se fait aujourd’hui via des points de terminaison par utilisateur \/ par d\u00e9p\u00f4t). Aujourd\u2019hui, dans le protocole AT public, les relais agr\u00e8gent les donn\u00e9es entre les r\u00e9f\u00e9rentiels en appelant Pour mettre en \u0153uvre l\u2019autorisation \u00e0 cet effet, nous attribuons \u00e0 chaque organisation un DID (Decentralized Identifier) organisationnel et introduisons le concept d\u2019identifiant d\u2019organisation, qui fonctionne comme un jeton OAuth pour l\u2019ensemble de l\u2019organisation. \u00c9tant donn\u00e9 que chaque espace au sein d\u2019une organisation a le DID de l\u2019organisation comme h\u00f4te d\u2019espace, ce jeton OAuth peut \u00eatre pr\u00e9sent\u00e9 \u00e0 Les m\u00e9canismes de backfill dans les espaces autoris\u00e9s ( Dans notre cas, puisque tout ce qui concerne un espace donn\u00e9 se trouve sur le m\u00eame PDS, nous pouvons lire \u00e0 travers les espaces et les d\u00e9p\u00f4ts avec n’importe quel jeton OAuth \u00e9mis 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\u00f9 les administrateurs de l’organisation approuvent et \u00e9mettent un identifiant d’organisation que l’application utilise pour synchroniser les donn\u00e9es pertinentes.<\/p>\n\n\n\n Pour mieux prendre en charge les mises \u00e0 jour d\u2019\u00e9v\u00e9nements et les remplissages r\u00e9trospectifs, nous d\u00e9veloppons Sap (du nom de Tap). Sap appelle Nous n’avons pas encore explor\u00e9 cela en profondeur, mais il semble qu’il y ait des implications pour l’activation d’applications \u00ab local-first \u00bb au-dessus d’Habitat, car l’agr\u00e9gation entre les d\u00e9p\u00f4ts d’utilisateurs repose sur un mod\u00e8le beaucoup plus simple. \u00c0 terme, nous pourrions m\u00eame r\u00e9introduire notre m\u00e9canisme de synchronisation \u00e0 partir de cliques entre les PDS, mais pour le cas d’utilisation des organisations, afin que celles-ci puissent synchroniser leurs donn\u00e9es entre elles sans passer par un serveur tiers.<\/p>\n\n\n\n Cet article \u00e9tait assez long, et tout ce que j’ai \u00e9crit ici est en cours de d\u00e9veloppement. Nous mettrons en place une sp\u00e9cification et une documentation appropri\u00e9es, et nous appr\u00e9cions tout commentaire ou question sur la conception d’ici l\u00e0 !<\/p>\n","protected":false},"excerpt":{"rendered":" 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\u00e9veloppons une couche de propri\u00e9t\u00e9 des donn\u00e9es pour les organisations. Au cours des derni\u00e8res semaines, nous avons travaill\u00e9 d\u2019arrache-pied \u00e0 l\u2019\u00e9tude de la conception des espaces \u00e0 acc\u00e8s restreint … <\/p>\n
\n\n\n\nAutorisations organisationnelles<\/a><\/h3>\n\n\n\n
D\u00e9velopper sur Habitat<\/a><\/h3>\n\n\n\n
\/xrpc\/com.atproto.repo.subscribeRepos<\/code>, et demandent individuellement des mises \u00e0 jour \u00e0 chaque utilisateur. Les AppViews communiquent avec les relais ou le jetstream afin d\u2019\u00e9viter d\u2019avoir \u00e0 effectuer elles-m\u00eames ce travail d\u2019agr\u00e9gation. Spaces propose une conception similaire, o\u00f9 les synchroniseurs doivent agr\u00e9ger ind\u00e9pendamment toutes les donn\u00e9es afin de maintenir une vue \u00e0 jour de l\u2019espace. Cependant, dans Habitat, puisque tous les d\u00e9p\u00f4ts membres se trouvent sur le m\u00eame PDS, nous pouvons proposer un point de terminaison unique \/xrpc\/com.habitatproto.spaces.subscribeSpaces<\/code> qui fonctionne comme un relais int\u00e9gr\u00e9 \u00e0 notre PDS, agr\u00e9geant les mises \u00e0 jour \u00e0 l\u2019\u00e9chelle de toute l\u2019organisation.<\/p>\n\n\n\n\/xrpc\/com.habitatproto.spaces.subscribeSpaces<\/code> pour obtenir un flux d\u2019\u00e9v\u00e9nements pour l\u2019espace entier. Il s\u2019agit d\u2019un jeton OAuth standard dont les port\u00e9es sont similaires \u00e0 celles des jetons OAuth utilisateur dans le reste du protocole AT : il peut demander des port\u00e9es pour des lexiques ou des types d\u2019espaces sp\u00e9cifiques, mais nous pouvons \u00e9galement l\u2019\u00e9tendre pour demander des d\u00e9p\u00f4ts sp\u00e9cifiques.<\/p>\n\n\n\ngetRepoOpLog, listSpaces, listRecords<\/code> dans la proposition relative aux espaces autoris\u00e9s) fonctionnent presque de la m\u00eame mani\u00e8re dans Habitat. Dans les espaces autoris\u00e9s, pour l\u2019authentification, ces points de terminaison prennent en charge soit le jeton OAuth personnel d\u2019un utilisateur, soit les informations d\u2019identification de l\u2019espace. Les jetons OAuth d\u2019autres utilisateurs ne peuvent pas \u00eatre pris en charge, car un d\u00e9p\u00f4t ne peut pas valider le jeton s\u2019il provient d\u2019un autre PDS et ne peut pas valider l\u2019appartenance si l\u2019h\u00f4te de l\u2019espace se trouve sur un autre PDS.<\/p>\n\n\n\nsubscribeSpaces<\/code> et diffuse toutes les \u00e9critures effectu\u00e9es dans l\u2019organisation avec des \u00e9v\u00e9nements de m\u00e9tadonn\u00e9es d\u2019autorisations suppl\u00e9mentaires. Il \u00e9mettra des autorisations aplaties afin que les applications puissent construire leur propre index r\u00e9pliqu\u00e9 des autorisations. De plus, si les applications souhaitent d\u00e9terminer si un utilisateur dispose d’une autorisation pour un espace ou comment il l’a obtenue (ce pour quoi nous utilisons OpenFGA en arri\u00e8re-plan), elles peuvent interroger directement notre API et les enregistrements de relations que nous stockons pour assurer l’interop\u00e9rabilit\u00e9.<\/p>\n\n\n\nQuestions, commentaires et pr\u00e9occupations<\/a><\/h3>\n\n\n\n