Né en 2012 sous le nom Redmatrix, Hubzilla renaît en 2015 comme un outil pour créer et relier des petits sites communautaires dans une grande communauté globale. Mais son histoire prend sa source dans Friendica, dans le Safeweb de Symantec, dans un CMS oublié et même dans le Collabra de Netscape.
Voilà pourquoi Hubzilla est une plate‐forme décentralisée de partage de contenu et de réseau social. Elle offre des facilités d’utilisation et d’identification et un socle très robuste pour des fonctions de réseau social (interopérable avec Diaspora, GNU-Social, Mastodon et gérant le chiffrement de bout en bout), de partage de fichiers et de photos (accessibles en WebDAV, à la Nextcloud / Owncloud), d’agenda et de serveur de calendrier CDAV, de carnet d’adresses et de serveur de contacts CardDAV et de wiki. De nombreuses extensions sont disponibles, du jeu d’échecs au partage de fichiers pair à pair via Webtorrent…
Hubzilla est publié sous licence MIT et programmé en PHP/MySQL avec prise en charge de PostgreSQL. La version 2.0 avait été publiée en décembre 2016 et n’avait pas fait l’objet d’une dépêche sur LinuxFr.org. Les principales fonctionnalités de la version 2.6 sont détaillées en seconde partie.
Facilités d’utilisation et d’identification
Identité nomade
Il est possibile de synchroniser plusieurs copies de son profil et de ses fichiers sur plusieurs serveurs, ou de migrer son profil sur un nouveau serveur, de manière transparente pour tous les autres utilisateurs et indépendante des DNS. C’est la fonctionnalité la plus forte de Hubzilla, rendant les utilisateurs libres vis‐à‐vis des administrateurs de serveurs, notamment en cas de rupture de service.
Authentification magique
L’authentification est automatique sur tous les nœuds du réseau (type Single Sign On).
Groupes d’accès et listes de contrôle d’accès
La gestion des groupes d’accès et des listes de contrôle d’accès est compatible avec les fonctionnalités précédentes, et à maille fine pour garder un contrôle aussi fin que possible sur ses données.
Les grands changements de cette version
Cette version marque une évolution décisive dans la gestion des passerelles vers les autres réseaux (principalement Diaspora et GNU-social / Mastodon). Voici un résumé des changements les plus importants.
Changements fondamentaux dans les mécanismes de fédération avec des services externes
Il n’y a à présent plus besoin d’avoir plusieurs rôles de serveur pour communiquer avec des réseaux séparés. Il n’y a plus qu’un seul rôle de serveur (« pro ») qui consolide les fonctionnalités de tous les autres. Note : en conséquence, les « niveaux techniques » sont maintenant disponibles pour tous les serveurs. Si vous trouvez l’interface et le choix de fonctionnalités trop simples à votre goût ou pour vos besoins, rendez‐vous dans vos paramètres de compte et adaptez le niveau technique jusqu’à ce qu’il vous convienne.
Révision des connecteurs pour la fédération
Les connecteurs pour la fédération ont été complètement revus. Le protocole de fédération Diaspora V2 a été implémenté et d’important nettoyage du greffon du protocole Diaspora ont été effectué. La compatibilité avec GNU-Social et Mastodon a été grandement améliorée et une fonctionnalité « récupérer les conversations » a été ajoutée pour tenter de localiser les références contextuelles manquantes et conserver les conversations pour les messages de ces réseaux. De plus, un connecteur pour le protocole ActivityPub est en cours de réalisation.
Possibilité de réorganiser les applications dans le menu des applications
De nombreux changements aussi dans le menu des applications et la barre de navigation ont été effectués pour améliorer l’ergonomie générale.
Mécanisme de partage de fichiers amélioré
Le partage de fichiers a également fait l’objet d’améliorations.
Sélection automatique de la langue
La langue est automatiquement sélectionnée pour l’aide, les pages Web et le contenu des wikis pour les usages multilingues.
Passage des tables MySQL en utf8mb4
Pour les nouvelles installations MySQL l’encodage des caractères est à présent en Unicode complet utf8mb4 afin de gérer parfaitement les émoticônes et les langues asiatiques.
Recherche textuelle améliorée
La recherche textuelle inclut maintenant les pages Web auxquelles vous avez accès. Les recherches par étiquette (« tag ») et par catégorie acceptent les jokers (« * »).
Coloration syntaxique
Le code réalisant la coloration syntaxique des blocs de code a été déplacé dans un greffon. Sans ce greffon un bloc de code normal sera affiché.
Corrections de bogues de synchronisation
Des problèmes de synchronisations des photos et fichiers vers les clones ont été identifiés et corrigés.
Gestion du téléversement des gros fichiers
Il est désormais possible de téléverser de grands fichiers (comme des vidéos) directement dans les conversations. Il y avait des limitations liées à la mémoire disponible auparavant.
Gestion des commentaires publics
Les canaux (l’identité de base dans Hubzilla) acceptent les commentaires publics de personnes non enregistrées (comme sous Wordpress).
Transfert des greffons CalDAV/CardDAV au cœur du serveur
Le code des greffons CalDAV/CardDAV a été transféré vers le cœur du serveur afin de faciliter l’intégration avec le calendrier et le carnet d’adresses intégrés.
Mise à jour de Bootstrap
C’est la version 4 bêta de Bootstrap qui est à présent utilisée.
Installateur amélioré
Le programme d’installation a également fait l’objet de quelques améliorations.
Pour la liste complète des nouveautés voyez le journal des modifications.
Appel aux traducteurs francophones
Le projet manque de traducteurs francophones, notamment pour les pages d’aide, qui ne sont pas gérées sous Transifex (outil de traduction en ligne pour les applications basées sur gettext). La traduction française de l’interface (hors aide en ligne) a été mise à jour dans Transifex, mais au moment de la rédaction n’a pas encore été intégrée dans GitHub. Cela devrait être fait dans les heures ou jours qui viennent.
Aller plus loin
- Hubzilla sur GitHub (340 clics)
- Site Web du projet (781 clics)
- L’histoire du projet (103 clics)
- Annonce initiale (76 clics)
# Identité nomade
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
C'est un projet très intéressant, et un que je n'ai pas encore testé moi même bien que j'en entende parler depuis plusieurs années. Je viens de regarder la démo vite fait, c'est complet.
Au sujet de l'identité nomade, je me pose plusieurs questions :
D'autre part, est-ce qu'on a une idée du nombre d'utilisateurs ? Est-ce qu'il y a un modèle économique ? Comment c'est développé (prise de décisions) et par qui ?
Bon courage, il faudra que je prenne le temps de regarder ça de plus près un jour.
[^] # Re: Identité nomade
Posté par gouttegd (site web personnel) . Évalué à 4.
Je ne suis pas utilisateur et je ne connais pas assez bien le projet pour répondre à la plupart des questions, mais sur celle-là :
ce que je peux dire est que Hubzilla représente environ 6% des nœuds connus de ma propre instance Friendica (128 nœuds sur 2244, précisément). Évidemment, ce n’est pas forcément représentatif de l’ensemble de la Fédération, c’est seulement ce que voit mon serveur…
Pour information, la Fédération vue depuis mon serveur, c’est précisément :
[^] # Re: Identité nomade
Posté par Papey . Évalué à 6.
Merci aux modos pour la passe de rédaction / mise en forme complémentaire !
Comment contacte-t-on quelqu'un qui peut être sur n'importe quel serveur ? Il y a un hash ou quelque chose compliqué, ou une astuce ?
Un "canal" est identifié par sa clé privée. Cloner un canal revient à copier la clé privée sur un autre serveur et à ajouter la nouvelle adresse à la liste des clones du canal, qui est envoyée à chaque contact.
Je suppose que oui mais je demande par acquis de conscience : les données sont chiffrées en cas de duplication ? Si je mets une identité sur plusieurs serveurs, ça ne veut pas dire que tous les admins de ces serveurs ont accès à mon nom, ma liste de contacts, mes messages, etc ?
Tous les transferts entre serveurs se font de manière chiffrée. En revanche sur les serveurs les admins ont par définition accès à toutes les données, chiffrées ou non, et aux clés de déchiffrement (clés privés) qui sont stockées en base. En ce sens la distinction chiffré/non chiffré a peu de sens vis-à-vis des admins. Finalement seuls les messages chiffrés de bout en bout échappent à cette règle. Ils sont stockés chiffrés, sans la clé. La clé de chiffrement doit être rentrée à la main dans le navigateur pour déchiffrer chaque message. Avoir confiance en l'admin est globalement un postulat de Hubzilla. Mais ceci est vrai pour tous les systèmes ne généralisant pas le chiffrement de bout en bout.
Du coup si les admins n'ont pas accès (ce que je suppose), est-il possible de dire qu'on ne veut pas de quelqu'un ?
Chaque administrateur de hub peut choisir le mode d'inscription à son hub. Sur un de mes hubs je n'ai qu'un compte : le mien. J'ai activé l'option pour valider explicitement toute nouvelle inscription, pour le cas où je voudrais ouvrir un compte à des amis ou de la famille, ou autoriser à créer un clone sur mon hub.
Et bien sûr j'interagis avec tous les hubs de manière transparente, comme si les autres utilisateurs étaient hébergés sur mon serveur (principe de la décentralisation). Seule nuance : le partage de fichiers entre utilisateurs. Autant mes propres fichiers sont clonés entre les serveurs sur lesquels j'ai décidé de répliquer mon canal ou mes canaux, autant le partage de fichiers tire profit du SSO et des ACL : à partir de mon canal "toto@titi.org", je peux donner accès au fichier "chaton.mp4" à "bidule@tata.be", en lecture seule, lecture/écriture… Ainsi je n'ai pas besoin de transférer mon fichier, "bidule@tata.be" se connecte directement en SSO à mon fichier. Je garde ainsi le contrôle si je veut un jour modifier les accès ou supprimer le fichier.
Quid de la place aussi, est-ce que dupliquer une identité ça prend beaucoup de place ? Si j'ai des albums photos, des vidéos, etc., est-ce qu'ils me suivent ?
Tout suit par défaut. Ca fait longtemps que je n'ai pas créer de clone, il faut que je vérifie si on peut choisir de ne cloner que la partie "données en base".
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 21 août 2017 à 19:21.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Identité nomade
Posté par Papey . Évalué à 2.
La clé privée du canal est utilisée principalement pour l'authentifier auprès des autres canaux indépendamment des DNS. C'est la clé de voûte de l'identité nomade. Elle n'est utilisée pour chiffrer que dans le cas des messages privés de canal à canal (une des applications de Hubzilla). Il ne s'agit pas dans ce cas de chiffrement de bout en bout, la clé étant stockée sur les serveurs. Les autres types de messages quant à eux sont chiffrés en SSL avec les clés des serveurs uniquement. Si la charge utile est un message chiffré côté client, on a un chiffrement de bout en bout.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Identité nomade
Posté par Papey . Évalué à 2.
La clé privée n'est répliquée que dans le cas du clonage, qui est un mécanisme de redondance global des informations d'un canal entre les serveurs choisis par le propriétaire dudit canal. On peut très bien n'héberger son canal que sur un ou des serveurs à soi, sans divulguer la clé privée à qui que ce soit. Seule la clé publique est diffusée aux contacts/amis. La clé privée est utilisée pour signer tous les envois mais pas systématiquement pour le chiffrement.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Identité nomade
Posté par Papey . Évalué à 4.
Pour ce cas d'usage il y a les réseaux P2P comme retroshare. Hubzilla fait le choix de tourner sur un serveur afin de rendre les données disponibles et synchronisables même quand le poste client de l'utilisateur est éteint. Le projet postule raisonnablement que l'on peut avoir confiance en l'administrateur du serveur, au besoin en administrant son propre serveur. Le cas d'usage est de partager des messages et plus généralement des données avec sa famille, ses amis, ses communautés, sans être soumis à la surveillance de masse des états et des multinationales d'internet et à la pub.
Cela exclut le cas d'une surveillance ciblée, où les attaquants bien financés auront plus vite fait d'exploiter un zero day ou une backdoor de chipset intel indétectable par l'OS pour installer un keylogger et contourner ainsi tout chiffrement, voire de poser des mouchards physiques au domicile de la personne surveillée.
Bref, pour les problématiques de vie ou de mort type dissidence politique ou militantisme radical au sein d'un pays soumis à la censure et à la dictature, Hubzilla n'est pas recommandé et ne cherche pas à pouvoir l'être.
Hubzilla reste plus sûr et plus polyvalent que Diaspora ou Mastodon du fait de l'identité nomade : si on ne veut pas cloner son canal on peut en faire un export json local, et en cas de rupture de service du serveur qui hébergeait le canal charger cet export sur un autre serveur. Les cas de serveurs "tombant" pendant des semaines ou des mois ou fermant définitivement ne sont pas anecdotiques, sur n'importe quel réseau social décentralisé. Hubzilla permet une résilience complète vis-à-vis de ce problème, et offre des fonctionnalités supplémentaires de CMS, de CDAV, CardDAV, WebDAV que les autres ne proposent pas.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0. Dernière modification le 22 août 2017 à 19:25.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Identité nomade
Posté par Papey . Évalué à 4.
Toujours un plaisir d'échanger :-)
Le chiffrement de bout en bout empêche toute fonctionnalité de recherche et d'indexation par mots-clés, qui permettent de retrouver/regrouper des messages dispersés parlant d'un même sujet. Au final cela nuit quand même au partage et à la collaboration, même si cela apporte un gain (jamais absolu) en termes de sécurité. C'est une question de position de curseur au final.
[^] # Re: Identité nomade
Posté par Papey . Évalué à 2.
En complément, un canal est identifié par son ZID (identifiant Zot) de la forme bli@blo.xx. Ceci permet d'utiliser une sorte de webfinger sur le serveur blo.xx afin d'obtenir la clé publique associée au canal et la liste des clones éventuels.
[^] # Re: Identité nomade
Posté par cb17 . Évalué à 0.
Je donne quelques réponses pour la confidentialité des données. Evidement l'admin du serveur peut tout voir sur nos données. Il faut faire confiance à l'admin ou bien s'autohéberger.
En cas de synchronisation, beaucoup de données sont synchronisées et certaines sont en clair dans la base de donnée.
A part cela, c'est quand même un outil qui va trés loin dans le sécurité, la confidentialité et l'anonymat.
Ce que je note sur les derniers changements c'est
l'implémentation de ActivityPub : c'est le premier a le faire. Je fais confiance au dev qui le dit car je n'ai pas testé. Mastodon est en train de l'implémenté, gnusocial aussi et d'autres vont suivre. C'est le futur standard.
On peut partager avec un simple lien un peu à la manière de nextcloud pour nos contacts qui n'ont pas de compte. Trés utile car qui a un compte hubzilla ou même mastodon ? Trop peu de monde. Moi je l'utilise pour partager des photos avec ma famille. De façon publique ces photos ne sont pas visibles mais avec un lien spécial oui. C'est un bon compromis entre facilité et hyper sécurité.
# Noms des fichiers avec des caractères spéciaux
Posté par GG (site web personnel) . Évalué à 6.
J'apprécie que le nom des fichiers avec des caractères spéciaux ne soient pas tronqués. Si j'envoie un fichier avec des caractères chinois dans le nom, il est renvoyé tel quel dans l'url quand on voudra y accéder plus tard.
C'est assez rare pour être souligné.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.