#fedibird #fedibird_info グループに返信する際、グループへのメンションを先頭にするよう修正しました(WebUI)
今回はgdevはデータベースの問題でロールバック(過去のデータに戻す)を行いましたが、一応動いた状態で対応ができました。
ロールバックで失われる情報も、リモートサーバから補いました。
もしグループのサーバが完全に死んでしまった(壊れたり、サービス終了した)場合でも、過去投稿はリモートの様々なサーバにキャッシュされていて参照できますし、それを元に新しいグループを別のサーバに作って、そこで新たにメンバーが再集結すれば、コミュニティは持続できます。
まあ、まだ自在に引っ越しできる、とまでは言えず、もう少しそのあたりをサポートする機能を充実させる必要がありますが、ともかく、できるということがある程度実証できたかなと思います。
今回、gdev.fedibird.comというサーバ上に作られたグループアカウントを、fedibird.comに引っ越しさせました。
MastodonやMisskey、Pleromaには、アカウントの引っ越しをサポートする機能があり、引っ越し先の新しいアカウントに既存のフォロワーを移し替えられます。
つまり、グループのメンバーを、別のアカウントに自動移行させることができます。
だいたいうまくいきましたね!
引っ越し機能(メンバー移し替え)ができなくても、メンバーに新しいグループアカウントを再フォローしてもらえばいいのですが、連絡がつけられなかったり、方法がわからなかったり、めんどうだったりして、離脱するケースも多くなると思います。
過去投稿を移し替えることは現状サポートされていないのですが、こちらは今回は手作業でやりました。fedibird.comにキャッシュされている情報を元に、新アカウントの投稿に書き換えています。
このグループの過去投稿にあたる、グループアカウントによるブーストは、あらためてリモートサーバへ伝播させていませんので、グループの設置サーバ以外では認識されていません。アカウントページを直接見に来る必要があります。
ともあれ、すべての投稿を引っ越しさせることができました。
QT: https://fedibird.com/@noellabo/104524341770775395 [参照]
グループの話(5/5)
グループは、連合する、サーバをまたぐコミュニティの構築に活用することができます。
ローカルタイムラインがコミュニティとして利用されてきていますが、その弱点を補うことができます。
Group Actorをホストしているサーバにメンバー管理と配送を依存していますが、投稿は参加者のサーバから発信され、参加者のサーバに配送されて保存されていくので、容易には失われません。
また、引っ越し機能でフォロワーを移し替えることで、コミュニティホストを引っ越すことすら可能です。
チャンネルに用いることもできます。これは、自身の投稿のうち、特定の内容だけをフォローしたいユーザーニーズに応え、投稿する側も配送先を使い分けることができるようになります。
複数アカウントの使い分けと比べ、リプライやお気に入り・ブーストが単一のアカウントにフィードバックされたり、メインアカウントのフォロワーに対して全てをまとめて配送できたりするメリットがあります。マルチポストが防げます。
こちらのらりおさんの記事をぜひ。これを実現可能なものです。
https://blog.cardina1.red/2018/02/25/strongest-dist-sns-i-think/
グループの話(4/5)
投稿するActorがGroupへメンションすると、Group Actorがそれを、メンバー(自身のフォロワー)へAnnouce Activityで転送します。これが基本形です。私はこれを、アクティブ方式と呼んでいます。
もう一つ、Group Actorからフォローバックして、ハッシュタグなど特定の条件が揃った場合にブーストする方式も可能で、私はこれをパッシブ方式と呼んでいます。
パッシブ方式は、無意味に多くの投稿をGroupに配送してしまう弱点がありますが、メンションせずにグループに投稿を流せるので、利便性はなかなかのものです。
これらは、既存のMastodonなどのサーバでも十分に機能しますが、サポートする機能を実装することで、より効率良く、使いやすくすることが可能です。
このあたりは、色々とアイデアがあって進めているところです。
グループの話(3/5)
グループは、ActivityPubによるユーザーの集合の表現で、コミュニティやチャンネルを実現することができる仕組みとして利用できます。
Actorの種類としてGroupが定義されているので、これを用います。
Group Actorを宛先とすることで、Groupに参加しているActorへ間接的にActivityを送ることができます。
(ただし、第三者となるActorがActivityを転送するにはJSON-LD署名が必要で、現実的には投稿と削除ぐらいしか対応していない状況です)
Groupのメンバーを表現する方法はいろいろ考えられますが、Mastodonなどの既存実装との互換性を考えると、Groupのフォロワーをメンバーと見做す実装が現実的であるため、私はそれを採用しています。
グループの話(2/5)
Actor同士が直接やりとりする投稿は、当事者以外、他の人には見えません。
そこで、Activityの宛先として、Publicコレクションという特殊な宛先を指定することができるようになっており、各サーバプログラムでは、これを誰にでも見えるようにしたり、連合タイムラインやローカルタイムラインに流して表示しています。
フォロワー限定やダイレクトが基本形で、公開や未収載が特殊な公開範囲だということです。
また、連合タイムラインやローカルタイムラインはユーザーを探すための場所ですよ、と説明されるのは、こういった事情があるためです。
公開投稿をどのように扱うか(見せ方を工夫するか)は、サーバ次第です。
なお、Activityの宛先には、メールと同様にToとCcがあります。一般に、PublicをToに指定したものが公開投稿、PublicをCcに指定したものが未収載として扱われています。
ここまで、なんとなくつかめましたでしょうか?
グループの話(1/5)
まず、ActivityPubの概要から。
Mastodon、Pleroma、Misskeyは、それぞれまったく異なるプログラムですが、ActivityPubというプロトコルに従ってやりとりすることで、相互接続を実現しています。
ActivityPubをざっくり言うと、Actorが別のActorに対してActivityを送信し、相互作用する仕組みです。
Actorはユーザーのアカウントに相当するものです。通常のユーザーはPerson、botはServiceという種類のActorとして表現されます。
Activityは『投稿を・作った』とか『投稿を・気に入った』『Actorを・フォローする』というようなメッセージです。
Actorは、受け取ったActivity、送ったActivity、フォローしているActor、フォローされているActorなどのコレクションを保持しています。
・ActorとActorがやりとりする
・ActorにPersonやServiceなどの種類がある
・Activityを送り合う
・フォロワーなどのコレクションを保持している
Fedibird方式のグループ紹介です。
グループ機能のテスト用のグループ実験場(playground)があります。
動作試験などを行う場ですが、住み着いている方もおられますw
@playground
https://fedibird.com/@playground
特定目的のグループに参加するのは勇気がいる、ということであれば、ここで試してみるのも良いでしょう。
Fedibirdのグループ機能を用いた、ポケモンのグループ、サンリオのグループです。
過去の紹介とアカウント・URLが変わっています。下記を参照ください。
@pokemon ポケモングループ
https://fedibird.com/@pokemon
@sanrio サンリオグループ
https://fedibird.com/@sanrio
過去の投稿は、URLの方から参照可能です。
QT: https://fedibird.com/@AzumaRinto/109825746352685722 [参照]
グループの紹介ひっぱってきましょう。
こちらはドール同好会の宣伝投稿です。
参加する際、投稿するアドレスが変更になっています。 @doll をフォローして、メンションしてください。
(古いアカウントを参照すると、引っ越した旨、表示がでると思います)
QT: https://fedibird.com/@7ru3___/110644297488694638 [参照]
Fedibirdのグループ各アカウント、移行前の過去投稿を移行しました。
古い書き込みも参照できるようになったよ!
@tell_me_fedi_jp @ishii00141 FedibirdのWebUIで実現するのは難しくないですが、Mastodon本家にPRしても採用されるかどうかは難しいところですね……。まあやってみるか……
@ishii00141 @playground そういう目的のグループだよー
@hanubeki @askyq @tell_me_fedi_jp V1のフィルターは、ホームとリストと通知についてはサーバサイドで投稿データを除外しますが、ローカルや連合など全員共通のパブリックタイムラインでは除外しないので、クライアントサイドでフィルター処理を入れる必要がありました。
V2系はサーバサイドでヒントだけ付与して、どのタイムラインでもサーバサイド除外しないので、クライアント処理を行わないケースでは対応状況が悪化する現象もみられます。(tootleとか)
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。