フォロー

サーバ管理者向けにもアンケートしとこう。

過去投稿やお気に入り・ブックマークをインポートする機能について、利用者の立場でどう思うかアンケートしています。
fedibird.com/@noellabo/1042600

さて、問題はサーバ側。

DBやメディア容量の圧迫、モデレーション、偽造、攻撃、他鯖への大量リクエストなどなど、運営する上では課題が山積みです。

さて、あなたは?

こちらも、できるだけリプライでコメントを添えてくれると助かります。

@noellabo やばそうですがたぶん有効にします。そのほうがお引っ越しのイメージにぴったりですし

@noellabo ケースバイケースなので4番目を選びました。
自分の場合、お一人様鯖なら完全有効、不特定多数に公開している鯖なら受け入れるデータを限定する、と言ったところですかね。
インポートを管理者による承認制にして、管理者が負荷をある程度コントロールできるようになるとすれば、管理業務の軽減にも繋がるかも知れません。

@noellabo@fedibird.com
「無理。無効にする」に投票しました。
各種容量の圧迫については運用上どのサーバーでも必ず当たる壁だと思っているので問題ないと思っています。
ですが、偽造、攻撃がクリアできたとしても各種投稿を取得しに行く関係で発生するサーバー負荷のことを考えるとあまり現実的ではないように感じます。
お気に入りに関して、既読感覚でつける人も一定数存在しており、その分インポートする量も多くなってしまうのではないか……と懸念しています。

@noellabo 私の技術力では到底対応しきれそうにありません。

@noellabo 利用者としてマストドンにアーカイブ的な役割を求めていないので、機能を実装することによるサーバ側の負担増ならびにその影響によってサーバが立てにくくなる、多様性が失われる方が問題かなあと思います。

@noellabo 有効にしたいです。単純にすごい機能だし、そもそも自分勝手な超零細鯖だから利用者少ないし……それでもこわいけど、こわいもの見たさもあり

@noellabo@fedibird.com 過去投稿はさすがにヤバいけど、お気に入り(Misskey, =Mastodonのブックマーク)はインポートできていいんじゃないかしら。
リアクションはダメ。(というリアクション-お気に入り周りってMisskeyとMastodonで実はかなり使用違うよなと)

@noellabo ニーズが高そうは機能なので入れたいところではあるのですが…もしそうなったら、具体的な実装を見て判断すると思います。

@noellabo 個人的にはインポート時のサーバー負荷のみを考えてもふぁぼ・ブックマークまでが限界かなと考えています ( それすらも非常に重いと思います ) 。
実装されればユーザーとしてはあった方が嬉しいので使えるようにしますが

@noellabo @souji マストドンに限らず、fediverseの各プラットフォームは機能がいよいよリッチになりつつありますが、個人運営が基本であることを踏まえると、様々な面で負担増が否めません。ただ機能の増加はユーザビリティの面から決して悪いことではないので、ごくシンプルな機能かつ開設・運営が気楽なプラットフォーム(できればおひとり様専用じゃない)があるといいのになと思います。

@noellabo 負荷はすごそうですが、自分は有効にします。
便利そうな機能はできるほうがいい。

@noellabo
ホスティング(masto.host)運用であることと、課題が多いことを勘案すれば、無効にします。
マストドンの過去のトゥートって、そこまで苦労・負荷をかけて公開の場に置いておく価値があるものなのでしょうか。私のトゥートはむしろ数ヶ月経ったら自然消滅して欲しい。それにnotestockのようなサービスもあるし。

@noellabo サーバの運営ポリシーによると思いますが、個人的には気まぐれにサーバを建てて閉じる連中の尻拭いをしたいとは思ってませんし、ただの倉庫にもなりたくありません。

@tateisu 私が真っ先に考えたのもコレで、なんでヨソで作られたデータのコピーをわざわざ受け入れる必要があるのか、と考える方が自然かと思います。裸一貫で来るなら受け入れんでもない、という感じで。

@noellabo どちらかというと、おひとり鯖に引っ越す人間など(いるか?)のためにソフトウェアに実装されていると便利かなとは思いますが、他人のために開放するかというと疑問はありますね。

@YUKIMOCHI 過去を捨ててくるなら良いとして、過去を持ち込むというのは、何かとしんどいですよね。

お一人様の場合は、tootctlなどでインポートするのが現実線かなと思います。ホスティングの場合も(事業者が)対応し易いし。

@noellabo 過去投稿を受け入れる場合、in_reply_to的な物の処理をどうするかというのが問題になるように感じます

@hadsn 様々なサーバ上で生きている、オリジナルの投稿(のキャッシュ)と重複コンテンツになる問題があって、例えば後からリプライを解決すると、同じ内容の投稿が二重にぶら下がったスレッドができてしまい、非常に面倒くさい。

連合先には新しい投稿は反映させず、インポートしたサーバ内だけでそのあたりを解決させるのが、とりあえずせいぜいといったところかと思います。

本格的に対応する場合、権威サーバである元のアカウントからの発信で、フォロワーだけでなく、投稿も同時にMoveさせる必要があるので、Fediverseを巻き込んだ非常に大げさな仕組みになってきます。

考えるべき問題が大きく、issueでの議論もなかなかまとまらないんですよね……。

@noellabo 難しく考えると、引越機能の要件定義から始めなければいけなくなりますね。初期のように引越表示してフォローを謝絶するだけなのか、引越先のアカウントからのフォローを強制許可させたりフォロワーのフォロー先を引越先に差し向ける必要があるのか、それともログを全部コピーして破棄せしめるのか。これら3つの動作のうち1つに限定するのか、はたまた並列して存在させるのか、という問題もありますし

@noellabo 引越機能を使ってまでアカウントを変えるということは、引越元のインスタンスが閉鎖する可能性が高いと考えます。従って前記の2番目の機能だけでなく、任意のインスタンス管理者が閉鎖したインスタンスのキャッシュを削除せしめる操作をしたときに引越操作をしたユーザのキャッシュ削除を阻害せしめる機能は必要なのでは、と考えます。 (ユーザは鯖Bから鯖Cに引越設定を行った。この設定に関わる通知が最低でもフォロワーのいるインスタンスには通知されるものとする。この通知を受け取った鯖Aは、インスタンス管理者が閉鎖インスタンスのキャッシュを削除するよう操作を実行しても、引越先の鯖C及びアカウントが生きている限りキャッシュを削除しない)

@noellabo 必要としている人も多いと思うし、可能な限り有効にしたいですね。
今後いろんな機能や別の対応ソフトが出たとしても同様に重たいものがあるかもしれません。なので個人的には「重たい処理も並行して行える」ような挙動が出来るようになってほしいな、と思います。

@noellabo@fedibird.com
自分の投稿(もしくはフォロワー)のみをインポートするとかなら、トラブルが起きにくい気がします
少量であれば自分(インポート先)にDMとかで送ったりしてますね

ログインして会話に参加
Fedibird

LTLのないFediverse志向の汎用Mastodonサーバです。Fediverseの活動拠点としてご利用ください。