新しいものを表示
のえる さんがブースト
のえる さんがブースト

Elixir由来なところもあるかもしれないけど、ActivityPubのルーズさに対して、不整な値に対するチェックが厳しいのはあるよね。

ちなみにfedibird.comから誰かがフォローしているリモートのサーバの数は4,574あるよ。

単に知っているというだけのトータルサーバ数は40,036。

問い合わせて200を返してくる、NodeInfoを備えた生きてるように見えるサーバが現在19,824。

うち、半分近くの9,683がMastodon系、2,296がMisskey系、1,624がPleroma系、gotosocialは867もありますね。friendicaが305、takaheが57、microblogpubが47、mitraが30、holloが14、gnusocialが12、といった具合です。

写真系では、Pixelfedが354、

動画系では、PeerTubeが935、owncastが141、loopsが1、

ブログ系では、wordpressが2,119、writefreelyが339、plumeが39、

リンクアグリゲーター系では、lemmyが252、mbinが14、kbinが5、

ってところかな。

スレッドを表示

自分の投稿をブーストできないようにする設定といえば、投稿範囲をフォロワー限定に設定ですね。

数えてみたんだけど、fedibird.comは4,125のサーバからフォローされているね。

そのうち、私のアカウントをフォローしているサーバは1,261だった。

私が適当に :pue_pue: って投稿すると、1,261のサーバにCreate Activityが送信される。

リモートのフォロワーは7,363いるけど、各サーバへは代表して一回だけ送れば良いので、17%ぐらいの送信量で済んでるね。

Misskeyのプロキシアカウントは、必要ないときにフォローする動作をやめた方がいいと思うよ。

たとえば、私のフォロワーがそのサーバに既にいて、投稿が相手のサーバに届いているときでも、そこのサーバの誰かがリストに入れただけでフォローしてくる。しなくていいよ。

自分のドメインを指定してあると、本人のアカウントだということ、わかりやすいよね。全然使ってないけどさ\(^o^)/

いまちょっとエラー出てたと思うけど、たぶんなおったのでひっかかった人は再確認よろしく!

のえる さんがブースト
のえる さんがブースト
のえる さんがブースト

サーバ選び? あなたには、ウチのLTLの雰囲気がぴったりじゃないかな!

グループに返信する際、グループへのメンションを先頭にするよう修正しました(WebUI)

今回はgdevはデータベースの問題でロールバック(過去のデータに戻す)を行いましたが、一応動いた状態で対応ができました。

ロールバックで失われる情報も、リモートサーバから補いました。

もしグループのサーバが完全に死んでしまった(壊れたり、サービス終了した)場合でも、過去投稿はリモートの様々なサーバにキャッシュされていて参照できますし、それを元に新しいグループを別のサーバに作って、そこで新たにメンバーが再集結すれば、コミュニティは持続できます。

まあ、まだ自在に引っ越しできる、とまでは言えず、もう少しそのあたりをサポートする機能を充実させる必要がありますが、ともかく、できるということがある程度実証できたかなと思います。

スレッドを表示

今回、gdev.fedibird.comというサーバ上に作られたグループアカウントを、fedibird.comに引っ越しさせました。

MastodonやMisskey、Pleromaには、アカウントの引っ越しをサポートする機能があり、引っ越し先の新しいアカウントに既存のフォロワーを移し替えられます。

つまり、グループのメンバーを、別のアカウントに自動移行させることができます。

だいたいうまくいきましたね!

引っ越し機能(メンバー移し替え)ができなくても、メンバーに新しいグループアカウントを再フォローしてもらえばいいのですが、連絡がつけられなかったり、方法がわからなかったり、めんどうだったりして、離脱するケースも多くなると思います。

過去投稿を移し替えることは現状サポートされていないのですが、こちらは今回は手作業でやりました。fedibird.comにキャッシュされている情報を元に、新アカウントの投稿に書き換えています。

このグループの過去投稿にあたる、グループアカウントによるブーストは、あらためてリモートサーバへ伝播させていませんので、グループの設置サーバ以外では認識されていません。アカウントページを直接見に来る必要があります。

ともあれ、すべての投稿を引っ越しさせることができました。
QT: fedibird.com/@noellabo/1045243
[参照]

のえる  
グループの話(5/5) グループは、連合する、サーバをまたぐコミュニティの構築に活用することができます。 ローカルタイムラインがコミュニティとして利用されてきていますが、その弱点を補うことができます。 Group Actorをホストしているサーバにメンバー管理と配送を依存していますが、投稿...
のえる さんがブースト

グループの話(5/5)

グループは、連合する、サーバをまたぐコミュニティの構築に活用することができます。

ローカルタイムラインがコミュニティとして利用されてきていますが、その弱点を補うことができます。

Group Actorをホストしているサーバにメンバー管理と配送を依存していますが、投稿は参加者のサーバから発信され、参加者のサーバに配送されて保存されていくので、容易には失われません。

また、引っ越し機能でフォロワーを移し替えることで、コミュニティホストを引っ越すことすら可能です。

チャンネルに用いることもできます。これは、自身の投稿のうち、特定の内容だけをフォローしたいユーザーニーズに応え、投稿する側も配送先を使い分けることができるようになります。

複数アカウントの使い分けと比べ、リプライやお気に入り・ブーストが単一のアカウントにフィードバックされたり、メインアカウントのフォロワーに対して全てをまとめて配送できたりするメリットがあります。マルチポストが防げます。

こちらのらりおさんの記事をぜひ。これを実現可能なものです。
blog.cardina1.red/2018/02/25/s

スレッドを表示
のえる さんがブースト

グループの話(4/5)

投稿するActorがGroupへメンションすると、Group Actorがそれを、メンバー(自身のフォロワー)へAnnouce Activityで転送します。これが基本形です。私はこれを、アクティブ方式と呼んでいます。

もう一つ、Group Actorからフォローバックして、ハッシュタグなど特定の条件が揃った場合にブーストする方式も可能で、私はこれをパッシブ方式と呼んでいます。

パッシブ方式は、無意味に多くの投稿をGroupに配送してしまう弱点がありますが、メンションせずにグループに投稿を流せるので、利便性はなかなかのものです。

これらは、既存のMastodonなどのサーバでも十分に機能しますが、サポートする機能を実装することで、より効率良く、使いやすくすることが可能です。

このあたりは、色々とアイデアがあって進めているところです。

スレッドを表示
古いものを表示
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。