高度で先進な機能を有する分散型SNSのHubzillaの決定的な問題点が見えてきた
HubziilaのアカウントはHubzillaサーバへアクセスするための認証情報でしかなく、一般的なSNSで言うユーザ情報としてのアカウントはアイデンティティと呼ばれる。
これは丁度、SSHなどでサーバへアクセスする認証情報と実際にリモート先で作業するユーザ情報は別個のものであるというのに似ている。
アイデンティティはすべてのHubzillaサーバで共通的に使われるユーザ情報であり、ユーザhumanアイデンティティが投稿した情報はfoo.hub.comへアクセスしてもber.hub.netへアクセスしても閲覧できる。
Hubzillaは高機能でありアドオンを導入することでActivityPubへ対応可能で、例えばMastodonからリモートフォロー出来るが、Hubzillaの検証を続ける内に1つの欠点が判った。
(続く)
高度で先進な機能を有する分散型SNSのHubzillaの決定的な問題点が見えてきた
判ったことはActivityPubへ指向するリモートフォローは、例えばhuman@foo.hub.comをリモートフォローしてもhuman@ber.hub.netはリモートフォローされないことだ。
これの何が問題かと言えば、Hubzillaの最大の特徴はfoo.hub.comが何らかの理由によって停止しても、アイデンティティへ指向したユーザの投稿情報はber.hub.netへ同期され、foo.hub.comが停止しててもber.hub.netへ簡単に退避出来ることにある。
HuibzillaのデフォルトであるZotプロトコルであれば、humanアイデユティティをフォローしていればfoo.hub.comにhumanが移動しようがber.hub.netに移動しようが関係なく、そのまま引き継がれて投稿を読める。
しかし、ActivityPubはhuman@foo.hub.com、そしてhuman@foo.hub.comという絶対値へ指向しないとリモートフォローは出来ないのだ。
(続く)
高度で先進な機能を有する分散型SNSのHubzillaの決定的な問題点が見えてきた
つまり、Hubzillaに居るhumanを逃さずActivityaPubリモートフォローしようと思うとhumanがバックアップしているすべてのHubzillaサーバをリモートフォローしなくてはならなくなる。
これはActivityPubユーザからすると非常にコストが大きいことで、Hubzillaユーザとは繋りにくいという印象を持ってしまう。
結局、Hubzillaのアイデンティティという良さを活かすには同じくHubzillaでアイデンティティを持つしかないということになる。
Hubzillaに取ってこれは非常に大きな欠点だ。
もちろんサーバへの認証情報とユーザ情報が紐付いたアカウントも持つActivityPubの欠点でもあるのだけれど。
