リアル仮想通貨ファン

[22:29:02] おひさ
[22:29:15] 君子さんね
[22:29:31] ところで、メルカリNFTマーケットプレイスの件どう思いますか？
[22:29:58] そうなのね
[22:30:20] ERC-20 や ERC-721、ERC-1155 はコントラクトの実装ではなくインターフェイスに関する規定でしかないので
[22:30:47] transfer による残高の移転や burnFrom などの実装はどのようになっているかはわかりませんよね
[22:31:12] 極端なはなし、コントラクトオーナーでなくても burnFrom を実行できてしまうようなコントラクトも記述可能なわけですが
[22:31:49] メルカリは OpenSea などのマーケットから購入した NFT をメルカリの所有としてオフチェーンで取引できるマーケットを作るとか
[22:32:10] メルカリに購入された時点で、コントラクトオーナーあるいは第三者が burnFrom をすると
[22:32:20] オンチェーン上ではメルカリの EOA の所有ではなくなるのに
[22:32:45] メルカリのマーケットプレイスの中では、メルカリが所有すると主張するもうひとつの NFT の権利が転売され続ける
[22:32:57] まぁ、メルカリは出庫できないように設計しているようなので
[22:33:10] そもそも、メルカリに権利が写った時点で別のなにかなのかもしれないですけどね
[22:33:22] どちらさまですか？
[22:33:46] もうひとりの…
[22:35:32] どうして、🍵 さんがそれを知っているのでしょう
[22:36:41] 君子はまたお風呂か…
[22:37:09] ダリさんじゃないの？
[22:38:09] 聖人君子であるぞ…
[22:40:55] おやすみ
[22:41:29] 私は、まだ寝ないよ…
[22:42:04] これは私の夢だから寝ているとも言う…
[22:42:14] 虚構の中で覚醒している…
[22:44:13] bF の HN の色は HSB 表色系のうち、色相環の一定の色相の範囲のみが許可されている
[22:44:51] それはなぜかと言うと、背景色の使われている色が寒色系であるから視認性などの観点からデザインの基本として補色を用いるべきだとされるからで
[22:45:54] ごめんなさい
[22:46:07] 正確には、HSL 表色系でしたのでここに訂正します
[22:48:48] https://amidagamine.com/notes/wp-content/uploads/2015/07/20150718a.png
[22:49:21] この色相環において、0~56°の範囲の色が用いられています
[22:49:43] ちょうど、対角に位置する色相の色が背景色に用いられていることがわかると思います
[22:50:14] ちなみに、私の HN の色は限りなく 0°に近い真っ赤です
[22:51:58] 廃止されてほしいのかｗ
[22:52:12] bF の悪口を言いまくれば閉鎖されるかも
[22:53:23] 和平の上にあぐらをかいていてよいのか
[22:53:34] ここは戦場ですよ…
[22:53:58] しかし、このチャットのメッセージ配送に使われるシグナリングのシステムは
[22:54:05] 何もチャットに限ったものではない
[22:54:24] いろんな取引が、このシグナリングシステムを使用したメッセージキューを使用していると考えられ
[22:54:33] このチャットはメンテのときでさえ止まらない
[22:54:53] このチャットが重くなるようなことがあれば、注文が通らなくなる可能性が高い
[22:55:41] 板の取引を執行するエンジンは別だろうけど
[22:56:42] このチャットは、たんに注文データや最新の価格情報などのフィードを配信するためにも使われていて
[22:56:47] これが止まることは許されない
[22:57:00] チャットは副次的なものであるので
[22:57:16] これを運用するのに追加で大きなコストがかかっているとは思えない
[22:57:35] DDoS 攻撃をするようなスパマーはいないと思うし
[22:58:00] 廃止すること自体は簡単だとは思うけどね
[22:58:11] 単にフロントエンドの UI を廃止すれば良い
[22:59:23] まぁ、しかし実際のところ bF のチャット使うより自前の鯖でチャット処理するほうが簡単だったりはする
[23:00:57] ｗ
[23:01:27] Discord の方が Bot 使えるし自由度高いから面白いけどね
[23:03:14] そもそも、bF チャットですらこの賑なのに
[23:03:35] 複数チャンネルを用意したところで、話題が分散するだけで過疎が深刻化するだけ
[23:04:03] 権限をむやみに複数人にわたすと
[23:04:26] 鯖ごと消滅しかねない
[23:04:43] そうそれ
[23:05:17] 特権を持った人が飽きないという前提と、特権を持つ人がある程度リテラシーを持っていないと
[23:05:34] Discord の設計にも問題あるけどね
[23:05:53] Discord は二段階認証をしていてもセッションハイジャックできるような脆弱性があて
[23:05:59] Github に攻撃ツールが転がっている
[23:06:34] 昔は、セッション管理に Cookie を使うことが多かったけどこれはブラウザのセキュリティ機構で守られていたが
[23:06:49] 最近は、ローカルストレージに機密情報を保管する例が増えた
[23:07:17] このローカルストレージに保存されているセッションキーが何らかの理由で流出するとセッションハイジャックされる
[23:07:53] fetch でも、セッションクッキーを使用可能なんだけどね
[23:08:11] credentials をブラウザに委ねていれば、最低限ブラウザのセキュリティで保護されるけど
[23:08:28] セキュリティの知識がない人が設計した fetch 系の API は危険
[23:09:33] ローカルストレージを用いる機密情報の保管方法も、クロスオリジンの制約がかかっていてセキュリティの問題はある程度緩和されるだろうけど
[23:10:24] チャットなどに埋め込まれた JavaScript や、添付されたデータが Discord などの運営主体のドメインのコンテンツとして配信される場合、クロスオリジン制約を突破されるおそれがあり
[23:10:58] また、そもそも論として Disocrd などのデスクトップ版アプリは Electron というフレームワークを用いているため
[23:11:12] 開発者が、意図的にセキュリティ上のクロスオリジン制約などを緩めることはでき
[23:11:51] セキュリティをよく理解していないエンジニアが開発していれば、二段階認証を設定していても容易にア​カウント乗っ取りができる
[23:13:23] 私は、重要なサービスの MFA はプラットフォーム統合の認証器による Passkey を用いているので
[23:13:38] Apple の TouchID や FaceID でログインできるからむしろログインが楽になるんだよね
[23:13:55] TOTP はめんどい
[23:14:40] 私は、Passkey 用に別にハードウェアウォレットのニーモニックフレーズにより導出される鍵を用いた認証器を用いているので
[23:15:22] 仮に、Apple の端末を全て物理的に失ったとしてもアクセスを失うことがないようにしている
[23:20:15] ハードウェアウォレットのニーモニックフレーズを用いて、ハードウェア上で暗号化／復号化を行い機密情報をブラウザのローカルストレージに格納するタイプの TOTP ベースの Authenticator を自作しようかと考えていたけど
[23:20:20] めんどうで、そこまではやっていない
[23:20:38] Google のブラウザ拡張として実行可能にすれば便利だよね
[23:21:10] パナの件は、コングロマリットディスカウントを避けるためではないのか？
[23:21:36] 複数の事業会社に分割しないと、それぞれの事業を個別に評価するのが難しい
[23:22:01] それは怪しい組織ｗ