このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
かつてのヘースブックでの政治的意見操作とかも思い出すけど、結局「人々は逃げられたはずなのに逃げなかった」ただそれだけなのだよなという思いがいつもある
ネットワーク効果だの「みんなが使っているから自分だけ抜けると〜」だのいろいろ言い訳はあるけど、結局それ原油の価格が急上昇したりしたとき「私はオイルショックで起きたトイレットペーパー騒動を知っているし愚かなことだと思うけど、それはそれとして『私以外の愚かな人々』がトイレットペーパーを買い占めると困るから私も買っとくわ」と何が違うのという。
トイレットペーパーでピンとこないなら取り付け騒ぎとかでもいいです
「私には大局が見えているが、他の人が愚かだと私まで損をするので一緒に愚行をはたらきます」って、それは紛れもなく愚かな人々の一員じゃん。帰結を背負う覚悟もなく悪行はたらいてんじゃねーよ
信念と美学すらない悪なんて、ただのカスじゃん。そんで胸を張ることもできず「でも損するのは嫌だもんね〜」で同じ境遇の受動的な愚行の担い手たちと同調して傷をなめあうわけでしょ。しょーもなすぎて白けるわ
ActivityPub サーバとクライアントの特殊化のミスマッチ - waf_thread
https://waf.nopth.ink/articles/0194335c-4be7-7f03-97be-e132bf56fdb2/
書いた
https://mastodon.cardina1.red/@lo48576/113708648293372158
ここで一瞬だけ言及した話をちゃんと書いた
Thanos と S3-compatible object storage で優勝できそう?
Thanos - Highly available Prometheus setup with long term storage capabilities
https://thanos.io/tip/thanos/storage.md/
S3 互換以外にもいろいろ使えるらしい
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Cloudflare R2、そんな HAL 9000 みたいな命名 (俗説) していいんだ……となる
標準のC2S APIが普及したとしても、現状のActivity Streamsの枠組みだと受信者側でのコンテンツのフィルタリングが曲者そう。
現状でも`Note`と`Article`といった区別くらいはあるけど、例えば`Video`に加えて「ショート動画」のようなものは当然ながら標準では用意されていない。この例ではヒューリスティックに判定という手もあるかも知れないけど、そんなどのクライアントで何が見えるのかはっきりしない環境で発信者・受信者ともに嬉しいのか微妙そう。`"type": "ex:ShortVideo"`のようにアドホックな拡張型を用意する手もあるけど、今度はショート動画とその他の動画の区別を気にしないような受信者との互換性が問題になる。いずれにしても中央集権プラットフォーム(やAtmosphere)のように「ショート動画」が満たすべき解像度等の要件の合意を成立させるのは困難そう。
(ちなみにこういう場面で`"type": "ex:ShortVideo"`の対案としてよく提案される解決策として、`"type": ["Video", "ex:ShortVideo"]`のようないわゆるmulti-typeなオブジェクトがある)
難しそうではあるけど、結局現状すでに受信側はユーザからみて単一受信サーバと単一クライアントでの閲覧になりがちな気がしていて (あるいはそれを嫌がってフォローを諦めることになっている気がして)、そこで発信者サーバの実装名を詳細なオブジェクトタイプのヒントとして使うくらいなら最初から type 用に発信者サーバ固有の URI を用意するのも大差なくないか? と思ってしまう
単に現状は「あまりにマッチしないコンテント種別の受信をユーザが諦める」とか「実装の多様性が十分に小さい、あるいは特定少数の既知の実装による投稿が大半である」とかの妥協や一過性の偶然のうえで安定して見えているだけで、いずれ妥協しきれなくなったり未知の実装による未知のタイプの投稿の割合が無視できなくなったりする日は来ると考えるべき (ユーザが逃げ出さなければ)
まあ multi-type なやつが現実的なんじゃないかなとは思う (DITA を思い出していた (ノードの型を「継承」して新しい型を作れて、非対応の処理系は基底型のノードとしてアクセスできる))
OASIS DITA仕様書 アーキテクチャ仕様
https://www.antenna.co.jp/XML/ditaspecialization-ja.html
AT Protocolでは割と積極的にAppView固有の語彙を作る風潮がある気がするけど、lexiconに対して少数のAppViewのみを想定したAtmosphereと比較して多様な独立した実装間の相互運用を尊んでいそう(ホンマか?)なFediverseにおいてはそこまでの割り切りは馴染まなそうというのが個人的な感想。
読書とアニメ視聴記録というユースケースがあるなら`my.skylights.rel`と`app.netlify.aniblue.status`を作るのがAtmosphereだとすれば、「作品とその閲覧と評価」のような共通項を見出して共有できる語彙は共有するのがFediverseっぽいというか(実際には例えばBookwyrm拡張は「本」しか想定していなそうだけど(`inReplyToBook`とか)……まあ、あくまで概念的な話として、はい)。
TwitterクライアントでRedditは見たくないけど、YouTubeでTikTokを観るくらいは(その逆を防ぐ仕組みさえあれば)良いんじゃね、的な
そのへんの抽象化 (あるいは共通項の抽出) って結局人間へのビューを提供するアプリの知識と能力次第になるので、クライアントの仕事であるべきだと思うし、だったら inbox として動作している受信側 AP サーバは object type agnostic でいいと思う (というかべつに Mastodon とかでも API 経由ならちゃんとそういう未知のオブジェクトをフェッチしてこられるのかもしれないけど)
ここは結局エコシステムの傾向の話になってしまうのだが、受信側サーバが「(なんでも受信してクライアントに転送できるけど) 俺は短文投稿専用です!」みたいな顔して許容範囲の狭い client (というか viewer) としての機能をコア機能で本質の一部であるかのように提供してしまうのが「受信者はクライアントではなく (あるいは、だけでなく) サーバを使い分けるもの」という暗黙の常識を強化する原因になってしまっているのではないかというのが。
結局サーバ実装とクライアントが密結合すぎる (かつそのような形での提供が当たり前になっている) のがユーザによる利用の幅を狭めて硬直化させているのでは。
個人的な感想、というか、普通にこれを引用すれば良い話だった:
https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/#activities
> When an implementation uses an extension type that overlaps with a core vocabulary type, the implementation MUST also specify the core vocabulary type.
https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/#extensibility
> implementations that rely too heavily on the use of extensions may experience reduced interoperability with other implementations.
(というかmulti-typeなオブジェクトは普通にMUSTな要件で言及されているレベルの事柄だったな)
CI で通るのにローカルで走らせると失敗するテストが発生して泣いてる、パーサの実装だしどちらも Linux だし環境依存の要素ないはずなのに……
当然のことながら CI パイプライン定義が壊れており、変数名に typo があった (かなしい)
電気毛布とか電気スリッパとか、良さげではあるが洗濯乾燥機に突っ込んで全自動で洗えないものは買わないことにしているので残念ながら
このアカウントは、notestockで公開設定になっていません。
ところで:#Strinova のマッチ成立直後のロード画面の音楽が前バージョンより半音高くなってる