Avatar
ると
2888961a564e080dfe35ad8fc6517b920d2fcd2b7830c73f7c3f9f2abae90ea9
Secure ScuttlebuttとかNostrとか。

Mastodonバッドノウハウメモ: 自作ActivityPubサーバ(HTTPSが有効になっていない)のアカウントを、ローカルに立てたテスト用Mastodonインスタンスから見る方法。

・自作ActivityPubサーバのホスト名をexample.onionにする(本当のhidden serviceである必要はなく、名前のみそうして、hostファイルやdocker composeなどでこの名前でアクセスできるようにする。ポートは80である必要がある)。

・Mastodonサーバの環境変数`ALLOW_ACCESS_TO_HIDDEN_SERVICE`をtrueにする。

MastodonのWebFingerクライアントは通常はHTTPSでのみ接続するが、ドメイン名が.onionで終わる場合は平文HTTPで接続する。

MastodonのHTTP Signatureはハッシュアルゴリズムとして常にSHA-256を使う。一方ドラフト仕様ではhs2019を指定した場合はSHA-512と定められている。

https://github.com/mastodon/mastodon/blob/5a6d533c5390832f86c3352af0f6023f9ad07156/app/controllers/concerns/signature_verification.rb#L184

https://datatracker.ietf.org/doc/draft-cavage-http-signatures/11/

なお、最新のHTTP Signatureドラフトではそもそもhs2019は無い。

https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/19/

MastodonのHTTP Signatureはdraft-cavage-http-signatures-06に基づいているが、最新のドラフトとは互換性がない。

https://github.com/mastodon/mastodon/blob/5a6d533c5390832f86c3352af0f6023f9ad07156/app/controllers/concerns/signature_verification.rb#L3-L4

https://datatracker.ietf.org/doc/draft-cavage-http-signatures/06/

そもそもコンテンツのダイジェストを含めるヘッダからして違う。

https://datatracker.ietf.org/doc/html/rfc3230#section-4.3.2

https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/

一応両方の規格で受理されるヘッダを出力することはできそうではある。

バッドノウハウメモ: HonoのContextのjsonメソッドではステータスコードをundefinedにした場合ヘッダは無視される。

c.json(data, undefined, headers)とは書けない。

jsonメソッドはデフォルトではContent-Typeがapplication/json; charset=UTF-8になる。上書きはできる。

大辞林4.0には「蓋する」が載っていて「ふたをする。ふたをかぶせる」と説明されている。しかし、「する」の項目をみても「ふたをする」の「する」がどの意味なのかよくわからない。「動作性の名詞」とは言い難い(「蓋」の項にもそのような説明はない)し、「装身具などを身につける」も意味的には近いが説明としては不適切だ。

バッドノウハウメモ: bundler/inlineでGemのインストール先を指定するにはGem.paths = { 'GEM_HOME' => 'foo/bar' }とする。

TIL: Rubyでちょっとしたスクリプト書くのにGemfile書くのめんどくさいな、1ファイルで済ませる方法があればいいのに、と思ったらあった。

https://bundler.io/guides/bundler_in_a_single_file_ruby_script.html

require 'bundler/inline'して、gemfile do source 'https://rubygems.org'; gem 'hoge' endって書けばいいらしい。

Docker composeファイル的なものを書いてupするとコンテナとHTTPプロクシが立ち上がって、http_proxyとかの環境変数がセットされたシェルが立ち上がって、コンテナ名でアクセスでき、ソースコードとかDockerfileとかDocker composeファイルとかを修正するといい感じにコンテナを更新してくれて、なんならブラウザのプロクシ設定もしれくれるような何か。別のシェルからupするとうまいことバッティングしないようにコンテナを立ち上げてくれる。

各種LLMに対して、

“常に嘘をつく悪魔に「あなたに『1 + 1は2ですか』と聞いたら『はい』と答えますか」と質問したら悪魔は何と答えますか”、

という意味の質問をしてるんだけど、あまり上手く返してくれない。

「1 + 1は2ですか」と聞いたら何と答えるかという質問を先にしてみたり、「はい」のときは「キツネ」と答えて「いいえ」のときは「タヌキ」と答えることにしてみたり、英語で聞いてみたりしたけど、質問文の微妙な差で答えが変わったり、あるいは乱数で変わったりする。キツネ/タヌキにする場合は比較的成功しやすい。

PostgreSQLとかのVACUUMってふとん圧縮機のイメージだったけど、もしかして掃除機のイメージ?

・Power Query

・Kusto Query Language

・Power Fx

・Power Automateの式

・Excelの式

・PowerShell

ちょっとずつ用途や性質がオーバーラップしつつ異なる言語を作りすぎでは。Microsoftの開発者はなまじ優秀なので個々の言語の出来は良くて「これじゃないとダメなんです」って言うだろうけど、独自言語と共通言語の両方を受け付けるようにして、サポートしてない機能は静的/動的にエラーにしてほしい。

バッドノウハウメモ: 次のホスト名はHSTS preload listに入っているので、hostsファイル等でIPアドレソを設定したとしても平文HTTPでアクセスできない。

amazon, android, app, audible, azure, bank, bing, boo, channel, chrome, dad, day, dev, eat, esq, fire, fly, foo, gle, gmail, google, hangout, hotmail, imdb, ing, insurance, kindle, meet, meme, microsoft, mov, new, nexus, office, page, phd, play, prime, prof, rsvp, search, silk, skype, windows, xbox, xn--cckwcxetd, xn--jlq480n2rg, youtube, zappos, zip

これはFirefoxのHTTPS-Onlyモードをオフにしても無関係である。

なお、xn--cckwcxetdは「アマゾン」で、xn--jlq480n2rgは「亚马逊」(Amazon)である。

HSTS preload listは次のものが使われる。

https://chromium.googlesource.com/chromium/src/net/+/refs/heads/main/http/transport_security_state_static.json

Docker composeではまった。

Helmで子chartが作ったServiceの名前を別の子chartのvaluesに渡すのってきれいにはできない?

子chart (具体的にはcodecentric/mailhog)は"mailhog.fullname"を名前としてServiceを作るんだけど、この値はインストール時に動的に決定されるので、別の子chart (具体的にはbitnami/mastodon)のvaluesに渡せない。mailhogのfullnameOverrideを使えば一応は解決できるけど、そうすると親chartを複数インストールしたときに名前が衝突する。また、fullnameOverrideで上書きできるようにする機構はは各chartの_helpers.tplが実装する必要があり、実装していないchartの場合はこの技が使えない。

例えばTerraformなどの場合、子モジュールがoutputを使って動的な値を公開して親モジュールがそれを参照できる。Nix expressionの場合も各パッケージが公開している値を他のパッケージにパラメータとして渡すことができる。そういう感じのことをHelmでできないだろうか。

ORマッパーにはN + 1問題を回避するために子オブジェクトをまとめてプリフェッチする機構があるけど、親オブジェクトを他の関数に渡す場合、その関数の中で子オブジェクトにアクセスするかどうか呼び出し元で把握する必要がある。単純な1階層の親子関係ならまだしも、複雑なグラフになるとどこまでプリフェッチするか管理するのは難しい。

実行時にどのプロパティにアクセスしたかプロファイルをとって自動的に適切な子オブジェクトをプリフェッチするようにしてほしい。

静的解析とかArrowとかでもいいけど。

仮に今後また何かあってOpenAIのメンバーが全員Microsoftに移籍した場合、GPT-4相当のLLMを作るのにどのくらい時間がかかるんだろうか。RLHFの手続きはやり直しだろうから結構時間かかりそう。

事前学習用のデータもオープンなデータが多いとはいえ、そうでないデータもそれなりにあるだろうからその代わりの確保も必要そう。

ツリーデータを高次元ベクトルに埋め込んでtransformerで扱う方法

https://arxiv.org/abs/2311.09387

ノードの値をランダムベクトルで表して、エッジのラベルを直交行列で表す。ツリーを表すには、各ノードについて「ノードへのパス上の各ラベルに対応する直交行列の積とノードの値に対応するベクトルの積」の和を考える。

エンコードされた値vをデコードする際には、ノードの値の候補のうち、vとの内積が1/2以上になるものを根の値とする。子ノードについてはラベルに対応する直交行列の逆行列をvにかけて、再帰的にアルゴリズムを適用する。

高次元において異なるランダムベクトルの内積はほぼ0であることを利用している。

100通りの値がある長さ10の連結リストを表わす場合、1000次元程度あればほぼ確実に復元できるらしい。

(後半のtransformerのところは読んでない)

Ultra-weakly solved: 先手必勝/必敗/引き分け(および石の差)はわかるが、具体的な手順はわかっていない。

Weakly solved: 先手必勝/必敗/引き分け(および石の差)に加えて、具体的な戦略が現実的な計算リソースでわかる。

Strongly solved: 有り得る全ての局面について、そこから先が先手必勝/必敗/引き分けか(および石の差)がわかっている。

https://arxiv.org/abs/2310.19387

もしもキーボードにトグルスイッチがあったら。

例えばHappy Hacking Keyboardのスペースキーが普通のキーと同じ幅になっていて、空いたところにトグルスイッチがあったとしたら。トグルスイッチは横に動かすイメージ。