json-ld 真面目に解析すればするほど沼に落ちるのが怖いやつ

たぶん、真面目に読んだほうが良いですね。

私のやつは、世の中に流通している Living standard な API 仕様で再定義しているので JSON-LD になってないんだよな。

一番やばいのは、 Living standard で実装するサーバーが増えると崩壊するという。。。

うちも json-ld をしっかり処理したいねぇ。

JSON-LD 悩んだらみたらしさんにごはんを提供して教えてもらうか。

なんかえらいレベルの高いリンクが流れてきたわね。

こんなん送られたら、クラッシュしてまう。（クラッシュはしない）

To: as:Public 実際のところ届いたことはない。

Expanded されている前提で回っている。

でも https://www.w3.org/ns/activitystreams#to で届いても動かないんだよな（爆

Mastodon の同じ具合の Expanded 具合なら動きます。（ひどすぎる）

これだから JSON として扱っちゃいけないんだよな。（実務上トラブル発生していないのもおかしいっちゃおかしいのだけど）

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

一応、記事の RSS みたいなやつの SEO に効果があるとかいう話はあるみたいね。

クソの定義ですわ。

これでもリレーは動くんだよな。

JSON-goLD 入れるとどのくらい負荷に影響あるんだろうか。

Ohagi 動いているとすると、 Mastodon や Misskey は任意の Expanded 具合でも動くのかしら。

Undo Follow リクエストを投げる機会がある。

外部に出ていく Activity のお話でした。

なるほど… 😇

表現方法ありすぎてやばくね？？？

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

いい感じすぎる、

Decode だけでも json-LD 対応したいね。

でも、リレーでは、投稿本体の Body をいじると署名が崩れるので結局内部解析でしか使わないのが悲しいところよな。

毎秒アクセスしたら DoS になりそうなのでそうですね…

いくつかのコンテキストはプレインストールしておいてもいいのかもしれん…

JSON-goLD 昔試したとき、 Expand に 1秒とかかかってキレてた。（使えるわけない）

スクリプトみたいな感じで、 1回変換させるだけのテストで回してたので、2回目以降の速度は多分確認してなかった。

堂前@IIJさんはTwitterを使っています: 「30年前はルータ専用機器はまだ高価。IIJでは専用線ご利用者向けに、PC/AT互換機にBSD UNIXとpppをインストールしたものを「ルータ」として貸し出していました。このためにIIJ社内で開発されたのが、後のiij-pppです。写真は発掘された1FDルータ。 #商用インターネット30周年 https://t.co/eRBRBNfF2k https://t.co/84dxC6fAvm」 / Twitter https://twitter.com/IIJ_doumae/status/1596025323891568640

普段気にせず使っている NAT にも歴史があるんだなぁ。 - NAT on iij-ppp https://www.junichi.org/FreeBSD/NAT/nat2.html

CGN とかよくうまく動くな。

ジョブキュー、 faktory を使うという手も（）

0.0.1 の時に試して性能的につらかったのでそれ以降試してないけど、 v1.6.2 まで上がってる。

サンプルのクライアントがゴミなので、自分で HTTP リクエストを送る前提になるけど。

参考までに RichardKnop/machinery はバックエンドをめっちゃ選べる。

そのせいでむだにライブラリがでかくてつらい。

Rabbit MQ をバックエンドにすると安定するんじゃないかと検討してたりした。

結局キューがたまりまくった時にさばきが不調になるのは、 Redis がポンコツになっているときなので、 Rabbit MQ にしたらよくなりそう。

Redis データたまりまくった時の挙動が厳しくなりがち。（永続化を無効にしていればたぶん問題ない）

リレーは、入力速度が出力速度を超えると平気で Redis が 2GB とかの dump.rdb を書き出し始めるので Redis 自体がレスポンスしなくなってくる。

これは、 v1.2.0 で改善はしてる。

Redis の利用容量さえ小さければ、いくらキューにたまっていても挙動が悪くならないので投稿の共通化をした。
今後は、 gzip で圧縮してやろうかと考えている。

新生キューライブラリ使いた～い！！！

そもそも、開発が続くライブラリなさすぎ問題なんだよな。

†𝙀𝙏𝙀𝙍𝙉𝘼𝙇 𝘼𝙇𝙋𝙃𝘼 𝙑𝙀𝙍𝙎𝙄𝙊𝙉†
でも ETERNAL Maintain がされるとうれしい（無茶）

RichardKnop さんは、 Grab に就業中で忙しいっぽいんよね。

いや、むしろ machinery 開発中は Grab にいたけど、最近メディア系に転職しているっぽい。
- https://uk.linkedin.com/in/richardknop

Redis バックエンド以外を削って小さくした Fork 作りたいんよね。

金融工学の会社？？？ - ESGブック - 私たちは持続可能な未来のために金融市場に力を与えます。 https://www.esgbook.com/

machinery の Fork ちょっと真面目に考えてみるか。

+ETERNAL WIP+

まずはここからしておくか。

ごちうさ感（？）

RabbitMQ で使われることを意識されている…

場所だけ作りました - yukimochi/machinery-v1: Machinery is an asynchronous task queue/job queue based on distributed message passing. https://github.com/yukimochi/machinery-v1

開発がとん挫した v2 のコードを削除するところから始めないといけなさそう。

ライセンスの確認 - Mozilla Public License version 2.0 日本語参考訳 | コミュニティ関連文書情報 | Mozilla Japan コミュニティポータル https://www.mozilla.jp/documents/mpl/2.0/

master が v2 で開発止まっちゃってるので。

作り直すとよくなりそう症候群なのではないかという気がしてる。

Activity-Relay でもこの病気にかかりかけてたけど我に返ってなんとか既存実装を直す方向に転換できた。

作り直し終えたのはえらすぎるのでヨシ！

ふむ

ふむふむ

意外と削るだけなら楽そうかも。

丸の内ランチでもいくかな。

キノコンピックまだ終わってなかったな…

@yakumo WireGuard で繋いじゃえ〜！

なんかガラス張りすぎるビルあるんだが。
前からあったっけ。

大手町タワーだった。

大手町のビル、ガラス好きすぎ問題。
私もすき。

大手町混みすぎ

KITTE 地階一階の楽天モバイル終わってるな。

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

SQS, GCP PubSub, Memcached, mongoDB のサポートを削除し、ライブラリの更新を行った RichardKnop/machinery/v1 ができました。

https://github.com/yukimochi/machinery-v1

互換性吸収層のつくりが完璧で、さっくり取り除くことができました。すごい。

Activity-Relay のバイナリサイズは、
36.4 MB から 18.5 MB まで縮小しました。