Mastodonでは長らく、投稿する行為をToot(トゥート)、投稿自体をStatus(ステータス)と呼んでおり、定着しておりましたが、
2021年4月22日に作られたこのプルリクエストにて『Post』に変更することが説明・宣言され、いくらかの議論の後、マージされました。詳しくはプルリクエスト本体のやりとりをみて下さい。
https://github.com/mastodon/mastodon/pull/16080
なお、この時点では投稿ボタンだけは『Toot』という表現が維持されましたが、その後『Post』に変更になりました。
また、用語変更の抜けがあちこちにあったため、その後ちょこちょこ修正が行われました。
ただ、この変更の周知はあまり行き渡らなかったようで、この時期に変更が行われたことのみならず、そもそも変更されたことがいまもって伝わっていないという状況かと思います。(正直、しっかり広報されてはいないと思います)
以上は、ActivityPubの枠内で行われる仕組みについて説明したものですが、
サーバーはinboxに送られてきた新しい投稿が公開してもいいものだと判断したときに、
連合タイムラインという特別な仕組みを用意していて、そこでみんながみられるようにしたり、
同じサーバーのActorが発行した新規投稿のActivityを使って、ローカルタイムラインという仕組みを実現したり、
いろいろとActivityPubの仕組みには存在しない付加機能を提供しています。
サーバーはActorのコレクションを持っているので、他のActorを探す機能を提供することができます。
投稿のハッシュタグをコレクションして、ハッシュタグで投稿を一覧する機能を持たせたりもしています。
ActivityPubにはハッシュタグの共通の表現は用意されていますが、それをどう使うかについては定義されていません。
そのあたりは、ActivityPubで通信する個々のサーバーにより定義され、実装されています。
このActivityPubの規格外の部分は、各実装同士がお互いの機能を理解して、互換性をとる努力をすることで、相互のやりとりを実現しています。
かなり自由だけど、それなりに大変な世界です。
さて、ここまでサーバが説明されていません。存在感ゼロですね!
実は、ActivityPubでは、サーバーを直接表すActorのような定義がありません。
便宜上、サーバーにもActorを割り当てることはありますが、主役ではありません。
とはいえ、サーバーの存在は別の形で表現されていて、効率の改善に貢献しています。
先程のActor毎のinboxがありましたが、この他にshared_inboxという、同じサーバのActorが共有して使うinboxがあります。
このshared_inboxにActivityを送ると、Activityに指定しておいた宛先のActorに対して、相手サーバーに委託してまとめて送ることができるようになります。
「あなたのサーバの、私のフォロワーに対して、Create - Noteしたのでよろしくね!」という感じで、shared_inboxに一回だけ送れば済む仕組みです。
実際の動きとしては、followersコレクションのActorのshared_inboxを調べ、同じものは一つにまとめてしまい、送信件数を最小限に減らしています。
なお、shared_inboxが無い場合は、個々のinboxに送ります。
Actorは、それぞれがinboxというActivityを受け入れる窓口を持っていて、他のActorから送られてきたActivityを処理します。
また、自分が送ったActivityをoutboxに保持しています(ずっと溜まっていきます)。
フォローしているActorのコレクション following も持っています。
フォローされているActorのコレクション followers も持っています。
これは、フォローを要求して、それが受け入れられた時に、お互いがコレクションに追加することで、その状態を維持します。
新しい投稿(Note)をCreateした時、つまり新規投稿時には、followersコレクションのActorのinboxに対してActivityを送ります。
そうすると、フォロワーのActorは、inboxに届いたActivityを処理して、フォロー相手の投稿が読めるようになります。
Activityを発行したActorが、フォロワーに対してそれを送信することで、お互いが繋がるネットワークが実現されています。
MastodonやMisskeyが、それぞれ別々に設置されている違うプログラムなのに、お互いに繋がることができる仕組みは、主に『ActivityPub』という通信規約(プロトコル)によって実現されています。
ActivityPubでは、私たち一人一人のアカウントをActorと呼びます。
Actorは、別のActorと、「フォローしたい」「いいよ」というやりとりをします。
投稿に対して「好き!」って反応したり、新しいノートを「作ったよ」、ノートをみんなに「アナウンス」します(ブースト・リノート)
これらのやりとりの語彙があらかじめ定義されています。
先程の例の順番でいうと、Follow, Accept, Like, Create, Announce というActivityとして定義されています。
Activityは、何を対象とするかを伴っていて、Actorを対象とするときもあれば、投稿(短い文章)を表す表現であるNoteや、「フォローしたい」というリクエストを許可したり、送った側が取り消すために、「フォローしたい」というActivityそのものを対象として指定することもあります。
このあたりの約束ごとが共通化されているため、それに従うことで、お互いのやりとりが可能になっています。
Mastodonの公開サーバを運営していると、警察の照会や捜査・押収の対象になることはあります。(もちろんMisskeyも同様です)
この際、正当な要請であれば捜査に協力します。法的根拠を求めて不当な捜査には抵抗しますが、まぁ強制捜査だとなんともならないことが考えられるので、提供可能な情報は提供されうると考えてください。
Mastodonはほとんど個人のデータを保持していないので、通常の捜査協力ではアクセス日時の裏付けや直近のIPアドレスの確認ぐらいしか提供できる情報はないのですが、
仮にデータベースを持って行かれた場合は、投稿データまるごとに加え、各アカウントの秘密鍵という重要情報が奪われる危険があります。死守したいところです。
VPSはまだしも、自宅サーバが物理で押収しやすいの、ちょっと怖いですね。
当局側が技術に明るければ、という条件付きではありますが、この秘密鍵と発信元ドメインをおさえられると、アカウントの乗っ取りが可能になってきます。大げさなようですが、クーデター・テロ対応など、事案によってはあり得るかもしれません。
なお、サーバが動いている状態、あるいは返却されれば、秘密鍵の再生成を行ってリモートサーバに差し替えリクエストを発行することで古い秘密鍵を無効にすることはできます。
以前に、PawooからFedibirdに移行した人向けに機能紹介したシリーズがあるんですが、普通に誰にでも役立つので、ちょっとまとめて紹介しておきますね。
Pawooから避難・引っ越ししてきた方へ #fedibird のTIPS
https://fedibird.com/@noellabo/109018265650602985
(ドメインタイムライン)
Pawooから避難・引っ越ししてきた方へ #fedibird のTIPS その2
https://fedibird.com/@noellabo/109018354290991395
(投稿の検索範囲の指定・拡大)
Pawooから避難・引っ越ししてきた方へ #fedibird のTIPS その3
https://fedibird.com/@noellabo/109018407720975647
(ハッシュタグ形式の時限投稿)
Pawooから避難・引っ越ししてきた方へ #fedibird のTIPS その4
https://fedibird.com/@noellabo/109019331117835684
(注目のハッシュタグによる投稿のカテゴリ分け)
Pawooから避難・引っ越ししてきた方へ #fedibird のTIPS その5
https://fedibird.com/@noellabo/109028394373269570
(アカウントのプロフィール説明文が検索対象になる) [参照]
𝕏(Twitter)のコミュニティに書いてきたやつ。
--
検索について、ActivityPubそのものには制約があるわけではないのですが、多数のユーザー・運営者を抱えるMastodonが無制限の全文検索を制限する考え方をとっているため、比較的状況としては厳しいです。
https://twitter.com/noellabo/status/1684459545794592768
かつてサーバーを跨いで全文検索を提供するサービスは度々設置されてきたのですが、そうした考え方に反するものとなり、運用費用が馬鹿にならず利益にならないにもかかわらず、非難され、クレームばかりが寄せられるため、次々と消えていきました。
https://twitter.com/noellabo/status/1684459547702992896
いま現実的なのは、misskey.ioのようにローカルユーザーや連合の大きいMisskeyサーバから検索する方法、fedibird.comのように検索範囲を指定できて公開情報が多いサーバから検索する方法、アーカイブサービスのnotestockから検索する方法です。
https://twitter.com/noellabo/status/1684459550467043328
v24.1.0 リリースしました。マルチアカウントフォロー管理機能を追加しました。
v24.1.0 (2023.07.21)
- 「マルチアカウントフォロー管理画面」を追加
- ユーザーのサブメニューの「フォロー管理(マルチアカウント)」から。
- プロフィールの「その他...」⇒「フォロー管理(マルチアカウント)」から。
- その他
#ZonePane
https://play.google.com/store/apps/details?id=com.zonepane
マスク氏「日本はすごい」 日本人のTwitter利用時間に感嘆、1人当たり換算だと“米国の3倍”(ねとらぼ) - Yahoo!ニュース https://news.yahoo.co.jp/articles/c970d4b2bb3670a82307ec04ba957f977905a66d
これ、ほんとにそう。日本社会は冷たい。20年近く前だけど、連合総研から新自由主義の米国社会が如何に問題のあるものか語ってくださいと発表の依頼があった。私は、逆に自由がなく、他人への優しさのない日本の問題を指摘。短いバージョンは朝日新聞にも掲載され、当時ちょっと話題になりました。その頃は、「え?日本って義理人情の社会ですけど?」っていう反応が多かった。
日本人の義理人情って、山下達郎みたいに「義理のある人」の罪や不得は見逃すのが「人情」って意味で、他人に救いの手を出すことではない。日本には、「倫理的に正しいことをする」という普遍的な価値観が欠如しているので、「正義」とか「公正」という概念もない。「人権」感覚が欠如しているのも急遽的には根っこは一緒。私が日本を出ていくことになった理由の一つ。どうしてなんだろう。遠藤周作の『沈黙』のように日本人の精神構造の話なのか、支配階級の操作の成功なのか。
https://news.yahoo.co.jp/byline/iizukamakiko/20211022-00264181
『スレッドについて知っておくべきこと』
Mastodon公式ブログから、Threadsについて説明した記事が出ているので、読んでおくといいよ。
QT: https://mastodon.social/@Mastodon/110664109379249958 [参照]
自治体の業務用機器の購入補助金を申請してみようと思って、パソコンの見積もりとって申請書に記入、先年度の青色申告のコピーとかを束ね、役所の産業振興課の窓口で提出したら、しばし書類を眺めた役人に「パソコンはダメです」と言われた。特化した業務に使う機器でなければダメだ、というので「申請書にも書きましたが私の業務はパソコンを使って特化した内容を扱うことだけなのですが」と申し出たが「でもパソコンは個人的なことにも使えるでしょう、それだとダメなんです」ということです門前払いであった。「だとしたら私みたいなパソコンで情報を扱う人間は補助金はもらえないんですね」と聞いたら、国に聞いてくれ、だそうである。
笑える。旋盤とか機織り機とか田植えマシンとかピザ焼き窯でないとダメなのだな。
Mastodonで全文検索が不便(できない)とお嘆きの方へ
まず、全文検索サーバの設置に金がかかるので、全文検索機能のついてないサーバがあります。mstdn.jpやPawooにはありません。必要な方は、対応サーバを使いましょう。
あと、mstodon.socialなど日本以外のサーバでは、日本語検索が弱いなどの問題もあります。
全文検索サーバがあるサーバでも、自分の過去投稿と、何らかのリアクションを行った他人の投稿だけが対象となります。
未知の投稿を探すことはできません。これはMastodonがわざと設けている制限・仕様です。
Fedibirdおよび同様の方式を採用しているサーバでは、投稿者が検索結果に載せて良いと許可した投稿が追加で検索対象になります。
Fedibirdの利用者は、自分の投稿を検索許可する設定をご検討ください。アカウント単位、投稿単位で変更できます。
なお、ハッシュタグをつけるのも有効です。 #fedibird #fedibird_info
岩永直子さんが退職するエントリーを読んだ人たちに https://anond.hatelabo.jp/20230702201919
続 岩永直子さんが退職するエントリーを読んだ人たちに https://anond.hatelabo.jp/20230702202134
岩永がどれだけひどいかがよくわかるエントリ2本を紹介
Twitterの件。いろいろな話を総合するとWebバージョンのTwitterAPIには昔から消せていないバグがあったんだけど、「何もしなければ」それが顕在化することはないという共通認識が社内にはあったのだが、元からいたエンジニアの殆どを一掃したので、その認識ないままWebのTwitterプログラムを弄ったら、その眠っていたバグが表出し暴れ出したと。
起きていることを簡単に言えばTwitterによるTwitterへのDDoS攻撃だということ。Twitterがセルフで秒間10-15回程度のリロードをかけている。マスク氏が当初、不正クロール対策だと言ってたのはこの挙動が外部からの攻撃だと思っていたかららしい
元Twitterのエンジニア曰く「こうなったら、とにかく弄り始めた最初の段階に巻き戻すかサービスを止めてバグを解消すること。結果としてそれが一番安全で早い」とのことらしいが、傍で見ている限り、マスケのやってることは、迷った道を元に戻ることなく更に走りながら違う道を突き進んでいる様に見える
元々のTwitterの基幹システムってとんでもなく優秀で。世界中にいる桁違いのユーザー抱えても、ここ数年は滅多にシステムダウンすることなくやってきたわけで。でもそのシステムも金持ちの気まぐれで風前の灯となっている