Notices by のえる (noellabo@fedibird.com), page 3

ベアナックルのカップルって何だろうって思ったらペアルックだった

（アクトレイザーの話題を見たせいだな……）

@weepjp ほら、外部リンクにクッションページ挟むじゃん……？（つらたん）

@weepjp 先日、Pixivもそれやってくれないからリンク貼っても緑にできないって話があった。普及して欲しいねえ。

#fedibird も非常に変わったサーバですが、

Mastodonではmastodon.socialがあり、mstdn.jpがあり、pawoo.netがあり、best-friends.chatがあり、

あるいはMisskeyやPleromaの様々なサーバが無数に存在することで、

私たちも、独自の方針のもとで運用することが許されていると考えています。

それぞれが受け持つ責任の範囲をできるだけ小さく保ち、それぞれのありかたを認め、気に入らなければ自分で作り、連合したりしなかったりすることで、うまくやっていこうというのが、分散SNS流のやり方です。

中央集権的な体制・考え方で実現できていたことが、ここではできないことがあります。

全てを知ることや、全てをコントロールすることはできません。

一つのサーバに全てを求めないことです。

企業のFediverse参入だけど、自社運用するかどうかは、mastodon.socialなり、まあ日本だったらfedibird.comでもいいけど、どこかに場を借りて、いろいろ見極めてからでいいんじゃないかな？

その上で、

・公式側からrel="me"によるリンクを貼って、対外的に公式アカウントを確認できるようにする

・プロフィールから公式のrel="me"リンクしているページにリンクを貼り、緑色の認証状態にする

だけはやっておく。

最近流行ってるWebFingerもありかな。

もし自社ドメインで運用するなら、信頼とブランディングの為にやるんだから、未経験で始めるのは避けた方がいいと思うよ。

しっかりアドバイザーがいるとか、もう勝手がわかってるなら、初手からどんどんやってもらいたいけど。

■ FediMovie Social 開設のお知らせ

従来より提供しておりますFediMovieの関連サービスとして、FediMovie Socialを開設しました。
https://social.fedimovie.com/

今後、社会的な関心（Social）を扱う動画についてはこちらに投稿していただき、

従来のFediMovieを、趣味や個人的な活動を中心とする内容に限定することで、

トーンの異なる双方の棲み分けを図ります。

FediMovie Socialで扱うジャンルは、PeerTubeのプリセットの

・アクティビズム
・ニュースや政治
・人物
・教育

などが主に該当します。

一方、現行のFediMovieは、

・食べ物
・音楽
・芸術
・科学やテクノロジー
・旅行
・エンターテインメント
・ゲーム
・コメディ
・スポーツ
・ハウツー
・乗り物
・動物
・子ども向け

などそれ以外のジャンルを受け持ちます。

なお、二つのFediMovieは、それぞれ異なるサーバとなるため、それぞれにユーザー登録が必要となります。

@ai18n @dansup 宛でいいんじゃないかな？

:mastodon_oops:

Mastodon名物の、ばんばんするやつあげとくね

@moriteppei 望まぬ相手にみられる面倒くささを大幅回避できるのと、同質集団とみなされずに済む、っていう2点かな。

#fedibird にはローカルタイムラインがないので、どんな人が登録しているか全然みえないし、気付きもしないっていう特徴がある。

だから、荒れてるとか、特定傾向の人が多いとか、考えなくて済む。

でも、連合タイムラインにはみんなと混ざって表示されるし、

連合タイムラインはfedibird.comの人たちがフォローした相手が相当な割合で含まれるので、もちろん影響を受けている。

いくつかのリレーに参加しているので、まったく誰もフォローしていない投稿も表示されるし、公開の投稿をすれば他のサーバにも流れていく。

分厚い連合の流れがあって、その中から購読する。

キーワードやハッシュタグでみつけてもいいし、サーバー単位で購読してもいい。

公開で投稿すれば遠くまで届きやすく、公開範囲を絞れば静かな空間を維持できる。

Fedibirdは、連合するFediverseに参加するタイプのサーバ。

そんなに難しい話じゃなくて、

人間の欲望を全部形にしたら、素敵なSNS空間にならないからですよ。

金や力にはなるかもしれませんが。

#fedibird フォローの代わりに、アカウント購読を試してみませんか？

アカウント購読はフォローと似ていますが、以下の点が異なります。

* 購読は相手に通知されません
* 購読していることは、相手が知ることはできません
* 連合タイムラインに流れている、公開投稿だけを受け取ります
* フォローに承認が必要なアカウントを、承認不要で購読できます
* 購読を解除しても相手に通知されません
* 何を購読しているか、いくつ購読しているか、他の人に見えません
* 購読者へは配送が不要のため、サーバとネットワークの負荷が軽い

このことにより、

* フォローにともなう、相互関係・人間関係への配慮が不要です
* 未収載・フォロワーのみなど、相手が積極的に公開していない投稿を目にせずに済みます
* 承認が必要なアカウントを無理にフォローしなくて済むので、お互い楽に運用できます
* サーバやネットワークにあまり負荷をかけずに済むため、遠慮なく購読を増やせます

お薦めの使い方

* 最初は購読で始め、関係が深まったらフォローに移行する
* 興味を持ったら、まずは購読して、あとで整理する

@moriteppei フォロワーの移動って、仕組みとしては大がかりなんだよ。

フォローって相手側が主体になる行為だから、こっちの移動を知らせて、それにあわせてフォロー先を変更するって、分散SNS上のいろんなサーバやプログラムが協力しあって初めて実現してることで、実現不可能じゃないか？ っていうレベルの話。（だから未対応もある）

最初から規格化されていたんじゃなくて、Mastodonで長期的に取り組んで、ようやく実現できたもの。

ま、利用者にとっては関係のないことだけどね！

@moriteppei 引っ越し機能は、新アカウントに旧アカウントのフォロワーを移動させて、旧アカウントに引っ越し済みフラグを立てるものです。

引っ越し済みフラグがたつと、このアカウントはこちらに引っ越しましたよー、って表示がでて、更新できない状態になります（復活させられます）

元のフォロワーは、移動しちゃうので消えます。が、移動に対応してないフォロワーは残るので、引っ越し処理が完了したらチェックして、残った人達にはお知らせするといいでしょう。Misskeyの人とかついてこないので。

フォローについては、自分でエクスポートして、新アカウントでインポートします。手動です。

引っ越しはフォロワーを移動しない選択もあります。フラグだけ立てる奴。

フォローインポートすると、フォローバックしてくれる人もいるので、それで済ませちゃうっていう。

@ichikawathrives @moriteppei 持って行けないのだ。いつかサポートするけど、いまはむり！ 元のアカウントは引っ越し状態のままのこしておいて、それを参照すること。あと、更新止めたらエクスポートしておく。アーカイブ保存できるので、いつかインポート対応されたらその時に実行する。

mstdn.jpほんとよく動いてるなあ。500がポコポコでるとしても。

このあいだまでアクティブ4,000人ぐらいだったんだよ（WAU）

先週、56,285人よ。ウチなんて14,534だから、4倍近くだよ。Pawooだって16,055なんだよ。

asusは、asusはなんてよむの！！

さきほどのDMの話とも関連しますが、

フォロワー限定の投稿を安心して運用するために、フォロワーはよく選んで下さい。

特に、FollowBotやGhost、素性の怪しいアカウントに注意してください。

FollowBotやGhostは、あなたをフォローして投稿を集めます。

この時、公開している投稿だけを収集するのであればまだいいのですが、フォロワー限定の投稿も一緒に収集しています。

一見するとBot自体は無害に見えるかもしれませんが、受け取ったサーバ側で悪用されることもあります。Botの所属サーバも判断材料です。

素性の怪しいアカウントは、身分を隠したストーカーかもしれませんし、保護者や学校の先生かもしれませんし、国家の捜査機関かもしれません。

FedibirdではBotフラグのついたアカウントはフォローリクエストになってワンクッション入りますが、Botが必ずBotフラグをつけているとは限りません。

全部公開で投稿するつもりの人はあまり気にする必要はないですが、肝心なときにフォロワー限定が機能しなくなることは留意しておきましょう。

それから、FediverseはMastodon以外の様々なタイプのサーバがあり、DMに相当するものをどう扱うかは未知数です。

Pleroma、Misskeyなどよく知られたサーバであれば期待通り扱ってくれることが期待できますが、

最悪の場合、管理者が任意に閲覧できるサーバであることも、誰でもみられる状態で受け取るサーバも考えられます。

先に悪い改造と申しましたが、見えるように改造されていた場合は、これを防げません。

従って、宛先に指定するサーバが信頼できるかどうかも考えなくてはなりません。

よく知った相手のサーバは多分大丈夫だろう、ぐらいの判断は可能かと思いますが、まぁ知らないサーバのことは判断できませんよね。

またこれは別の問題ですが、添付したデータ（画像や動画）はURLが漏洩すると誰でも参照できます。

また、オブジェクトストレージに保管していることが多いため、AWSだったりWasabiだったりに監視されることもあります。

また、添付データ（画像や動画）をモデレーション対象とするサーバもあります。

というわけで、

まあ最悪漏れてもいい内容までにしておきましょう。

DMの内容が当事者以外にみえるケースですが、

まず、そのDMの発信元か配送先であることが必要です。

DMを送信した人のサーバと、宛先に指定した人のサーバ（複数）のデータベースに内容が記録されます。

無関係のサーバからはみえません。

それから、DMの当事者の誰かがこれを通報した場合、通報の宛先となったサーバの管理者およびモデレーターがこれを確認できるようになります。

（悪い改造がされていなければ）管理者やモデレーターはMastodonの操作を通じてDMをみることはできません。

ただし、データベースに直接アクセスできる人は、DMの内容を取り出して見ることができます。

これは主に管理者が該当しますが、技術担当が別にいる場合や、ホスティングで委任している場合もありますので、ケースバイケースです。

このほか、警察や軍など司法・国家機構からデータベースを明け渡すよう求められたり、クラッキングによりデータを盗まれるケースもあります。

こうした場合に、サーバ上に鍵が存在しない方法で暗号化されていれば内容は読めないのですが、平文で保存されておりそのまま読める状態になっています。