@tizerm 見てから考えるのと、二次創作でないなら別に構わんし…。

@daibaka 早速貼っときました。絵が用意できたらまた考えましょう。

〈unlisted〉だけでなく全部考え直すと、こんなのはどうでしょうか。
Public — 全体発信
Unlisted — 非掲示発信
Followers only — フォロワーのみ許可
Mentioned people only — 言及した相手のみ許可

寝坊しつつ移動中。

Mastodon（サーバーソフトウエア、本家）の開発がどれぐらい活発なのか（フォークやカスタム‐CSS の追従がどれぐらい忙しいのか）把握してない。「はやってから六年も経ってるし」そろそろ結構安定してきたんぢゃないのという期待を持っていたけど、フロントエンドだけ見ても結構ツギハギがあるし、どこかでまだ大きく変わりそうな予感もある。（開発ロードマップとかは見てない。）

「把握してない」「見てない」というのは「後で調べとこ」という意味です。

@noellabo ありがとございます。出先なので夜に見たいです。

「リモートを見に行け」という今の作りを取りあえず受け入れるとして、同じ操作を表す言語表現が「リモートで表示」だったり「元のページを開く」だったりまるで揃ってないのがすごい。

月一回の出社が済んだので、家に移動中です。在宅勤務を少しするけど、長引かせないようにしたい。

古い知り合い向けの年賀状（春の挨拶状）を作るのと、ほぼ完成してるフォントの更新版を頒布まで持ってくのと、それ以外の絵を描くのと、放置している自サイトを拠点として今一度整備するのをやりたいです。

警告付きの投稿の「もっと見る」「隠す」のボタンを前方に移動してみました。不便だったり不自然だったりしたらお知らせください。

警告文が長大な場合にあまり美しくないな。（そもそもここに長文を書くべきではないと思うけど。）本当はボタンを先頭に float させたいけど、本来文末に配置されてるから、文書構造上の順序を変えないと難しい。

確かに、Aethy では添付画像も警告文の奥に隠されてる。普通の Mastodon では文章だけ隠され、画像は初めから見えてる。

ぜるまくんがアカウントを取ったマストドンサーバー、私がこの前作った概念図と一致度高くなったのが面白いな。Pawoo と mstdn.jp とボカロ丼。まあ目立つ例を集めたから自然ではある。

この図、文字が小さかったなあと反省しています。個々の絵文字の表情は読み取る必要がなく、文字情報を読む方が重要だから、大きさの比をそれに整合させるべきだった。
https://twitter.com/sayunu/status/1616288466698121216

多数のサーバーが自由に繋がるという基本的な理解を助ける為に作った図であって、サーバーの具体例は規模や知名度といった観点で選んだ。ツイッターで若干リツイートされたけど、彼らに「2023 年にお勧めのサーバー」を伝える事を目的にするとしたらちょっと違う物を選定しただろう。

@daibaka サーバーの説明に全体的に加筆しました（一枚目）。従来のは二枚目。履歴は手元にも保存してあります。

大きな変更点として、
・ Masto.host についての説明を追加しました。
・ マスコどんがどういう観点で もふけものと結び付くのか文を追加しました。
それと、全体の調子を揃える為に「様」を削るなど言い回しに手を加えた所があるけど、だいちゃんが「自分の言葉ではない」と違和感を覚えるようならまた弄ってください。

@daibaka ルールも全体的に再編成しました。まづい所があれば言ってください。主な観点は…
・ 楽しい気分の時以外も使える方がいいなあ。
・ 私も人に迷惑を掛けるし、それが駄目だと厳しいなあ。
・ 一応、隠蔽処理の基準を示しておこうか。
・ 日本語以外を書くのは許すけど、運営者と日本語で会話できないのは困る。
・ 所在が国外であるという話はルールにならないので、サーバー説明の方に書いた上で削ろう。

おはぽよ。

@daibaka 👍

もふけもののサーバーはフランスに在るらしいので、我々はフランスに滞在中 ?

マストドンのハッシュタグ検索は複数条件を組み合わせたりできないから、ツイッターの「#\絵 from:sayunu」そのものはないけど、プロフ画面の「注目のハッシュタグ」から開けば同等の検索範囲になるのね。URL は
https://mofu.kemo.no/@sayunu/tagged/%E7%B5%B5
となる。

プロフの設定で「注目」として掲出してないハッシュタグも、同じ形式の URL を呼べば当てはまる投稿の一覧が表示される。

分散と連合を重視する思想だと、「人が多い所に行く」という発想がそもそもないのだわ。

しかし使ってみるとサーバーを跨ぐ操作は若干複雑だし、まだ Mastodon は分散の思想を不完全にしか実現していないと思う。

個別の機能を実装していくのはバラバラのコミットでいいけど、一貫した UI というのは一旦全部を見ないと作れないよね。（Mastodon の開発の履歴を眺めて思った）

@tizerm 実に良くない。プロフを開いたら情報を取得して来るべき。

「個別に作っていけば、最終的にこのように はまる」と全体を予めデザインしてからバラバラにコミットするという行き方はある。

リモートから飛んで来るお気に入りとかを見るに、恐らく連合タイムラインを見てる人が結構いる。賑わっているサーバーで少なくとも一人からフォローされているというのがやはり可視性に大きく関わるなあ。零人と一人の差が大きい。

前も触れたけど、連合タイムラインには「自サーバーの誰かが採用したフォロー先」というキュレーションが効いてるから、自サーバーが「趣味のいい人々」の集まりだったら高品質になり得る。

ローカルタイムラインの意義という面でも、どのように人々を区切ってサーバーに収めるかが実は体験に大きく関わる。もし「どのサーバーでもいいんだよ」と勧めるなら、ローカルタイムラインと連合タイムラインを使わないという前提が要る。

いや、しかし連合タイムラインなどを「使う」事に関する体験は、本質的には所属サーバーの問題というより、やはりユーザーインターフェイスの形の問題なんだ。各サーバーのフロントエンドは「自サーバーの持っている情報しか出さない」という作りだから、よそのサーバーの連合タイムラインを見るには別の窓口に行かないといけない。それは必然ではない。

よそのサーバーが受け取っている連合タイムラインを見る権限を、私が持っていないわけではない。ただウエブ画面の右側のメニューにないだけ。

作りとしては、よそのサーバーのタイムラインは最新情報のプッシュを貰えないという違いがあるわけか（多分）。手動で、または定期的にプルする事になる。

XMLHttpRequest で任意のサーバーから連合タイムラインを取って来るのは簡単にできるので、その方向で作り込めば「自分の属するサーバー」とは関係のないマストドンブラウザーが出来そう。
https://twitter.com/sayunu/status/1622901519774552064

既存アプリにどんなのがあるか把握してないですけど。既にそういうシ組みはあるのかしら ?

そう言えば XMLHttpRequest っていう古びた機能ではなく最近は色々あるらしいんですけど、この前ちょっと fetch というのを使ってみたらあんまり便利に感じなくて XHR に書き直したという経緯があります。使い方が悪いのかな。JavaScript の非同期処理の流れとかは従来の考え方が定着してるので、その中でやる事に不自由を感じないというか…。

複雑な事をやろうとすると便利になってくるんだろうなとは思った。私は単純な事しかしないから…。

ハッシュタグ「絵」のタイムラインも取れた。見せ方次第では複数のサーバーから取って来た情報を一つのタイムラインに流し込む事もできるだろうから、かなり便利な気がする。

最古のローカルタイムラインが表示されて感動しています。
https://mofu.kemo.no/api/v1/timelines/public?min_id=0&local=true

もふけものの概要に「そもそもマストドンとは何か」を短く分かりやすく書いておくと有意義な気がします。

@mo_so_shitekara 入れるっていうか、他サーバーの人をフォローする事はできますよ。

@mo_so_shitekara ええと、今ウエブブラウザーから見てますか ? 私のこのアカウントをフォローするのであれば、その Pawoo の画面内で私の名前をクリックしたら、「フォロー」というボタンがあるページに遷移するのではないかと…。

@mo_so_shitekara マストドンは、それぞれのサーバーに「入る」のではなくて、一つのサーバーに住みながら色んなサーバーの人をフォローできるんです。（まあ別々のアカウントを作っても悪くはないけど。）

@Arcu いらっしゃいましー。

@mo_so_shitekara 気付いてなかったんかい 😅 他サーバーの人をフォローする操作はちょっと分かりにくいですけど、Pawoo の左上の検索欄に「@[相手のアカウント名]@[相手のドメイン名]」を貼り付けてやれば、どんな場合でも表示できます。

@mochimochikin 配色あったかいでしょ。アカウントが二個になっちゃったようですが、使い分けるなり、休眠させるなり、御自由に…。

このアカウントは、notestockで公開設定になっていません。

@mo_so_shitekara 言われるまで気付かなかった…ピンコとレンジでちょうどいいですね。主に もふけものにいます。

@mochimochikin まあ、アカウントを持っておいて損はないので。プロフィール部分に Pawoo への誘導を書いておくといいかも。

@oldchipmunk 感想ありがとうございます ! 背景まだ仮の状態なので、また変わるかも…。

Mastodon のハッシュタグ検索、API としては複合条件に対応してるぢゃないですか。試してみたら「#\絵 #\ここたま #\レンジ」を期待通りに絞り込んでくれた。それならウエブ画面のインターフェイスを開けてほしいぞ。
https://docs.joinmastodon.org/methods/timelines/#tag

試したのは次の URL。
https://mofu.kemo.no/api/v1/timelines/tag/%E7%B5%B5?all%5b%5d=%E3%81%93%E3%81%93%E3%81%9F%E3%81%BE&all%5b%5d=%E3%83%AC%E3%83%B3%E3%82%B8
これはパーセント符号化を復号すると、
https\://mofu.kemo.no/api/v1/timelines/tag/絵?all[]=ここたま&all[]=レンジ

もふけもの内の投稿の通し番号の付け方が変わった時期のタイムライン。サーバーに依って切り替わった日が全然違う。Pawoo は 2018-01-23T06Z 頃に切り替わってる。

当時はどうやって連合の時系列順を実現していたんだろう。created_at を見てたのかしら。

直近の Pawoo の連合タイムライン。created_at は若干前後してて、id は単調に増加してる。id は各サーバーが付与してると思うけど、どういう理屈でこうなるんだろう ? それと遅延して届いた場合はタイムラインの途中に挿入されるのかしら。そうだとしたら、新着だけ取得するつもりで既存の先頭を min_id に指定して問い合わせたら、遅れて届いた物を取りこぼす事になる。

投稿の番号を単純に 65536 で割れば created_at の近傍の UNIX‐時間が得られる事は分かった。

味噌を買うべき。おはようございます。

@noellabo なんと。触ってみた所、マルチカラムのピン留め後だけ使える感じでしょうか。

@noellabo よく分からない設計…🤔 教えていただいてありがとうございます。

アカウント名（「sayunu」）から識別番号（もふでは「109727585732036523」）を得るには
/api/v1/accounts/lookup?acct=sayunu
を呼ぶといいけど、これが Mastodon に追加されたのは v3.4 と随分遅くて、Pawoo は v3.3 なので利用できない。困る。
https://docs.joinmastodon.org/methods/accounts/#lookup

例えば mstdn.jp に対して
/api/v1/accounts/lookup?acct=sayunu@pawoo.net
を問い合わせると、リモートとして把握している情報を得られる。本人に訊けないので周りに訊く方法。でも連合してる保証はないからなあ。

取りあえず Pawoo だけ例外的に扱う ? ほかの中小規模のサーバーで古い版を使い続ける理由はあまりないだろうし、99 パーセントを超える用途が片付くような気がする。

あー、この識別番号はリモートでは別の値が付与されてるのか。ううん。

ボカロ丼も v3.3 だから lookup が使えないぢゃんぬ。何で API の品揃えの中でここが長らく抜けてたんだろう、鍵になる部分なのに。sayunu さんの内部的な番号なんて知らないよ。

投稿が一個以上あるアカウントなら、
/@sayunu.rss
の中の「<item><link>…</link></item>」を読めば最新の投稿の識別番号が得られる。これを
/api/v1/statuses/[投稿の番号]
に投入すれば account の情報が関連付けられてるから、アカウントに関する API が叩けるようになる。二通りの方法を実装するしかないか。

アカウント名で lookup を問い合わせてみて id が取れたらそれを使い、取れなかったら RSS を経由した二段階の問い合わせで取得するようにしました。これなら Pawoo やボカロ丼といったバージョンの古い Mastodon に対応できる。（RSS の内容は link よりも guid の方が識別子っぽいので、そっちを読むようにした。）

スマートホン用のアプリとして Mastodon 本家と Tooot というのを使ってみたけど、「他サーバーのアカウントの情報は不完全にしか見えてないよ」という挙動はウエブと同じで、しかもリモートを見に行くという選択肢がないっぽいので更に悪いような…。常に現地のサーバーを読みに行ってくれるアプリって稀少なのかも。

アカウントなしで使える Mastodon Browser が一応動くようになりました。各サーバーの連合タイムラインを覗いて、そこに流れてる人を辿っていけます。自サーバーという概念がなくて常に現地を見に行くから、「以前の投稿は表示されません」とかいうのと無縁。
http://kokagem.sakura.ne.jp/app/mastodon-browser/

便利に使うには色々と足りないけど、凝ると終わらないので取りあえず公開しておいた。Misskey とかは API が違うみたいなので辿れないです（よく調べてない）。

そうだ、重大な制限として、スクロールに応じて古い投稿を追加で読み込んだり、新着を自動的に追加したりはしないです、今のところ。「やろうとすればできる」という技術検証でしかない。

自動的に読み込まないにしても、手動でページ送りする手段はあるといいな…。

応答待ちである事の表示がやっぱり欲しい。遅いサーバーは遅い。

ページ送りのボタンを付けました。最新・最古に飛ぶボタンもあり。一ページに 20 件を表示してるんだけど、次ページを読み込む際は境界の一件を残して新たに 19 件を表示する。

本文中のアット言及をクリックした場合も、投稿者名をクリックした時と同様に枠内で遷移できるようにしました。本当はハッシュタグのリンクとかにも対応したいんだけど。

Mastodon Browser でどこまでも遠くのサーバーをさまよっていたら、ニンテンドーダイレクトをやってる事をそのタイムラインから思い出させられました。まだ視聴してない。同じ頃にツイッターで不具合が起きてたらしい。

いい天気だなあ。後でお散歩に行きたい。

ページ送りに関しては常時二ページ分を読み込んで、スクロール位置を合わせつつ継ぎ足していく方が快適だろうなあ。緊急性は低いので将来やれたらやりたい。

あるといい機能 :
・ ハッシュタグ検索
・ フォロー先とフォロワーの表示
・ localStorage を利用した表示設定の記憶
・ 多カラムまたは多タブ構成
・ 複数タイムラインの合流
・ 取得した範囲での全文検索、クライアント側での抽出表示
・ 自動更新

閲覧中にタイムライン内で認知したドメイン名を入力候補として表示するようにしました。

JavaScript でオモチャを作るという事を度々してるけど、今回はコンテンツを通す窓なので実用性が高いですね。

返信連鎖の追跡もできたらいいな…。

絶妙に面白い 😆
https://twitter.com/_Lattice/status/1623346476868042757

ニンテンドーダイレクトを見ます。 #NintendoDirect
https://youtu.be/yo-C2MTUhCQ

『コロコロカービィ』が追加されるのは良いなあ。ニンテンドースイッチのジャイロ入力を使えるようにしてるわけでしょ ? これなら録画もしやすいし。 #NintendoDirect

『マリオカート 8 デラックス』及び「コース追加パス」買うか…これは買う理由かも知れないな…。コース追加と言いつつキャラクターも追加するのね ! 期待度を低めに設定してから少しづつ水準を上げてる感じ。 #NintendoDirect

『セレッサと迷子の悪魔』のロゴは、詰め具合を弄りたくなる。「子」は密度が低くて「悪魔」は密度が高いので、「の」を中央に置こうとしない方がいいかも。「迷」を僅かに大きくしようかな…。あと「セ」の字形は Cereza の「C」が前提にあるのを強く感じる。もうちょっとセとして堂々としてほしい。 #NintendoDirect

ハイカラシティはバンカラ街に慣れてから戻ると狭く感じるかも。まあ全機能がコンパクトに収まってるのは利点にもなり得るけど。行き止まりだった所を拡張してくれたら散歩好きとしてはワクワクするけど、電車が周回してたりするし、手間が掛かり過ぎるわな。バンカラジオもハイカラニュースに替わるのかしら。多分そう。 #NintendoDirect

取りあえず、ここまで。

マストドンのミュート機能を初めて試しました。連合タイムラインからも見えなくなるのね。

複数のマストドンサーバーの連合タイムラインを取得して来て一つのタイムラインに流し込むみたいな事をする場合、同一の投稿を識別して取り除く方法を考えないといけない。識別番号は各サーバーで付与してるようなので、同一性の判定に使えない。API の応答内容をよく読んだらいい情報があるかな…。

行けそう。応答の JSON に含まれる「uri」「url」という属性は、どのサーバーから見ても発信側ドメインの同一のアドレスを指してるから、これを比較すれば分かる。

マリオカートのヨッシーアイランドについてツイッターで追加の話をしました。 #NintendoDirect
https://twitter.com/sayunu/status/1623669901893464066

@tizerm 文法的にも文体的にも思う所が多いけど…一々添削しないでおくね。

「カスタム絵文字」を幾つか有効にしてみました 設定画面が分かりにくかった…。

「カスタム絵文字」設定画面はローカルとリモートに分かれていて、リモートの一覧に列挙されているのは、恐らく当サーバーが今までに受信してキャッシュしてある物。一ページに 40 個で 1533 ページある。リモートから送られて来た絵文字は、そのまま相手側を尊重して表示できる。

当サーバーで新たに書く投稿に使えるカスタム絵文字は「ローカル」の一覧に登録する必要がある。「リモート」の画面で好きな絵文字にチェックを入れて「コピー」を押すとローカルに複写される。これとは別に「アップロード」する機能もある（試してない）。

本文のデータとしては、カスタム絵文字は絵文字名の前後をコロン（:）で囲んだ文字列で表現される。これが表示の際に画像に置換される。前コロンの直前や、後コロンの直後が別の文字に接していてはならない（両外側に空白か句読点が必要）。管理者はローカルの絵文字を同名で別の絵に差し替える事ができ、そうすると過去に投稿された絵文字も新しい絵に変化してしまう。

設定画面の「表示・非表示」は、絵文字パレットに候補として現れるかどうかを指す。「有効・無効」は、本文中の置換を行うかどうかを指す。

各サーバーでは、同じ画像に異なる絵文字名を付けていたり、異なる画像に同じ絵文字名を付けていたりする。「どのサーバーから送られて来たか」に基づいて適切な画像を選んで表示してるんだろう。リモートの一覧からローカルに「コピー」する際は画像と名前が抱き合わせになっていて、改名は多分できない。

絵文字パレットの中では名前の ABC‐順に表示されるけど、個々の絵文字を「カテゴリー」に帰属させると、カテゴリー毎の見出しの下に並ぶ。「未分類」の絵文字は「カスタム絵文字」という見出しの下に並ぶ。カテゴリー設定は、投稿本文のデータには多分影響しない。

私ちょっと誤操作で「リモート」の一覧に載っている絵文字の一部を「削除」しちゃったけど、大丈夫かしら。mstdn.jp に由来するうち、多分 vivaldi から youtube まで。キャッシュを消しただけの事で、今度送られて来たらまた表示されるんぢゃないかと思うけど。（過去ログの中で使われているのが表示できなくなったかも ?）

機能を試す のが目的なので今は七個しか有効にしてないけど、もう少しあった方がいいでしょうね。理想的には もふけもオリジナルがあるといい…。

幅のない空白文字（U+200b zero width space）を使って区切れば、少なくともこの画面上では隙間なくカスタム絵文字を並べられるのを確認しました ​​ 一般の人には利用しにくいけど…。

カスタム絵文字の大きさや位置が揃ってなくて残念なので、取りあえず CSS で個別に調整してみました。画像自体を差し替えた方がいい気もするけど、どちらにしても複雑な絵が入る場合は通常の絵文字フォントより若干大きくしないと見にくいし、悩ましい

私は絵を描く人でもありフォント作る人でもあるので一番気になる立場かも知れない。

他サーバーとの互換性や、ウエブ以外のクライアントでの解釈され方を重視するなら、既に行われている大きさの基準を変えてはいけない気もする。でも自サーバーのウエブでの表示を最優先するとしたら、全てのカスタム絵文字をキャンバス中央に少し小さく揃えた上で、統一的に拡大するという規格を設けた方が扱いやすい。（その為の画像編集が面倒という観点もあるけど…。）

もふけものに留まる「ちょっとした必要性」を提供できたらいいなと思ったんです。それを求めて人が集まるという程ぢゃなくていい。現状でも「まったりしていて好き」という感想が時々見受けられるけど、流速ゼロになりがちなのはちょっと過疎い。

既にそこそこ会話が起きていれば、その繋がり自体が「必要性」になるけど、まだそれが成立してない。積極的にやるとしたら参加型企画を立てまくるとかあるけど、そういう柄でもないだろう。取りあえず「愉快なカスタム絵文字が使える」というのは奥ゆかしい「必要性」の一つになり得るので、それについて考えたわけです。

@nebiros むしろぬるいの歓迎ですよ ! 技術系サーバーでもないのに小難しい話が多くなっちゃって…。もちろん、全体公開にしない方が居心地がよければそれはそれで大丈夫です。

@daibaka ハコが綺麗なだけでは賑わいには繋がらないけど、カスタム絵文字はハコの中でもキャラクター性が出せる部分だからうまく利用したい所です…

それはさておきギョームをしないと…。

@cojohne リモートのを見ると、気にしてない感すごいですよね。日本の法律と感覚的基準に照らすと遠慮しちゃう。

「リモートで表示」の見た目をボタンにしておきました。

・ 著作権に関する懸念をあまり感じなくて、
・ カスタム絵文字の用途に合いそうで、
・ しかも もふけものに馴染みそうな題材
…として、いわゆる 2‐ちゃんねる系アスキーアートのキャラクターというのが考えられます。

おお、リモートから来る投稿の順序が前後した。

単なる偶然なのか、それともカスタム絵文字に関連する遅延があるのかしら。

東京地方で雪という報告があるけど、浦安では今のところ観測してないです。

さむい…。

絵文字の小ささは折角の表現力を奪っていると判断して、初期値よりかなり大きく表示されるように調整しました。たくさん並べるとうるさくなるけど、それよりも単体で置いた時の印象深さを重視。

初期状態での表示され方も参考に置いておきます。

@oldchipmunk 見やすいって思ってもらえてよかった

このアカウントは、notestockで公開設定になっていません。

@cojohne いいね

もふけものが開設されてから今までのローカルタイムラインをザッと読んで、どの時期にどれぐらい賑わっていたか調べて来ました。（読み切れる程度の量しかない !）どんなサーバーであると幸せなのかな…。大盛況である必要は多分ないんだけど、「たまに立ち寄ってみたら前回の投稿が全然流れ去ってない」というのを喜ぶ利用者は、あまりいない。「壁打ち」するにしても流れ去ってくれないと居心地が悪いわけで…。やっぱり少しは流速があり、それを持続できる状態に持って行った方が良さそう。

おはぬょう。

@daibaka ほわ。明日来るかな。意識しておこう。

https://github.com/mastodon/mastodon/tags

misskey.io が大量のインスタンスをブロックしていて、その中に mofu.kemo.no も含まれるらしい。うちの利用者に不都合が出てるようだし、外してもらわないと…。

https://fba.ryona.agency/?reverse=misskey.io

よく見ると「reject」ではなく「followers_only」に掲出されてる。これってどういう意味だろう ?

misskey.io の適当な人を検索欄から呼び出して「フォロー」を押してみると、すぐにはフォローが成立せず、「フォローリクエストを取り消し」というボタンに切り替わる。これで要求が相手に届いてればいいんだけど ?

現地（misskey.io）にアカウントを作って操作してみた。こっちからフォローボタンを押すと、あっちには「フォローされました」という通知が即座に表示される。こっちからはフォローリクエストの承認待ちという扱いになって、自分のフォロー先に追加されない。

misskey.io から mofu.kemo.no のアカウントをフォローしようとすると、「処理中」のまま進まず、フォローが成立しない。

明るいうちに出掛けようと思ったら Misskey の挙動を見てて暗くなっちゃった。後でまた考えます。

@daibaka misskey.io のアカウントとフォロー関係を結べないらしい件、どうします ? サポート窓口というのが設けられてるようだけど。

fedibird.com の方に持っているアカウントで misskey.io との間のフォロー操作を試すと相互に通るので、mofu.kemo.no との間の問題というのは分かる。

ていうか Misskey、ウエブのインターフェイスが一部表示されてないっぽくて基本的な操作が難しいんですけど…。ウインドウの横幅を狭くしないと投稿ボタンが現れないし、いわゆるハンバーガーボタンを押してもメニューが出て来ない。私の Chrome 103.0.5060.134 は最新ではないけど、そんなに新しい CSS‐属性でも使ってるんですか ?

@admtan 協力ありがとうございます。さてどうしたものか…。

『ブラタモリ』2022/10/8（#217 東京スカイツリー）の録画を消化。 #ブラタモリ

このアカウントは、notestockで公開設定になっていません。

「もふけもの。」のサーバーが v4.1.0 に更新されました。（Masto.host に任せっきり !）ボタンの色指定が微妙に変わってて読みにくい部分が発生していたのでカスタム‐CSS を直して対応しましたが、ほかに変な所があったらお知らせください。 #mofu_kemo_no

@daibaka 案外すぐ来ましたねえ。取りあえず問題なさそう。

@daibaka 私としては「サポート窓口」に「規制外してもらえません ?」って淡々と書こうかと思ったけど、あちらが何やら技術的・その他の要因で大雑把な大量ブロックをせざるを得ない状況であるなら、しばらく待って様子を見ようかなあとも思いました。経緯よく知らないし、公式な発表をどこで読めばいいのかも分かってないけど…。まあ声を掛けるだけ掛けても損はないかな。

毎週録画してるテレビ番組の為に古いのを消して容量を空ける必要があったけど、これは見終えるのが微妙に間に合わないな…。放送を見るしかない。

@cojohne なんか七時間前のマスコどんの投稿が今頃流れて来てる ?

@cojohne もふスタイルが何やら細かい事をやってるのは、空白を相殺する為とかではないです。ただ「大抵は空白があるから多少はみ出ていいよね」という意識はあります。

絵文字を区切る空白文字は zero width space でも有効なので、キッチリ並べるにはそれを使う事に…。

標準絵文字とカスタム絵文字で扱いを変えてるのは、次の考え方に拠ります。
・ 標準絵文字は小さくても読み取れるようにデザインされてるので、あまり拡大しなくていい
・ カスタム絵文字は複雑な絵が使われる可能性があるので、なるべく大きくしたい
・ 占有する字幅はどちらも等しくしたい

@cojohne そうだねえ。複数行に渡って敷き詰める使い方に対応するなら、むしろマスコどんのように単純に拡大する方式の方がいいかな…。こっちは行高を維持するようにしてあるので、重なっちゃう。

コーヒー豆（既に挽いてある物）を買って来なきゃ。

このアカウントは、notestockで公開設定になっていません。

@mastohost Thanks !

なんか今ちょっと mofu.kemo.no が重かったですね。回復したかしら。

『世界ふしぎ発見 !』（ブルガリア）、あまり集中して見られなかったです。

古いブラウザーで Misskey のメニューが表示されない件、CSS で「dvh」という非常に新しい長さの単位を使ってるせいのようです。Chrome は 2022/11 のバージョン 108 で対応したらしい。閲覧者側で「100dvh」を「100vh」に上書きしたら直った。

一応、調査の為に作ったアカウントはこれです。
https://misskey.io/@sayunu

Mastodon v4.0.2 では、マルチカラム表示で表示領域の横幅を狭くすると、単一カラムを前提にした無意味なヘッダーが現れるという不具合があったけど、v4.1.0 では この周辺のスタイルが修正されたみたい。カスタム‐CSS も対応しておこう。

カスタム‐CSS の この部分は不要になったので消した。そのほか、「.ui__header」に関する定義を幾つか移動する必要があった。セレクター優先順位が変わっていて、背景色とかの上書きが無効になったので。多分これで大丈夫かな。

マスクをしてると外気の匂いが分かりにくくなるけど、「おいしそうな匂い」を漂わせて客を誘う食べ物の売り上げに影響してたりするのかな。

@aotokage こんにちは。ウエブアプリから API‐経由であちこちのサーバーを閲覧していて気付いたんですが、kemonodon.club を見ようとするとアクセスがブロックされて、「blocked by CORS policy: The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed」とのエラーが出るようです。例えば、図は
https://kemonodon.club/api/v1/timelines/public
に他のドメインからアクセスした場合ですが、「access-control-allow-origin」が二個あるせいかな…。恐らく意図的な拒否ではないように推察されるので、よかったら設定を見直していただけるでしょうか ?

改めて考えるに、標準絵文字とカスタム絵文字を同じ字幅に縛る必要はあまりないかも…。標準絵文字は縦横にピッチリ敷き詰められる事を優先した方がいいような気がしてきた。Wordle みたいな使い方があるし。

カスタム絵文字は色んな性質の絵があり得て、全部を同じ寸法に統一する必要はない。CSS から名指しで大きさを指定できるんだから、敷き詰めるべき物も、大きく見せた方がいい物も、それぞれ最適に設定すればいい。そう考えたら正方形に縛る必要すらない。

まあ「Wordle みたいな」正方形を敷き詰める利用法も特殊と言えば特殊で、それを最優先にすべきかは検討の余地がある。正方形などの幾何学図形の絵文字だけ別扱いにするという考え方もある。

Misskey.io についてですが、「今までにフォロー関係を持った事がない小規模サーバー」からのフォローを先回りで遮断しておくのは、負荷軽減の為の苦肉の策として筋が通ってるかも。リモートのフォロワーの為に情報を送る負荷は、相手サーバーが大規模でも小規模でも変わらない。相手サーバーにフォロワーが一人いても百人いても一回送るだけでよい。とすると、百個の外部サーバーに一人づつフォロワーがいるより、一個の外部サーバーに百人いる方が、送出する立場では負荷が低い。既にフォロワーが一人いるサーバーに二人目が現れるのは構わないが、今まで送り先にしてなかったサーバーに一人目のフォロワーが現れると送信先が増えて困る、という事になる。

それでどれぐらい負荷が軽減するのか知らないけど、某サーバーに対する説明として「配信に関連する負荷」を挙げているようだし…。そういう目的で大量ブロックを行っているとしたら、まあ性能が追い付くまで見守るしかないか、という感じがする。しかしそうした事情をどこで発表してるのかよく分からない。（ツイートぐらいの長さの雑な発言しか見当たらない。）

サーバー管理者ってちょっとバーサーカーに似てる。

ずっと寝てました。また昼夜逆になってしまった。

「解除していただけないでしょうか」と書いて送りました。これ私は偶然 Discord のアカウントを持っていたけど、なければ問い合わせの為に作らされるんだろうか。

@admtan まあいづれにしても対応すべき問題なので、admtan さんが顕在化してくれたという事で…ありがとうございます。

出掛けて帰ったら、「対応中のチケット」#\technical-0140 のチャンネルが消滅していました。ほう ?

別の問い合わせも消えました。「投稿ボタンが表示されない」という、Misskey 利用者の立場での報告をしたんだけど…。

どうやら Misskey.io の問い合わせ窓口は機能してないようなので、本件の対応は残念ながらここまでという事にします。

@nebiros どうもです まあ、あちらも利用者の急増とかで大変みたいだし、しょうがないですね。

@nebiros そうですねえ。まだ Fediverse は若いし、穏やかな場になるまでしばらく掛かりそう…。

基本方針として、
・ 訊く前に深読みし過ぎない
・ 逃げたり隠れたりしない
・ できるだけ公式な手段で通信を試みる
…という事にしています。問い掛けてみれば、解決するかも知れないし、解決しなかったとしても相手の事情を知る手掛かりが増えるし、やれる事をやったならスッキリ終わるし、自分たちへの信頼感は補強されるし。

（正確には「深読みするけど、それを外向けの行動に直接反映しない」と言った方がいいな。知らされてない事は知らないつもりで、外面的に筋を通して振舞う。）

@admtan 調査に協力してもらって、ありがとうございました。ちなみにどのアカウントをフォローしようとしたんです ? 差し支えなければ。

『スプラトゥーン 3』のフェスマッチを少し遊んだけど、画像・動画の投稿先としてツイッターしか利用できないので、こっちでは言及してないという状況です。

ちなみに「ビターチョコ・ミルクチョコ・ホワイトチョコ」の三勢力に分かれたバトルで、私はビターを選びました。