Les espaces continuent de parler pendant que l'hôte dort

Chaque espace dans Social Home vit sur un foyer : son hôte. Entre foyers jumelés, ça n’a jamais été un goulot d’étranglement. Les publications voyagent directement d’une maison à l’autre, ou sautent à travers le maillage (mesh) des foyers que vous connaissez tous les deux, et l’hôte n’a pas besoin d’être réveillé pour tout cela.

Le chemin via le GFS (Global Federation Server – le serveur de fédération global) — le relais qui aide les foyers à se trouver — était différent. Il transporte un espace vers des foyers avec lesquels vous n’êtes pas jumelé : les abonnés d’un espace global, ou les membres qui ont rejoint un espace privé par un lien. Sur ce chemin, l’hôte devait signer et relayer chaque publication. Si le serveur de l’hôte redémarrait, se mettait à jour ou était simplement hors ligne, l’espace se taisait pour tous ceux qui l’atteignaient via le GFS.

Plus maintenant. Avec Social Home 2026.10.4, les membres publient eux-mêmes leurs publications, commentaires et réactions directement via le GFS, et l’hôte n’a plus besoin d’être en ligne. Le chemin GFS fonctionne désormais comme la fédération directe et le maillage l’ont toujours fait. Il a fallu cinq pull requests et beaucoup de travail sur le protocole, et nous ne pourrions pas être plus contents du résultat. Et le GFS ne voit toujours jamais ce que quiconque publie.

Tout ce qui suit ne concerne que le chemin GFS. La fédération directe de foyer à foyer et le maillage sont inchangés.

Les membres publient pour eux-mêmes

Quand un foyer obtient des droits d’écriture dans un espace, il reçoit désormais en même temps une petite autorisation signée par l’espace. À partir de là, il publie tout seul directement via le GFS ; le GFS vérifie l’autorisation et transmet la publication scellée à tous ceux qui suivent l’espace. L’hôte n’est plus dans la boucle.

Le GFS ne voit toujours rien qu’il puisse lire. Il ne peut pas distinguer une publication d’un commentaire ou d’une réaction — tout arrive sous forme d’enveloppes scellées de quelques tailles identiques. Perdez vos droits d’écriture (retiré, banni, parti, ou restreint aux commentaires seulement) et votre autorisation cesse de fonctionner au même instant. Les foyers sur des versions plus anciennes continuent de recevoir chaque publication, parce que l’hôte continue de relayer comme avant et que les destinataires ignorent simplement les doublons.

Sous le capot

L’autorisation est un certificat d’écriture : la clé d’autorité de l’espace signe {space, key epoch, household key, scope} avec la portée write ou comment — une signature Ed25519 par foyer auteur et par époque, jamais une par publication. Un membre joint le certificat et publie directement ; le GFS le vérifie par rapport à la clé d’espace qu’il a épinglée, puis distribue l’élément aux abonnés sous forme de space_item générique accompagné du texte chiffré. Les charges utiles sont complétées à des tranches de taille fixes (1, 4, 16, 64 et 128 KiB), donc une réaction et une publication se ressemblent. Perdre les droits d’écriture fait tourner l’époque de clé, ce qui invalide l’ancien certificat. Commentaires, réactions, modifications et suppressions voyagent de la même façon et peuvent arriver dans n’importe quel ordre : une suppression qui arrive avant sa publication l’emporte quand même, et les modifications se départagent par l’heure de modification signée par l’auteur.

De confiance ou strict : le propriétaire décide

Le propriétaire de l’espace choisit ce que le GFS peut apprendre sur qui publie.

• De confiance (par défaut) : le GFS voit quel foyer a publié, jamais quoi.
• Strict : les membres publient anonymement. Le GFS ne peut pas dire de quel foyer vient une publication — ni même quels foyers ont le droit d’écrire.

Sous le capot

En mode strict, tous les auteurs partagent une clé d’écriture par époque dérivée de la graine de l’espace. Une publication ne porte ni identifiant de foyer ni signature de foyer ; le certificat d’écriture voyage à l’intérieur du texte chiffré. Les auteurs s’abonnent dans le même lot mélangé que les abonnés, donc le GFS ne peut pas séparer les auteurs des lecteurs.

Les espaces privés peuvent aussi utiliser le GFS

Un espace privé ne touche normalement jamais le GFS : ses membres sont des foyers avec lesquels vous êtes jumelé, et ils se joignent directement ou par le maillage. Désormais, le propriétaire peut activer le GFS pour un espace privé. C’est désactivé par défaut. Une fois activé, toute personne disposant d’un Lien GFS peut rejoindre l’espace sans jumelage préalable, et les membres qui ne sont joignables que via le GFS reçoivent les publications les uns des autres pendant que l’hôte est hors ligne.

Même alors, le GFS n’apprend jamais quel espace il transporte — ni son nom, ni sa clé, ni son contenu. Il apprend seulement quels foyers y participent.

Personne n’est coupé par accident. Tant que des foyers arrivés par un Lien GFS sont encore dans l’espace, désactiver le GFS est refusé, et les paramètres listent exactement quels foyers retirer d’abord. Chaque lien d’invitation affiche maintenant son type : un Lien GFS pour tout le monde, ou un Lien local qui ne fonctionne que pour les foyers auxquels vous êtes déjà connecté et ne touche jamais le GFS.

Sous le capot

Un espace privé avec le GFS activé est représenté sur le relais par un identifiant de canal aléatoire de 128 bits avec sa propre clé, dérivée par HKDF pour qu’on ne puisse pas la relier à la clé de l’espace. Le GFS voit les foyers membres de ce canal, jamais l’identifiant, le nom, la clé ou le contenu de l’espace.

Le GFS en apprend moins que jamais

Tant qu’on y était, nous avons réduit ce que le GFS voit sur toute la ligne :

• Une synchronisation d’espace ne dit rien au GFS. Synchroniser un espace directement avec un autre foyer n’implique plus du tout le GFS, donc il n’y a aucune trace de qui a synchronisé quand.
• Le GFS n’apprend jamais qui a relayé. Les événements d’espace partent sans aucune identité de foyer attachée.
• Le trafic des liens d’invitation est complété à taille fixe. Le GFS voit une taille approximative, jamais la taille exacte.
• Les pannes ne perdent pas d’événements. Si le GFS a un raté, votre foyer continue d’essayer. Les messages destinés aux membres brièvement injoignables sont conservés et envoyés dès leur retour.

Sous le capot

Les synchronisations directes demandaient au GFS un nœud de signalisation que personne n’utilisait ; cet appel a disparu. L’ancienne publication identifiée est supprimée : les événements d’espace partent sous la forme {space_id, event_type, payload} sur une session sans cookie, sans identifiant de foyer. Les enveloppes destinées aux membres arrivés par lien sont complétées à des tranches de taille. Les publications qui rencontrent une erreur du GFS sont réessayées avec un délai croissant (5 s, 30 s, 2 min, 10 min), et le GFS met en file les trames pour les destinataires hors ligne jusqu’à 24 heures.

Se connecter pendant la prise en main

La dernière étape de la visite de bienvenue propose désormais de connecter votre foyer au GFS de Social Home. La case est décochée, donc rien n’est envoyé tant que vous ne la cochez pas. Elle dit en mots simples ce que le GFS vous permet de faire et ce qu’il peut voir, et l’application vérifie qu’il s’agit bien du GFS de Social Home avant de se connecter.

Essayez-le

Tout cela est dans Social Home 2026.10.4. Les foyers plus anciens continuent de fonctionner : sur le chemin GFS, ils se rabattent simplement sur l’hôte jusqu’à leur mise à jour, et la fédération directe est intacte dans tous les cas. Curieux de savoir comment le GFS s’intègre ? Lisez Espaces globaux, ou hébergez un GFS vous-même.