Notices by 白湯さゆぬ (sayunu@mofu.kemo.no), page 5

@tizerm そーねえ :bunhdidle:

シャワーを浴びてて思い至ったんだけど、私の活動場所が束縛されるのは、作る物のほとんどが自宅に据えた iMac に依存するからだわ。実家に長期間帰れないのはそれがあるからだし、仮に会社を退いても漂泊の民になれない。

おはようごす。

ツイッターでもそうだったけど、フォローしながらミュートするという使い方が可能なのが奇妙で、「ミュートするならフォローを外せ」とは前から言ってる。（私に対してそういう人がいるかは分からないし、ミュートしていたら読まれないから伝わらないけど。）

Mastodon の時限付きミュートならまだ意味があるかな。フォローしたまま無期限ミュートして忘却するんだったら本当に意味がない。「フォローしている」という虚構を相手に伝え続けるだけ…。それを目的とするなら趣味が悪い。

フォローしている、またはされているアカウントに対してミュートかブロックが必要と考えられるのは、嫌な返信が繰り返し送られて来て通知に耐えられない場合だけ。私はそういう状況になった事はないので、一度もしてない。そうなったならミュートよりブロックの方がいい（相手に無駄な返信を書き続けさせてあざ笑うのが目的でない限り）。

ブロックして忘却するのは一番怖い。当人にとっては視界から消えた過去の話でも、相手にとっては永続的に有効な妨げなので。相手があなたを思い出す度に「自分をブロックしている人だ」と思ってほしいか、どうか。

〈ミュート〉〈ブロック〉と共通の名前で呼んでもサービスに依って挙動の差があり得る（というか完全模写のサービスでない限りどこか違う）ので、その意味合いは個別に考える必要がある。

Fediverse においては、フォローという操作が…
(a) 投稿を自サーバーに受信しておく
(b) 投稿をホームタイムラインで読む
…という二つの働きを持つから、(a) を目的として (b) が要らないならフォローしつつミュートという使い方はあり得る。

ただミュートっていう機能は相手からの返信を不可視にするので、「返信されても読みたくない、返信があったと気付きたくもない」ひいては「返信が来たならそれを無視したという行動を示したい」というのが動機でないなら、Mastodon だったらミュートではなくフィルターを使うべきだろう。

「使うべき」というか「使えるようにすべき」…。一般利用者の選択肢として存在するわけではないから紛らわしい投稿だった。どうしてアカウントを条件にしたフィルターができないのか謎（これは Mastodon への不満）。

@noellabo あんまり分かってないですが、権限を持つ日本語話者（Yamagishi Kazutoshi さん）が個別に approve した（または古い訳を unapprove した）事で反映されたように見えます。誰も確認せずに採用されるとしたらさすがに怖い。

ていうか〈未収載〉という用語を〈非収載〉に変える提案、意識してなかったけど Mastodon v4.2.1 で取り込まれてますね ? 割と身軽ね、本体機能と違って翻訳は。

#Mastodon

「ここたまアンテナ」、自動化しないと有効に機能しないよなあ。（手動だから私としても自信を持って勧められない。）必要な機能は…

(1) 被フォローに対して自動的にフォローを返す。

(2) 定期的にフォロワー一覧を確認して、フォロー外しに追従する。

(3) フォロワーの投稿のうち特定のハッシュタグを含む物を抽出する。

(4) それをブーストする。

多分、うまく作れば難しい事ではないんだろう。機能 (3) は二つ実現方法が考えられる。

(3a) ハッシュタグタイムラインを見て、投稿者がアンテナのフォロワーである事を確認する。

(3b) ホームタイムラインを見て、ハッシュタグが含まれるのを検出する。

今のところ絶えず監視させるつもりはないので、私が Mac を稼働させている時だけ動くとすると、「見てなかった間」を遡ってブーストする必要がある。Mastodon のホームタイムラインは直近の四百件しか遡れないので、もしアンテナ利用者が大勢になると見切れない可能性がある。…けどホームを見るのが作りとしては楽そう。

ハッシュタグタイムラインを見る方法だと非収載が抜ける事になるほか、複数のタグを監視するので、厳密に時系列順にしたい場合の処理がちょっと面倒という問題がある。

フォロワー各人の投稿一覧を見に行って集めるのが一番確実ではある。

いづれにしても、今の流速ならホーム見とけばいいとは思う。

文脈の続き方が三種類ある。

(1) スクリプト実行環境が継続的に動いてる間

(2) 実行環境を止めてはいないが、計算機本体のスリープなどで処理がお預けになった時

(3) 実行環境を止めてから再び起動するまで

項目 (3) における状態の引き継ぎは、サーバーに情報を保存するようにしたい。「ここまで読んだ」という情報は、非公開投稿にメモするのがいいかも。ブックマークで表そうかとも思ったけど、対象が削除された場合などを考えると複雑だし。

稼働している間、つまり (1) は、例えば五分などの間隔で情報を取得して、次の処理を行う。

・ フォロー一覧をフォロワー一覧に一致させる

・ ホームタイムラインなどを読んでブーストすべき投稿を抽出し、ブーストする

・ どこまで済んだか記録する

これを一度に一斉に行いたくないので、実行環境において「このあと送信する要求のリスト」に積み上げる。順に完了を確認しながら五秒間隔とかで送信する。仮に (2) の中断があった場合は再開後に続きが送信される。

リスト上の要求が片付いてから、状態のメモを更新する。リストの途中で項目 (3) の中断があった場合に巻き戻るけど、再開後に同じ処理をしようとして、ブースト済みならスキップする事にすればいいだろう。多分。

必要な要求は…この辺りか。

フォロワー一覧を見る
GET /api/v1/accounts/[ID]/followers

フォロー一覧を見る
GET /api/v1/accounts/[ID]/following

フォローを解除する
POST /api/v1/accounts/[ID]/unfollow

フォローする
POST /api/v1/accounts/[ID]/follow

タイムラインを見る
GET /api/v1/timelines/home
GET /api/v1/timelines/tag/[タグ]

ブーストする
POST /api/v1/statuses/[ID]/reblog

投稿する
POST /api/v1/statuses

投稿を削除する
DELETE /api/v1/statuses/[ID]

加筆編集の方がいいかしら
PUT /api/v1/statuses/[ID]

昨夜は JavaScript の Promise と async・await について大体学びました。

フォロー一覧とフォロワー一覧を並列に要求する事もできるだろうけど、どうせ同じサーバーに問い合わせるんだし、直列的な書き方でいいやと思った。

#JavaScript

非公開投稿に状態のメモを書く件は、加筆編集を使えば参照が楽そうだけど、無駄に編集履歴が残ってしまうのが気になる。仮に五分間隔で書き替えたら、24 時間で 288 件の履歴になる。それに対して毎回消す方法ならデータベースの中身は定期的に掃除されるだろう。まあ大したデータ量ではないし、動くだろうけど…。

自己紹介の領域を使おうかしら。自己紹介の本文に書き込むのはあまり美しくない。補足情報欄を使うのはマシ。ウエブ画面だと他人に対しては非公開のメモ欄があるけど、あれって自分自身にも使えるのかしら。後で試そうか。

@ara_tsuma この手の反応は本人には抑えるのも難しいですからねえ。結果的に、前よりかわいらしい感じになったんぢゃないかと思います :genbaneko:

どうですかね…使いにくかったらおっしゃってね。一人で勝手に決めてるので全然自信がない。