TL;DR: FOKSはKeybaseのようなものですが、完全にオープンソースでフェデレーテッドです。ユーザーの視点から見て、現在Keybaseとどんな機能が共通していますか？例えば、私はKeybaseを主に公開アイデンティティ（HN、Redditなど）を使った安全なメッセージングやデータ/ファイルの共有のために覚えています。

マックス！あなたがこれをやってくれて本当に嬉しいです！私はKeybaseの大ファンで、ここ数年は分散型のオープンソース版を祈って（時には資金調達のアイデアを考えたり）過ごしてきました。FOKSの詳細を掘り下げるのが楽しみですが、あなたとKeybaseチームがやってきたこと、特にZoomの買収後もKeybaseを続けてくれたことに感謝したいです。

Max、これ面白そうだね！ブログをフォローしたいんだけど、Atomフィードを追加してもらえるかな？

FOKSはクールなプロジェクトだね。これからどんなプロジェクトが派生すると思う？実は、KeybaseのMerkleツリーとアイデンティティ証明の使い方にインスパイアされた暗号学ベースのプロジェクトに取り組んでるんだけど、プライバシーを高めるために仮名とチェーンハッシングを加えてるんだ。これに時間をかけてくれてありがとう！

KERIをまだ見たことがないなら、ぜひ読んでみて！インターネットアイデンティティワークショップで知ったんだけど、公開鍵のための生活の質を向上させる機能がたくさんあるんだよ。取り消し、ローテーション、リカバリーとかね。「キーイベントレシートインフラストラクチャ」。証人に依存してるみたいだけど、そこはどうかなって思う。でも、プレゼンはすごく印象的だったよ。 https://keri.one/

正解です！リモートのチームメンバーは、サーバーにアカウントがなくても共有されたチームキーやチームのデータにアクセスできます。チームキーを知っているだけで、リモートユーザーが認証してサーバーとの間で（暗号化された）データを転送できるんです。サーバー間の通信はほとんどないので、設計やソフトウェアのアップグレードが簡単になります。

昔は、遊びでやってたDevOpsプロジェクトのためにKeybaseのGitリポジトリを使ってファイルベースのシークレット管理をしてたんだ。FOKSのGitリポジトリか、SOPSのネイティブサポートがあったらめっちゃクールだね！

実際には、個人プロジェクトをやってる誰かが、自分の手元にあるツールを使ってウェブサイトにきれいな画像を追加しただけなんだよね。そのウェブサイトはプロジェクトとは全く関係ないし。もしアプリを自分でコーディングしてたら、確かに疑ってもいいけど、そういう証拠はないし、ただウェブサイト用に画像が欲しかっただけなんだよ。彼らはソフトウェアエンジニアで、グラフィックデザイナーじゃないしね。そのグラフィックの出所については、どのウェブサイトエディタを使ってるかと同じくらいの重みしかないよ。もし彼らがウェブデザイナーとして自分を売り込んでたら、まあ、それは関係あるかもしれないけど、ここではそういうことじゃないからね。

その画像（bootstrap、vault）は、記事やプロジェクトにとってはかなり二次的なものだね。個人的にこれを試すのが楽しみだよ！maxtaco、これを作ってくれてありがとう！

好きか嫌いかに関わらず、今AI生成の画像について文句を言うのは、PhotoshopやIllustratorを使って画像を作る人に文句を言うのと同じだよね。

同意するよ。マックス、AI画像は削除することを強く勧めるよ。気にしない人もいるけど、結構な数の人が気にしてるからね。君は100%コーディングしてないと思うけど、AI画像はそういう印象を与えちゃうんだよね。

このクレームは、サイトのレイアウトやページのデザインに関するHNのガイドラインに反してると思う。今後は毎回このクレームをフラグするつもりだよ、ガイドラインに反してると考えてるからね。証拠なしに主張できることは、考慮せずに却下できるってヒッチンズの剃刀にあるように。AI生成画像とそれを使ったプロジェクトの質との関係についての研究は存在しないと思うから、君のクレームは動機づけられた推論のように見える。生成された画像が質の低さや判断の悪さのサインだと信じているから、他のプロジェクトの側面にも影響すると思ってるんだろうね。私たちの認識がこういう風に色づけされるのは正確じゃないし、マーケターによって操作されてる。商業的でも顧客向けでもないこういうプロジェクトのプロモーション面についての批判は、君の側からはあまり説得力がないし、指摘されるべきだと思うよ。 https://en.wikipedia.org/wiki/Hitchens%27s_razor

Radicleには詳しくないけど、ちょっと調べてみるね。1) のケースで、そのサーバーがAWSでホストされてると考えてみて。メンバーだけがSSHでアクセスできるとはいえ、平文はクラウドハードウェアに知られてしまうから、そこから流出する可能性があるよね。FOKSでは、サーバーは暗号化されたデータしか見えないから、その攻撃はかなり軽減されると思う。もしSSHサーバーがチームメンバーのワークステーションの1つでホストされてたら、FOKSのセキュリティの利点はかなり少なくなるだろうね。KVストアとGitサーバーはFOKSのインフラの上に「アプリケーション」として実装されてるから、依存関係はないよ。彼らはPer-Team-Keys (PTKs) のシーケンスを見てて、古いものを復号化に使い、新しいものを暗号化に使ってる。FOKSの上にいろんなアプリケーションが作られるのを見たいけど、適切なプラグインアーキテクチャを確立するために少し作業が必要かもね。

簡単なマルチアカウント機能は、もう実装されてるといいな（foks key switchはかなりスムーズだし）。これはよく使う機能なんだ（個人アカウントは@foks.appにあって、会社アカウントは@ne43.foks.cloudにある）。これはいいポイントで、かなり考えたことがあるよ。もし本当にいいアイデアなら、後で変更できることもあるけど、非ローカルの管理者がいると、サーバー間の通信が増えて、信頼関係も増えるから、それを避けたかったんだ。例えば、alice@fooがbluejays@barの管理者だとするよ。alice@fooがメンバーを追加したり削除したりするときには、bluejays@barに対して署名された変更を行う必要があるんだ。今は、barのサーバーがこれらの署名の有効性をチェックしていて、alice@fooの最新の鍵で作られたかどうかを確認してる。つまり、barがfooに認証して、aliceの署名チェーンを読み取って最新の鍵を確認する方法が必要になるってこと。fooとbarを分けておくのは、権限の分離やネットワークをシンプルに保つためにいいアイデアだと思ってたんだ（それが稼働時間の向上やソフトウェアのアップグレードを簡単にすることにもつながるし）。