@ ec42c765:328c0600

test test

@ ec42c765:328c0600

test

@ ec42c765:328c0600

# カスタム絵文字とは 任意のオリジナル画像を絵文字のように文中に挿入できる機能です。 また、リアクション（Twitterの いいね のような機能）にもカスタム絵文字を使えます。  # カスタム絵文字の対応状況（2025/02/06）  カスタム絵文字を使うためにはカスタム絵文字に対応した[クライアント](https://welcome.nostr-jp.org/tutorial/explore-client.html)を使う必要があります。 ※表は一例です。クライアントは他にもたくさんあります。 使っているクライアントが対応していない場合は、クライアントを変更する、対応するまで待つ、開発者に要望を送る（または自分で実装する）などしましょう。 #### 対応クライアント - [Amethyst](https://play.google.com/store/apps/details?id=com.vitorpamplona.amethyst) - [FreeFrom](https://freefrom.space/) - [nostter](https://nostter.app/) - [Rabbit](https://rabbit.syusui.net/) - [Lumilumi](https://lumilumi.app/) - [Nos Haiku](https://nos-haiku.vercel.app/) - [Snort](https://snort.social/) - [noStrudel](https://nostrudel.ninja/) ここではnostterを使って説明していきます。 # 準備 カスタム絵文字を使うための準備です。 - Nostrエクステンション（NIP-07）を導入する - 使いたいカスタム絵文字をリストに登録する ## Nostrエクステンション（NIP-07）を導入する Nostrエクステンションは使いたいカスタム絵文字を登録する時に必要になります。 また、環境（パソコン、iPhone、androidなど）によって導入方法が違います。 Nostrエクステンションを導入する端末は、実際にNostrを閲覧する端末と違っても構いません（リスト登録はPC、Nostr閲覧はiPhoneなど）。 Nostrエクステンション（NIP-07）の導入方法は以下のページを参照してください。 [ログイン拡張機能 (NIP-07)を使ってみよう | Welcome to Nostr! ～ Nostrをはじめよう！ ～ ](https://welcome.nostr-jp.org/tutorial/nip-07.html) 少し面倒ですが、これを導入しておくとNostr上の様々な場面で役立つのでより快適になります。 ## 使いたいカスタム絵文字をリストに登録する 以下のサイトで行います。 [emojito](https://emojito.meme/) 右上の**Get started**からNostrエクステンションでログインしてください。 例として以下のカスタム絵文字を導入してみます。 実際より絵文字が少なく表示されることがありますが、古い状態のデータを取得してしまっているためです。その場合はブラウザの更新ボタンを押してください。 [generalJP | カスタム絵文字](https://emojito.meme/a/naddr1qqykwetwv4exzmz22qqsuamnwvaz7tmev9382tndv5hsyg8vgtrk2svt8kuusk4l7w5g7j3mhet4xhhthhz52gsyr7jn9rqxqqpsgqqqw48qud6u3s)  - 右側の**Options**から**Bookmark**を選択  これでカスタム絵文字を使用するためのリストに登録できます。 # カスタム絵文字を使用する 例としてブラウザから使えるクライアント nostter から使用してみます。 [nostter](https://nostter.app/) nostterにNostrエクステンションでログイン、もしくは秘密鍵を入れてログインしてください。 ## 文章中に使用 1. **投稿**ボタンを押して投稿ウィンドウを表示 2. **顔😀**のボタンを押し、絵文字ウィンドウを表示 3. **＊タブ**を押し、カスタム絵文字一覧を表示 4. カスタム絵文字を選択 5. : 記号に挟まれたアルファベットのショートコードとして挿入される  この状態で投稿するとカスタム絵文字として表示されます。 カスタム絵文字対応クライアントを使っている他ユーザーにもカスタム絵文字として表示されます。 対応していないクライアントの場合、ショートコードのまま表示されます。  ショートコードを直接入力することでカスタム絵文字の候補が表示されるのでそこから選択することもできます。  ## リアクションに使用 1. 任意の投稿の**顔😀**のボタンを押し、絵文字ウィンドウを表示 2. **＊タブ**を押し、カスタム絵文字一覧を表示 3. カスタム絵文字を選択  カスタム絵文字リアクションを送ることができます。  # カスタム絵文字を探す 先述した[emojito](https://emojito.meme/)からカスタム絵文字を探せます。 例えば任意のユーザーのページ [emojito ロクヨウ](https://emojito.meme/p/npub1a3pvwe2p3v7mnjz6hle63r628wl9w567aw7u23fzqs062v5vqcqqu3sgh3) から探したり、 [emojito Browse all](https://emojito.meme/browse) からnostr全体で最近作成、更新された絵文字を見たりできます。 また、以下のリンクは日本語圏ユーザーが作ったカスタム絵文字を集めたリストです（2025/02/06） ※漏れがあるかもしれません [日本ユーザー作 カスタム絵文字](https://nostviewstr.vercel.app/npub17hczqvxtfv3w69wr6lxrttnpdekwdwel55mld60fr24zwjuu6utqtj8mjx/10030) 各絵文字セットにある**Open in emojito**のリンクからemojitoに飛び、使用リストに追加できます。 ----------- 以上です。 次：Nostrのカスタム絵文字の**作り方** Yakihonneリンク [Nostrのカスタム絵文字の作り方](https://yakihonne.com/article/_@lokuyow.github.io/1707912490439) Nostrリンク nostr:naddr1qqxnzdesxuunzv358ycrgveeqgswcsk8v4qck0deepdtluag3a9rh0jh2d0wh0w9g53qg8a9x2xqvqqrqsqqqa28r5psx3 ----------- # 仕様 [NIP-30 Custom Emoji](https://github.com/nostr-protocol/nips/blob/master/30.md) [NIP-30 カスタム絵文字（和訳）](https://github.com/nostr-jp/nips-ja/blob/main/30.md)

@ ec42c765:328c0600

てすと nostr:nevent1qqst3uqlls4yr9vys4dza2sgjle3ly37trck7jgdmtr23uuz52usjrqqqnjgr nostr:nevent1qqsdvchy5d27zt3z05rr3q6vvmzgslslxwu0p4dfkvxwhmvxldn9djguvagp2 test てｓ

@ ec42c765:328c0600

# カスタム絵文字とは 任意のオリジナル画像を絵文字のように文中に挿入できる機能です。 また、リアクション（Twitterの いいね のような機能）にもカスタム絵文字を使えます。  # カスタム絵文字の対応状況（2025/02/06）  カスタム絵文字を使うためにはカスタム絵文字に対応した[クライアント](https://welcome.nostr-jp.org/tutorial/explore-client.html)を使う必要があります。 ※表は一例です。クライアントは他にもたくさんあります。 使っているクライアントが対応していない場合は、クライアントを変更する、対応するまで待つ、開発者に要望を送る（または自分で実装する）などしましょう。 #### 対応クライアント - [Amethyst](https://play.google.com/store/apps/details?id=com.vitorpamplona.amethyst) - [FreeFrom](https://freefrom.space/) - [nostter](https://nostter.app/) - [Rabbit](https://rabbit.syusui.net/) - [Lumilumi](https://lumilumi.app/) - [Nos Haiku](https://nos-haiku.vercel.app/) - [Snort](https://snort.social/) - [noStrudel](https://nostrudel.ninja/) ここではnostterを使って説明していきます。 # 準備 カスタム絵文字を使うための準備です。 - Nostrエクステンション（NIP-07）を導入する - 使いたいカスタム絵文字をリストに登録する ## Nostrエクステンション（NIP-07）を導入する Nostrエクステンションは使いたいカスタム絵文字を登録する時に必要になります。 また、環境（パソコン、iPhone、androidなど）によって導入方法が違います。 Nostrエクステンションを導入する端末は、実際にNostrを閲覧する端末と違っても構いません（リスト登録はPC、Nostr閲覧はiPhoneなど）。 Nostrエクステンション（NIP-07）の導入方法は以下のページを参照してください。 [ログイン拡張機能 (NIP-07)を使ってみよう | Welcome to Nostr! ～ Nostrをはじめよう！ ～ ](https://welcome.nostr-jp.org/tutorial/nip-07.html) 少し面倒ですが、これを導入しておくとNostr上の様々な場面で役立つのでより快適になります。 ## 使いたいカスタム絵文字をリストに登録する 以下のサイトで行います。 [emojito](https://emojito.meme/) 右上の**Get started**からNostrエクステンションでログインしてください。 例として以下のカスタム絵文字を導入してみます。 実際より絵文字が少なく表示されることがありますが、古い状態のデータを取得してしまっているためです。その場合はブラウザの更新ボタンを押してください。 [generalJP | カスタム絵文字](https://emojito.meme/a/naddr1qqykwetwv4exzmz22qq3uamnwvaz7tmwdaehgun2vykkkctjdyhxset8w4ex7tnrdakj7q3qa3pvwe2p3v7mnjz6hle63r628wl9w567aw7u23fzqs062v5vqcqqxpqqqp65uhjtrk6)  - 右側の**Options**から**Bookmark**を選択  これでカスタム絵文字を使用するためのリストに登録できます。 # カスタム絵文字を使用する 例としてブラウザから使えるクライアント nostter から使用してみます。 [nostter](https://nostter.app/) nostterにNostrエクステンションでログイン、もしくは秘密鍵を入れてログインしてください。 ## 文章中に使用 1. **投稿**ボタンを押して投稿ウィンドウを表示 2. **顔😀**のボタンを押し、絵文字ウィンドウを表示 3. **＊タブ**を押し、カスタム絵文字一覧を表示 4. カスタム絵文字を選択 5. : 記号に挟まれたアルファベットのショートコードとして挿入される  この状態で投稿するとカスタム絵文字として表示されます。 カスタム絵文字対応クライアントを使っている他ユーザーにもカスタム絵文字として表示されます。 対応していないクライアントの場合、ショートコードのまま表示されます。  ショートコードを直接入力することでカスタム絵文字の候補が表示されるのでそこから選択することもできます。  ## リアクションに使用 1. 任意の投稿の**顔😀**のボタンを押し、絵文字ウィンドウを表示 2. **＊タブ**を押し、カスタム絵文字一覧を表示 3. カスタム絵文字を選択  カスタム絵文字リアクションを送ることができます。  # カスタム絵文字を探す 先述した[emojito](https://emojito.meme/)からカスタム絵文字を探せます。 例えば任意のユーザーのページ [emojito ロクヨウ](https://emojito.meme/p/npub1a3pvwe2p3v7mnjz6hle63r628wl9w567aw7u23fzqs062v5vqcqqu3sgh3) から探したり、 [emojito Browse all](https://emojito.meme/browse) からnostr全体で最近作成、更新された絵文字を見たりできます。 また、以下のリンクは日本語圏ユーザーが作ったカスタム絵文字を集めたリストです（2025/02/06） ※漏れがあるかもしれません [日本ユーザー作 カスタム絵文字](https://nostviewstr.vercel.app/npub17hczqvxtfv3w69wr6lxrttnpdekwdwel55mld60fr24zwjuu6utqtj8mjx/10030) 各絵文字セットにある**Open in emojito**のリンクからemojitoに飛び、使用リストに追加できます。 ----------- 以上です。 次：Nostrのカスタム絵文字の**作り方** Yakihonneリンク [Nostrのカスタム絵文字の作り方](https://yakihonne.com/article/_@lokuyow.github.io/1707912490439) Nostrリンク nostr:naddr1qqxnzdesxuunzv358ycrgveeqgswcsk8v4qck0deepdtluag3a9rh0jh2d0wh0w9g53qg8a9x2xqvqqrqsqqqa28r5psx3 ----------- # 仕様 [NIP-30 Custom Emoji](https://github.com/nostr-protocol/nips/blob/master/30.md) [NIP-30 カスタム絵文字（和訳）](https://github.com/nostr-jp/nips-ja/blob/main/30.md)

@ ec42c765:328c0600

# カスタム絵文字とは 任意のオリジナル画像を絵文字のように文中に挿入できる機能です。 また、リアクション（Twitterの いいね のような機能）にもカスタム絵文字を使えます。  # カスタム絵文字の対応状況（2024/02/05）  カスタム絵文字を使うためにはカスタム絵文字に対応した[クライアント](https://welcome.nostr-jp.org/tutorial/explore-client.html)を使う必要があります。 ※表は一例です。クライアントは他にもたくさんあります。 使っているクライアントが対応していない場合は、クライアントを変更する、対応するまで待つ、開発者に要望を送る（または自分で実装する）などしましょう。 #### 対応クライアント - [Amethyst](https://play.google.com/store/apps/details?id=com.vitorpamplona.amethyst) - [FreeFrom](https://freefrom.space/) - [nostter](https://nostter.app/) - [Rabbit](https://rabbit.syusui.net/) - [Snort](https://snort.social/) - [noStrudel](https://nostrudel.ninja/) ここではnostterを使って説明していきます。 # 準備 カスタム絵文字を使うための準備です。 - Nostrエクステンション（NIP-07）を導入する - 使いたいカスタム絵文字をリストに登録する ## Nostrエクステンション（NIP-07）を導入する Nostrエクステンションは使いたいカスタム絵文字を登録する時に必要になります。 また、環境（パソコン、iPhone、androidなど）によって導入方法が違います。 Nostrエクステンションを導入する端末は、実際にNostrを閲覧する端末と違っても構いません（リスト登録はPC、Nostr閲覧はiPhoneなど）。 Nostrエクステンション（NIP-07）の導入方法は以下のページを参照してください。 [ログイン拡張機能 (NIP-07)を使ってみよう | Welcome to Nostr! ～ Nostrをはじめよう！ ～ ](https://welcome.nostr-jp.org/tutorial/nip-07.html) 少し面倒ですが、これを導入しておくとNostr上の様々な場面で役立つのでより快適になります。 ## 使いたいカスタム絵文字をリストに登録する 以下のサイトで行います。 [emojito](https://emojito.meme/) 右上の**Get started**からNostrエクステンションでログインしてください。 例として以下のカスタム絵文字を導入してみます。 実際より絵文字が少なく表示されることがありますが、古い状態のデータを取得してしまっているためです。その場合はブラウザの更新ボタンを押してください。 [generalJP | カスタム絵文字](https://emojito.meme/a/naddr1qqykwetwv4exzmz22qq3uamnwvaz7tmwdaehgun2vykkkctjdyhxset8w4ex7tnrdakj7q3qa3pvwe2p3v7mnjz6hle63r628wl9w567aw7u23fzqs062v5vqcqqxpqqqp65uhjtrk6)  - 右側の**Options**から**Bookmark**を選択  これでカスタム絵文字を使用するためのリストに登録できます。 # カスタム絵文字を使用する 例としてブラウザから使えるクライアント nostter から使用してみます。 [nostter](https://nostter.app/) nostterにNostrエクステンションでログイン、もしくは秘密鍵を入れてログインしてください。 ## 文章中に使用 1. **投稿**ボタンを押して投稿ウィンドウを表示 2. **顔😀**のボタンを押し、絵文字ウィンドウを表示 3. **＊タブ**を押し、カスタム絵文字一覧を表示 4. カスタム絵文字を選択 5. : 記号に挟まれたアルファベットのショートコードとして挿入される  この状態で投稿するとカスタム絵文字として表示されます。 カスタム絵文字対応クライアントを使っている他ユーザーにもカスタム絵文字として表示されます。 対応していないクライアントの場合、ショートコードのまま表示されます。  ショートコードを直接入力することでカスタム絵文字の候補が表示されるのでそこから選択することもできます。  ## リアクションに使用 1. 任意の投稿の**顔😀**のボタンを押し、絵文字ウィンドウを表示 2. **＊タブ**を押し、カスタム絵文字一覧を表示 3. カスタム絵文字を選択  カスタム絵文字リアクションを送ることができます。  # カスタム絵文字を探す 先述した[emojito](https://emojito.meme/)からカスタム絵文字を探せます。 例えば任意のユーザーのページ [emojito ロクヨウ](https://emojito.meme/p/npub1a3pvwe2p3v7mnjz6hle63r628wl9w567aw7u23fzqs062v5vqcqqu3sgh3) から探したり、 [emojito Browse all](https://emojito.meme/browse) からnostr全体で最近作成、更新された絵文字を見たりできます。 また、以下のリンクは日本語圏ユーザーが作ったカスタム絵文字を集めたリストです（2024/06/30） ※漏れがあるかもしれません [日本ユーザー作 カスタム絵文字](https://nostviewstr.vercel.app/npub17hczqvxtfv3w69wr6lxrttnpdekwdwel55mld60fr24zwjuu6utqtj8mjx/10030) 各絵文字セットにある**Open in emojito**のリンクからemojitoに飛び、使用リストに追加できます。 ----------- 以上です。 次：Nostrのカスタム絵文字の**作り方** Yakihonneリンク [Nostrのカスタム絵文字の作り方](https://yakihonne.com/article/_@lokuyow.github.io/1707912490439) Nostrリンク nostr:naddr1qqxnzdesxuunzv358ycrgveeqgswcsk8v4qck0deepdtluag3a9rh0jh2d0wh0w9g53qg8a9x2xqvqqrqsqqqa28r5psx3 ----------- # 仕様 [NIP-30 Custom Emoji](https://github.com/nostr-protocol/nips/blob/master/30.md) [NIP-30 カスタム絵文字（和訳）](https://github.com/nostr-jp/nips-ja/blob/main/30.md)

@ 21ac2956:09d1e2df

## [kakoi](https://github.com/betonetojp/kakoi) の仕様についてのメモ ### キーボード操作 * 左手での操作に最適化 | キー | 動作 | |:-|:-| | ESC | 設定画面 | | F1 / F12 | ポストバーの表示と非表示 | | F2 | 時間の表示と非表示 | | F3 | ユーザーアイコンの表示と非表示 | | F4 | 名前の表示と非表示 | | F5 | Geminiによるタイムラインまとめ画面を表示 | | F9 / Z | コンテンツの折り返し表示の切り替え （余白ダブルクリックでも動作） | | F10 | ユーザーリストとキーワード通知の設定画面 （余白右クリックでも動作） | | F11 | メイン画面の表示と非表示 （ポストバー表示） | | Shift + W | イベント最上行へ移動 | | W / ↑| イベント選択上移動 | | S / ↓ | イベント選択下移動 | | Shift + S | イベント最下行へ移動 | | A / ← | Webビューを開く （イベントを右クリックでも動作） | | F / → | リアクションを送信 （イベントをダブルクリックでも動作） | | 1 ～ 0 | リアクションを選択 | | R | 返信 | | B | リポスト | | Q | 引用 | | C | Webビューを閉じる | | Ctrl + Shift + A | メイン画面をアクティブにする | ### タイムライン * kind:1, 6, 7, 16を取得して表示する * フォロイーの名前の前には * が付く ### フォローリスト（kind:3） * 参照のみで更新はしない * F10 で開くユーザーリストでユーザーを選択し petname セルをクリックすることで未フォローユーザーにもペットネームを設定可能（ローカル保存） ### プロフィール（kind:0） * F10 で開くユーザーリストでユーザーを選択し picture セルをクリックすることでユーザーのアイコン表示を変更可能（ローカル保存） ### 返信（[NIP-10](https://github.com/nostr-protocol/nips/blob/master/10.md) kind:1） * kakoi のタイムラインに流れるすべてのイベント種に返信可能とする * スレッドを考慮せず、単一イベントへの単発返信とする * e タグは marker と返信先 pubkey は設定していない。 relay-url には空文字を設定 ```json ["e", "返信先 event-id", ""] ``` * p タグは 返信先 pubkey ひとつだけを指定 ### リポスト（[NIP-18](https://github.com/nostr-protocol/nips/blob/master/18.md) kind:6 , 16） * kakoi のタイムラインに流れるすべてのイベント種をリポスト可能 * kind:1はkind:6。その他はkind:16でリポストする * e タグは relay-url に空文字を設定 ```json ["e", "リポスト元 event-id", ""] ``` ### 引用（[NIP-18](https://github.com/nostr-protocol/nips/blob/master/18.md) kind:1） * q タグは relay-url に空文字を設定 ```json ["q", "引用元 event-id", ""] ```

@ 101b30ee:18a46a45

--- ### ハンドシェイク - HTTPリクエスト解析 - [ ] HTTPリクエストラインのパーサー関数作成 - [x] HTTPヘッダーのパーサー関数作成 - [ ] HTTPリクエストボディのパーサー関数作成 - [ ] WebSocket関連ヘッダーの検証 - [ ] `Upgrade: websocket` - [ ] `Connection: Upgrade` - [ ] `Sec-WebSocket-Key` の取得と検証 - [ ] `Sec-WebSocket-Version: 13` の検証 - HTTPレスポンス作成 - [ ] `Sec-WebSocket-Accept` の生成 - [x] `Sec-WebSocket-Key` にSHA-1適用(外部依存) - [ ] `Sec-WebSocket-Key` にSHA-1適用(非依存) - [x] `Sec-WebSocket-Key` にBase64エンコードを適用 - [x] HTTP 101 Switching Protocolsレスポンスの構築と送信 --- ### データ転送 #### WebSocketフレームの処理 - フレーム解析 - [x] `fin` ビットの取り出しと解釈 - [x] `rsv1`, `rsv2`, `rsv3` の取り出しと検証 - [ ] `opcode` の取り出しと処理 - [ ] 0x0: 継続フレーム - [ ] 0x1: テキストフレーム - [ ] 0x2: バイナリフレーム - [ ] 0x8: 接続終了 - [ ] 0x9: Ping - [ ] 0xA: Pong - [x] `mask` フラグの取得と検証 - [x] `payload_len` の取り出しと解析 - [x] 拡張されたペイロード長（`extended payload len`）の取り出し - [x] `masking key` の取得とデコード - [x] `payload` データの取り出し - [ ] `fin` に基づく分割パケット対応 - デコード - [x] `masking key` を使用したペイロードデコード - opcode別処理 - [ ] テキストフレーム(0x1)のUTF-8デコードと処理 - [ ] バイナリフレーム(0x2)のデータ処理 - [ ] Ping(0x9)フレームへのPong応答 - [ ] 接続終了(0x8)の処理 - [ ] 不正なopcodeに対するエラー応答 #### フレーム生成 - フレーム構築 - [ ] `fin` フラグ設定 - [ ] `opcode` の設定 - [ ] ペイロードのマスキング処理（クライアント向けのみ） - [ ] ペイロード長の設定（拡張ペイロード長を含む） - [ ] フレーム全体のバイトストリーム化 --- ### 接続管理 - [x] クライアント接続の確立 - [x] 2クライアント以上の接続の確立 - [ ] 接続中のクライアントのリスト管理 - [ ] 接続のタイムアウト処理 - [ ] 不正なクライアントからの接続拒否 - [ ] 接続終了時のクリーンアップ処理 - [ ] ハートビート機能（Ping/Pong）による接続維持 --- ### セキュリティ - [ ] WebSocket Originヘッダーの検証（許可されたオリジンのみ受け入れる） - [ ] メッセージサイズの上限設定（大規模メッセージ攻撃の防御） - [ ] 不正なフレーム/データに対するエラーハンドリング - [ ] SSL/TLSサポート（wssプロトコル用） --- ### 拡張機能とプロトコルアップグレード - [ ] サブプロトコル（Sec-WebSocket-Protocol）の処理 - [ ] 拡張（Sec-WebSocket-Extensions）のサポート - 圧縮データのデコード (例: permessage-deflate) --- ### テストとデバッグ - [ ] 単体テスト - [ ] ハンドシェイクのテスト - [ ] フレーム解析と生成のテスト - [ ] 各opcode処理のテスト - [ ] 負荷テスト（高負荷時の動作確認） - [ ] プロトコルコンフォーマンステスト - [ ] RFC 6455に準拠しているかの確認 - [ ] ロギングとデバッグツールの実装 --- ### ドキュメント - [ ] コードベースのコメントとドキュメント化 - [ ] WebSocketサーバーの設定と使用法についてのユーザーガイド作成 ### タグ #RFC6455

@ 59cb0748:9602464b

Nostrでお世話になっている方も、お世話になってない方も、こんにちは！ タコ頭大吉です！ NIP-23を使った初めての投稿です。 今回は、私がここ数ヶ月中にデザインをした三種類のビタキセケースの紹介記事になります！！ ビタキセを買ったもののあまり自分の好みに合う外観や仕様のケースがなく、いくつかプロトタイプを作りそれなりに時間をかけて考えたケース達です。 これら３シリーズに関しては、FDMタイプの3Dプリンタの精度、耐久性、出力後の作業性を考慮して一つのパーツで完結することに拘って設計をしました。 一定以上の充填率でプリントをすればそれなりに丈夫なはずです。 また、基本的に放熱性と保護性を両立できるように設計をしたつもります。 それぞれのモデルについて簡単に紹介をさせていただきますので、よろしければ各リポジトリに付属のREADMEを読んでいただいて自作、フィードバックをいただけましたら幸いです。 それでは、簡単に各モデルの紹介をさせていたきます。 ----------- ## AirLiftFrame  最初に作ったモデルです！ 少し大きいのが難点ですが、分厚めのフレームをベースとし基盤周辺をあえて囲わない設計により、保護性と放熱を阻害しない事の両立を狙っています。 [リポジトリへ](https://github.com/tko-combinator/BitaxeAirLiftFrame) ----------- ## TwinAirLiftFrame  ビタキセを買い増ししたことにより、複数台をカッコよく運用したいという需要が自分の中に出てきたので、AirLiftFrameを2つくっつけたら良いのではと言うごくごく単純な発想でつくり始めたケースです。 しかし、ただ横並びにしただけでは廃熱が干渉するだけではなく、DCジャックやUSBポートへのアクセスが阻害されるという問題にすぐに気がつきました。 そこで、WebUI上でディスプレイの表示を上下反転出来ることに注目し、2台を上下逆向きに取り付ける事でそれらの問題を解決しました！ [リポジトリへ](https://github.com/tko-combinator/BitaxeTwinAirLiftFrame) ----------- ## VoronoiShell  AirLiftFrameシリーズのサイズを小型化する事から始めたプロジョクトです。 縦横の寸法の削減だけではなく、厚みを薄くつくリたいという希望がありました。 所が単純に薄くすると、持った時に発熱する背面パーツに手が触れてしまったり、落下などでぶつかった際に背面パーツが破損する懸念がありました。 そこで、(当初は付けたくはなかった)背面保護用のグリルをデザインする必要が出てきました。 初めは多角形でしたがあまりにもダサく、調べている内にVoronoi柄という有機的なパターンに行き付き即採用しました。 結果、ビタキセを取り付けると柄が見えなくなるのが勿体無いぐらい個性的でスタイリッシュなデザインに仕上がりました。 [リポジトリへ](https://github.com/tko-combinator/BitaxeVoronoiShell) ----------- いずれカスタム方法やインサートナットや増設ファンの選定方法等を紹介したいのですが、今回はNIP-23になれるという意図もあるので紹介に留めます！ また、他の関連OSハードウェアプロジェクトのケースもデザインできたらと思っております！ 今後ともタコ頭をよろしくお願いいたします。

@ 84b0c46a:417782f5

- [lumilumi](https://lumilumi.app/) The Nostr Web Client. Lightweight modes are available, such as not displaying icon images, not loading images automatically, etc. - [nostr-share-component](https://github.com/TsukemonoGit/nostr-share-component) [Demo](https://tsukemonogit.github.io/nostr-share-component/) - [Nostr Follow Organizer](https://tsukemonogit.github.io/NFO/) Follow List ( kind3 ) organization tool. - [NAKE](https://github.com/TsukemonoGit/nake) NIP-19, NIP-49 Encode/Decode Tool - [chrome extension](https://chromewebstore.google.com/detail/nake/pckmdjknadbfalfohabbccmffoohlamk) - [firefox add-on](https://addons.mozilla.org/ja/firefox/addon/nake/) - [nostviewstr](https://nostviewstr.vercel.app/) Addressable or Replaceable Event Editor ( いろんなリストエディター ) - [luminostr](https://tsukemonogit.github.io/luminostr/) Addressable or Replaceable Event Recovery tool ( いろいろリカバリーツール ) - [Nostr Bookmark Recovery Tool](https://nostr-bookmark-recovery-tool.vercel.app/) Bookmark event ( kind:10003,30001,30003 ) recovery tool ( ぶくま復活させたいやつ ) - [Profile Editor](https://nos-profile-arekore.vercel.app/) プロフィールを編集するやつ - [nostr-bookmark-viewer](https://nostr-bookmark-viewer3.vercel.app/) Bookmark event ( kind:10003,30001,30003 ) Editor ( ぶっくまーくをみるやつ ) - [Nostr Note Duplicater](https://dupstr.vercel.app/) Broadcast an event from relay to relay ( イベントをブロードキャストするやつ ) - [もの画像サイト](https://tsukemonogit.github.io/nostr-monoGazo-bot/) - [いろいろbotサイト](https://tsukemonogit.github.io/iroirotest/)

@ 21ac2956:09d1e2df

スペース2つ＋改行→ 改行2つ→ ハードブレイク→<br>いかがでしたか？

@ 32310997:0c1e64cc

※このポエムは[Nostr Advent Calendar 2024]( https://adventar.org/calendars/10004)の25日目の記事です。24日目は[tansaibow]( https://nostter.app/tansaibow@tansaibow.com)さんのご担当です。 ----------- **この鍵ひとつあれば**<br> **僕はどこにだってゆける**<br> **なんだってできる**<br> <br> **さぁ進もう**<br> **この曠野を**<br>  （※画像はイメージです。本文とはたいして関係がありません）

@ ec42c765:328c0600

この記事は前回の内容を把握している人向けに書いています（特にNostrエクステンション（NIP-07）導入） 前回：[Nostrのカスタム絵文字の使い方](https://yakihonne.com/article/_@lokuyow.github.io/xVMTZxHcV_NWKuTbDBUYs) # 手順 1. 登録する画像を用意する 2. 画像をweb上にアップロードする 3. 絵文字セットに登録する ## 1. 登録する画像を用意する 以下のような方法で用意してください。 * 画像編集ソフト等を使って自分で作成する * 絵文字作成サイトを使う（[絵文字ジェネレーター](https://emoji-gen.ninja/)、[MEGAMOJI](https://zk-phi.github.io/MEGAMOJI/) など） * フリー画像を使う（[いらすとや](https://www.irasutoya.com/) など） ### データ量削減 Nostrでは画像をそのまま表示するクライアントが多いので、データ量が大きな画像をそのまま使うとモバイル通信時などに負担がかかります。 データ量を増やさないためにサイズやファイル形式を変更することをおすすめします。 以下は私のおすすめです。 * サイズ：正方形 128×128 ピクセル、長方形 任意の横幅×128 ピクセル * ファイル形式：webp形式（webp変換おすすめサイト [toimg](https://toimg.kakechimaru.com/to-webp)） * 単色、単純な画像の場合：png形式（webpにするとむしろサイズが大きくなる） ### その他 * 背景透過画像 * ダークモード、ライトモード両方で見やすい色 がおすすめです。 ## 2. 画像をweb上にアップロードする よく分からなければ [emojito](https://emojito.meme/) からのアップロードで問題ないです。 普段使っている画像アップロード先があるならそれでも構いません。 気になる方はアップロード先を適宜選んでください。 既に投稿されたカスタム絵文字の画像に対して - 削除も差し替えもできない → [emojito](https://emojito.meme/) など - 削除できるが差し替えはできない → [Gyazo](https://gyazo.com/)、[nostrcheck.me](https://nostrcheck.me/)など - 削除も差し替えもできる → [GitHub](https://github.com/) 、セルフホスティングなど これらは既にNostr上に投稿されたカスタム絵文字の画像を後から変更できるかどうかを指します。 どの方法でも新しく使われるカスタム絵文字を変更することは可能です。 同一のカスタム絵文字セットに同一のショートコードで別の画像を登録する形で対応できます。 ## 3. 絵文字セットに登録する [emojito](https://emojito.meme/) から登録します。 右上の**アイコン** → **+ New emoji set** から新規の絵文字セットを作成できます。   #### ① 絵文字セット名を入力 基本的にカスタム絵文字はカスタム絵文字セットを作り、ひとまとまりにして登録します。 一度作った絵文字セットに後から絵文字を追加することもできます。 #### ② 画像をアップロードまたは画像URLを入力 emojitoから画像をアップロードする場合、ファイル名に日本語などの2バイト文字が含まれているとアップロードがエラーになるようです。 その場合はファイル名を適当な英数字などに変更してください。 #### ③ 絵文字のショートコードを入力 ショートコードは絵文字を呼び出す時に使用する場合があります。 他のカスタム絵文字と被っても問題ありませんが選択時に複数表示されて支障が出る可能性があります。 他と被りにくく長くなりすぎないショートコードが良いかもしれません。 ショートコードに使えるのは半角の英数字とアンダーバーのみです。 #### ④ 追加 **Add** を押してもまだ作成完了にはなりません。  一度に絵文字を複数登録できます。 最後に右上の **Save** を押すと作成完了です。  画面が切り替わるので、右側の **Options** から **Bookmark** を選択するとそのカスタム絵文字セットを自分で使えるようになります。 既存の絵文字セットを編集するには **Options** から **Edit** を選択します。 以上です。 ----------- # 仕様 [NIP-30 Custom Emoji](https://github.com/nostr-protocol/nips/blob/master/30.md) [NIP-30 カスタム絵文字（和訳）](https://github.com/nostr-jp/nips-ja/blob/main/30.md)

@ 2cb8ae56:84d30cba

ども、薄味のキャルピスでございます。<br>当記事は、「Nostr Advent Calendar 2024」7日目の記事です。 <br> この記事を読んでいる人でいないとは思いますが、Nostrとはなんぞやとお思いの方は以下をご覧ください。 https://hello.nostrapp.me/ 僕は「Nostrで過ごした2024年」というタイトルの通り、一年間を振り返ってみようと思います。 <h2>自己紹介</h2> まず知らん人のために軽く自己紹介をします 「薄味のキャルピス」という名前で、色んな所にいるどこかの高校生です。 左利き、箸とベースとお盆は右手。 普段は学業の傍ら、画像を弄ったり作ったりしている上に、イヤホンを集めたりラジオにメッセージを送っています。 コーディングは出来ないテクノロジーまみれのガラクタ人間（→テックジャンカー）です <h2>参加経緯とスタンス</h2> なぜ参加したのかを思い出しながら書いていきます まず、どんな媒体でNostr（ノスター・ノストラ）の存在を知ったのかと言うと、ネットニュースです。 https://gigazine.net/news/20230425-nostr-intro/ こちらの記事で「そんなのあるんだ」と知り、4月1日ついにjoin!!!!  現時点での参加スタンスは「気楽に、素直に」という感じで参加しています やりたいときにやりたいことをやるって言うリアルでは到底難しいことを、Nostrのなかでやっている気もします。 後述するNostrasia 2024の開催日「9月23日」を持って、Mastodon（マストドン）から乗り換え、上記のスタンスのもと、メインで精力的に活動しています。 <h2>Nostr活動年表</h2> 2024/04/01 Nostr Join!!! 2024/06/08 人生初オフ会「たくろうさんオフ」参加、LNアドレス追加。 2024/09/23 人生初小規模イベント「Nostrasia 2024」運営メンバーとして参加 2024/10/12 2度目のオフ会「デザイン談義」主催・参加 <h2>簡易的に各種紹介！</h2> <h3>人生初オフ会「たくろうさんオフ」</h2> 渋三魚金でご飯→猿田彦珈琲でリラックス、Linux使ってると話を切り出す（唐突）→スクランブル交差点で解散。 ウォークマンの再生画面を送付した投稿を行う <h3>人生初イベント「Nostrasia 2024」</h3> あ、記事出したので見てください。 <h3><a href="https://aurtun.hatenablog.com/entry/nostrasia2024-r1">初版<br></a></h3> <h3><a href="https://aurtun.hatenablog.com/entry/nostrasia2024-r2">第二版</a></h3> <h3>2度目のオフ会「デザイン談義」</h3> 秋葉原の「創作空間caféアトリエ あきば店」で行われたオフ会。 ちょくちょく内容を上げているので、見ていってください。 https://nostter.app/npub19ju2u4sduewta4hxl22kke7se8yxm2puytzw47lr6y999pxnpjaqtjjfxj/2024/10/12 終了後、e☆イヤホン 秋葉原店にて、BTR13の在庫状況を確認し、在庫がないため予約しました。 （10月24日到着） 雑多すぎますが、一応こんな感じで大丈夫かな？ <h3>まとめ</h3> 僕がNostrに出会い、Nostrにのめり込むまでの話はいかがだったでしょうか。 Nostrに入る前、オフ会に参加するまでは「ネットにロクな人なんていない！」と思っていましたが、Nostrは違いましたね。 いい意味で期待はずれ、本当にいい人たちばかりで、とにかく自然体で接することができるSNSであると感じました。 そんな世界にぜひとも一回足を踏み入れてみてはいかがでしょうか？ それではまた、来年のアドベントカレンダー、及び開催されましたら「Nostrasia 2025」でお会いしましょう。

@ ec42c765:328c0600

てすと nostr:nevent1qqst3uqlls4yr9vys4dza2sgjle3ly37trck7jgdmtr23uuz52usjrqqqnjgr nostr:nevent1qqsdvchy5d27zt3z05rr3q6vvmzgslslxwu0p4dfkvxwhmvxldn9djguvagp2

@ ec42c765:328c0600

[Nostr Advent Calendar 2024](https://adventar.org/calendars/10004) の 12日目の記事です。 昨日の 12/11 は きりの さんの [2024年のNostrリレー運営を振り返る](https://zenn.dev/imksoo/articles/92be671d734551) でした。 # nostr-zap-view 作った リポジトリ: https://github.com/Lokuyow/nostr-zap-view/ 動作確認ページ: https://lokuyow.github.io/nostr-zap-view/ ## それ何？ 特定の誰かや何かに宛てたZap（投げ銭）を一覧できるやつ を 自分のWebサイトに設置できるやつ --- 自分のサイトに設置した例 * SNSリンク集ページ（最下部）: https://lokuyow.github.io/ * おいくらサッツ（Zap一覧ボタン）: https://osats.money/ * 今日からビットコ（最下部）: https://lokuyow.github.io/btc-dca-simulator/ ## なんで作ったの？ 私の去年のアドベントカレンダー 【Nostr】Webサイトにビットコインの投げ銭ボタンを設置しよう【Zap】 https://spotlight.soy/detail?article_id=ucd7cbrql/ が前提になってるけど長いので要約すると * ZapするやつはあるけどZap見るやつがないので欲しい * ZapをNostr（の典型的なkind:1クライアント）内だけに留めるのはもったいない * Webサイトの広告うざいからZap（的な何か）で置き換わって欲しい ## お前だれ？ 非エンジニア、非プログラマー AIにコード出させてるだけ人 ## 作った感想 できた ## 作った感想2 完成してから気付いた本当に作りたかったもの こういうところにそのままZapを表示できる感じにしたい  （ここまでちゃんとした商業ブログでなく）個人のブログやHPの端っこに「Sponsored by」欄があって名前が表示される感じ もうZapっていう文字もビットコインっていう文字もNostrも出さなくていいし説明もしなくていいのでは感がある イメージはWebサイトを対象にした[ニコニ広告](https://dic.nicovideo.jp/id/1314224) + [スーパーチャット](https://www.asobou.co.jp/blog/life/superchat) + [祭りとか神社の奉納者一覧](https://www.google.com/search?q=%E7%A5%AD+%E5%A5%89%E7%B4%8D%E8%80%85+%E4%B8%80%E8%A6%A7&tbm=isch) --- で思ったのは 個人からの投げ銭なら推し活的なものにしかならないけど 企業がNostrにアカウントを作ってサイトに投げ銭をしたら企業の広告になるんでは！？ ~~企業がNostrにアカウントを！？デリヘルしか見たことない！~~ ## 今後 思いつき、予定は未定 * ボタン→ダイアログ形式でなくバナー、Embed形式にしてページアクセスですぐ見れるようにする * 多分リレーに負荷がかかるのでなんかする * Zapの文字は出さず「Sponsored by」等にする * 単純な最新順でなくする * 少額Zapをトリミング * 一定期間（一か月など）ごとで金額順にソート * 多分リレーに負荷がかかるのでなんかする * 今は投稿宛てのZapをWebサイト宛てのZapと勝手に言い張ってるだけなのでちゃんとWebサイト宛てのZapにする * NIPの提案が必要 * ウォレットの準拠も必要 * リレー（wss://~）宛てのZapもできてほしい ## 将来 インターネットのすべてに投げ銭をさせろ --- **おわり** 明日は mono さんの [Open Sats 申請編](https://zenn.dev/konemono/articles/cb39fb7f302551) です！！

@ 8fb140b4:f948000c

After nuking my second LND node (the first one died due to hardware failure) by my own typo and lack of any thought in the design of the CLI of LND lightning node tools, I decided to take a plunge into the world of mature and complex implementation of the protocol, [Eclair by ACINQ](https://github.com/ACINQ/eclair). It has been almost one year (the birth of the node was on Christmas Day 2023), 50 thousand transactions routed, and over 30 BTC of routed value. In this post, I'd like to reflect on my experiences with Eclair, go over some of the gotchas and issues, and highlight some of the good choices that I've made since the beginning of my adventure. ## Learnings from the Past Experience While I was learning Lightning network and had very little understanding of how things worked in the whole Bitcoin space, Umbrel was my go-to solution that helped me get off the ground. It proved to be easy and somewhat educational but was not something that I would continuously run for the production setup or trust with any significant amount of bitcoin that I could not afford to lose. Lightning is built on top of the L1 (Bitcoin) network but manages the state of the channels in its own database that is negotiated and agreed upon with its peers. Any failures in the state integrity may result in the complete loss of liquidity or hefty penalty transactions (significant loss of capital). A Lightning node that participates in routing public transactions is also required to be constantly online with as little downtime as possible and only short periods offline at a time. Otherwise, you may risk causing force-closure of the channel due to expired HTLC that is measured in number of blocks. ## The Setup Taking all of my learnings into consideration, I decided to first invest in reliable enterprise-grade hardware: - Server-grade hardware with ECC memory and reliable power supply and CPU - UPS (Uninterruptible Power Supply) to avoid any headaches due to electrical spikes or drop-outs - Reliable enterprise SSDs and NVMEs - ZFS (filesystem) to mirror the critical storage and to ensure full integrity of the data (bit-rot prevention). You do need to tune ZFS for your specific workload and reliability - Reliable and replicated database (PostgreSQL) with two local and one remote replica, and a requirement to have at least two replicas committing the transaction to the disk - Backup! On-site and off-site backup of the critical configuration that you could use to restore the node if your house burns down - Spare parts, redundancy, backup, monitoring - Reliable and stable internet connectivity The software is Eclair 0.11.0 (latest release as of today), PostgreSQL 16 with two replicas, Bitcoin Core 27.2 (with redundant storage of blocks), additional Bitcoin Core running on a separate node and in-sync with the chain (in case primary node fails), Ubuntu 22.04 with the latest docker software from the official Docker repo. ## All Major Gotchas That I Came Across While Eclair is mature and very stable in itself, it does have some quirks and design choices that you need to account for when running your node. The software is written in Scala and requires a specific version of JVM to run it, as well as JRE and Maven to build it. It doesn't mean that other versions won't work, but you may find unpleasant bugs that may result in catastrophic failures of your node with nobody to help you. All of the requirements are listed in the release notes and installation guide. Whenever in doubt, **RTFM** first, then ask questions. ### Limited Support by the FOSS Community Eclair is not the most popular implementation of the Lightning protocol, and therefore it is hard to find tools or plugins that could help you manage the node. GUI for the node so far is only supported by RTL and with a very limited number of features. For any sort of statistics, you are limited to either Prometheus (extensive metrics are available) or writing your own SQL on top of the Eclair tables. ### On-chain Fee Differences Between Yours and Partner Nodes This one hit me hard, and many times. I've had more than a few force-closures of the channels because of the conservative and safe default settings. The worst part is, it strikes you when there is a huge spike in fees, which results in significant losses to force-close the channel due to high fees. I am still not 100% sure how the big difference can be exploited in practice, and opted for increase of the tolerance levels to avoid surprise FCs: ``` eclair.on-chain-fees { feerate-tolerance { ratio-low = <0.01~> // will allow remote fee rates as low as XX our local feerate (spikes) ratio-high = <20.0~> // will allow remote fee rates as high as XX times our local feerate (drops) } } ``` It is up to you and your risk tolerance to define something reasonable and yet allow for secure and reliable node operation. ### Initial Lightning Network State Sync When I just started running the node, I had very few channels and startup times were fast. Later, when I expanded the number of channels, I noted that it took my node up to 6-12 hours before it was fully in-sync and routing traffic fast. Given that ACINQ maintains one of the largest nodes on the network, I knew that there was something with my settings that caused the issue. After some research, I came across the setting that whitelisted node IDs for state sync, which immediately rang a bell since I knew from the LND days that not all peer nodes are used for the network sync. Setting the list to my most reliable and largest nodes reduced the startup settling times down to minutes again: ``` eclair.sync-whitelist = [ "03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f", ... ] ``` You do not need to have too many public keys in here, and should keep it between 5-10. ### Automatic MAX HTLC Adjustment for the Channel One of the killer features of Eclair is its ability to automatically adjust MAX HTLC for the channel and reduce the number of failed transactions due to insufficient liquidity on the channel. It can be used to estimate your total channels' balances but with smart configuration and a little thinking, you can make it reasonably private while still maintaining a good transaction flow: ``` eclair.channel.channel-update.min-time-between-updates=1 hour # Allows for the adjustments to be made once every hour eclair.channel.channel-update.balance-thresholds=[ { available-sat = 10000 max-htlc-sat = 0 // 0% of 10000 }, ... ] ``` You can have as many variations as you need, and ensure that the channel MAX HTLC is set well and within reasonable ranges. You would also want to account for multiple transactions going through the channel, but also account for the channel size and an average amount of sats per transaction. ### Max Accepted HTLCs By design, the Lightning channel is limited to a specific number of in-flight HTLCs, and the setting is fixed during channel opening time with no way of changing it unless you close and reopen the channel with new settings. If you find your node routing a lot of small transactions (zaps), you may quickly fail many due to that limit (I think default was in single digit range): ``` eclair.channel.max-htlc-value-in-flight-percent=98 # Default I think is half or 50% eclair.channel.max-accepted-htlcs = 50 ``` The setting above will allow for the channel to be more fully utilized and have more concurrent transactions without clogging. ### CLTV Delta This is basically a setting that is global for Eclair and sets the maximum number of remaining blocks (in time) before HTLC expires. Setting this too high may result in many HTLCs failing for the small nodes with not so great centrality, and reduce the number of routed transactions: ``` # CLTV delta eclair.channel.expiry-delta-blocks = 60 ``` Default is 144 but I found that setting this to 60 (minimum possible for my node setup and configuration) yields better results for routing. It does expose you to more risk of expired HTLCs that may cause force-closures, but I have seen only one so far on my node. ### Allocate Sufficient Memory You will want to adjust the heap size for Eclair, since the default is too small to run any sizable node. Setting `JAVA_OPTS=-Xmx32g` (or half the size of your available RAM) would be a good start. I would advise having at least 32GB of RAM for the node, and allocating at least 16GB (`JAVA_OPTS=-Xmx16g`) for smooth and fast operations. ### And More Settings and Parameters to Tune I have covered only some of the major settings that I felt were worth writing about, but there is much more you could configure and tweak. Read all of the [Guides](https://github.com/ACINQ/eclair/blob/master/docs/Guides.md) and especially focus on the [Configure](https://github.com/ACINQ/eclair/blob/master/docs/Configure.md) and a [sample reference configuration file](https://github.com/ACINQ/eclair/blob/master/eclair-core/src/main/resources/reference.conf). ## Good Decisions First, going with Eclair was the right choice, along with using server-grade hardware with ECC RAM and reliable storage. Second, having a replicated database on three separate nodes with one off-site saved me from a sure destruction of all state and loss of funds. Third, deciding to only maintain channels with reliable and stable nodes saved me from some bad force-closures, where I would choose to close the channel if a peer node goes up and down too frequently, regardless of how well it routes. Even big nodes run by single operators fail badly, as do nodes operated by companies. Keeping your eyes on the node and its health, as well as the health of its peers, is something that very few operators do, which can cause failures and unnecessary loss of your and their funds. Lastly, if you decide to run a routing node, you have a responsibility to maintain it well and monitor its health. There are many tools you could use, and with Eclair you can use Prometheus and Grafana. Keep your node's packages updated and monitor for any security-related issues that may appear from time to time, so you can mitigate them quickly. ## Conclusion So far I am satisfied with Eclair despite all of the difficulties and headaches I've had with it. It is not perfect, and it requires me to create small tools to do some basic things, but I need a stable and reliable node that I can trust. Eclair has proved to be all that I wanted, and saved my bacon a few times when I nuked one of the PostgreSQL servers and all of its data, and managed to do the same for another replica, but was able to recover and recreate from the remaining replica. Eclair is also stateless during runtime and guarantees consistency of the node regardless of how it fails. Even if you pull a plug on the node's server, it will still be able to come up and recover its consistent state that is in agreement with its peers. **Is it for everyone?** No, it is definitely not for everyone or for anyone who just wants a small node to run their online shop with a few channels. You could have a very reliable and trusted node for the online shop with Eclair, but you will need some technical skills to be able to set up, maintain and recover it if things go wrong. In the end, it is all up to you, your skills, your willingness to learn, and your risk tolerance to make that decision. For me, it was the right choice, and I have no regrets despite not having access to the latest shiny features of the Lightning network.

@ 6b0a60cf:b952e7d4

## フォロワーリストを低コストで取得する仕様を考える [Nostr リレーはフォロワー数をカウントしたほうが良い](https://fivebythree.net/project/clusteringcoeff/countingfollowed/)を受けて考えたことを雑多に書き留めておきます ### 単一リレーの場合 #### [NIP-45](https://github.com/nostr-protocol/nips/blob/master/45.md) COUNT を使う ##### 短所 - 単一リレーで数えた総数でしかない - 現時点では数を返すのみ - 複数リレーでマージできるように[idsを一緒に返そう](https://github.com/nostr-protocol/nips/issues/765)という提案もある #### {"#p": ＜pubkey＞, "kinds": [3]} でREQする ##### 短所 - 単一リレーで数えた総数でしかない - フォロワーの数だけクソデカイベントが返ってくるので時間がかかるしギガが減る ### 複数リレーの場合 #### {"#p": ＜pubkey＞, "kinds": [3]} でREQする ##### 長所 - 複数リレーでマージできる - そこそこもっともらしいフォロワーリストが取れる ##### 短所 - 一度でもフォローをしたことがある人のリストでしかない(後にアンフォローしたかもしれない) - nostr:nevent1qqs829n0s3qa3wegnhpf6haz3t87hn9huznldd4x2ld6c0d02uq09gsge47l7 - リストすべての公開鍵で接続リレーとkind3を調べ直してアンフォローされている場合を除く処理をすればそこそこ正確になる - 大変すぎる - 未調査のリレーにフォロワーがいるかもしれない ## 新しいkind(フォロワーを格納する)を新設する 仮にkind1003とする kind3と同じ構造とする ``` { "kind": 1003, "pubkey": "＜Aさんの公開鍵＞", "tags": [ ["p", "＜Bさんの公開鍵＞"], ["p", "＜Cさんの公開鍵＞"], ["p", "＜Dさんの公開鍵＞"] ], // other fields... } ``` で、これ**誰**が作るの？ ### リレーが作る - pubkeyにはAさんの公開鍵を入れることになるけど、署名するにはAさんの秘密鍵が必要だよ？ - 無理 ### クライアントが作る - Rabbitやnostter等のクライアントにはプロフィール画面でフォロワーのところをクリックするとフォロワーの取得が始まる - その際、構築したフォロワーリストをkind1003イベントとしてリレーに送ってしまえば良い - リレー毎でなく複数リレーのマージした結果であるが、その方が有用だろう - でもkind1003を作成した時期はアカウント毎にバラバラになってしまうね ### 誰が嬉しいの？ - クライアントは恩恵を受けない - 本来kind1003の恩恵を受けるべきクライアント自身がkind1003を作らなくてはならない - 統計調査に興味がある人が満足する - そのためだけに各クライアントを使用するユーザーの端末のリソースを使う価値があるかどうか ## そもそもリレーである必要があるだろうか - リレーはシンプルであるべきだが、リレーに高機能を求めること自体は否定されるべきことではない - [NIP-50](https://github.com/nostr-protocol/nips/blob/master/50.md)のように検索に特化したリレーもある でもこの統計情報ってWebSocketで送られてくるべきものだろうか？HTTPで良くない？ リレーである必要すらなくて、REST APIを提供するサービスがあれば十分だよね？ 外部サービスとして独自にデータを集めているサービスは既にある - [Nostr検索ポータル](https://nostr.buta3.net/) ## これをNIPにする必要があるだろうか - WebSocketやリレーが登場しないからといってNIPに定義してはいけないなんてことはない - 例: [NIP-96](https://github.com/nostr-protocol/nips/blob/master/96.md) - しかしNIPというのは仕様を共通化して共有するためのものであり、複数の実装を期待するものである - 統計API提供サービスなど1つあれば十分で、耐検閲性を目的として10個も100個も存在を期待されるものではない

@ e0a8cbd7:f642d154

これは「[Nostr Advent Calendar 2024](https://adventar.org/calendars/10004)」５日目(12月5日)の記事です。 <br><br> 2024年にNostrにのみ投稿した絵で今年を振り返りたいと思います。 あえて、タイトルのみで、なぜその絵を描いたかなどの絵の説明は書かないことにします。 <br><br> 1月2日 ブルルッチモ大噴火！<br>  <br><br> 1月9日 Macの箱を開けながら、ギャォォォォンって叫ぶぺぇさん。<br>  <br><br> 1月12日 便器の上で踊るサボテンになったぽーまんさん。<br>  <br><br> 1月15日 空飛ぶつるるん。<br>  <br><br> 1月23日 ぽわどん<br>  <br><br> 1月26日 Lokuyow said "I am a pen."<br> <br><br> 1月28日 ロクヨウ「早く人間にのりたい」<br>  <br><br> 1月31日 小さなmonoから大きなmonoまで<br>  <br><br> 2月1日 しおさん、巨象恐怖症<br>  <br><br> 2月1日 枕を積んで寝るDonさん。<br>  <br><br> 2月4日 ブロッコリの逆襲<br>  <br><br> 2月8日 びっとこダチョ太郎<br>  <br><br> 2月13日 虹色カレーを食べて虹色になったロクヨウさん<br>  <br><br> 2月13日 ロクヨウさん誕生秘話<br>  <br><br> 3月5日 人参と椎茸たべるロクヨウさん<br>  <br><br> 3月5日 まきうさん、ロクヨウさんに乗って東京へ<br>  <br><br> 3月26日 ごはんの上のめんたいこぽーまん<br>  <br><br> 3月26日 ポワニッチモ<br>  <br><br> 4月4日 上司にズラしていくことを許可されて朝の悩みが増えたぺえさん<br>  <br><br> 5月7日 とうふさんが演じる「お洋服とっかえひっかえして遊ぶりとりんとやぶみん」<br>  <br><bR> 6月20日 ソファーと一体化するポーマンさん<br>  <br><br> 6月21日 つるるん食べていい？<br>  <br><br> 6月28日 ぽーまんさん、たいきんのまい<br>  <br><br> 7月5日 ソファから剥がれて出発するぽーまんさん<br>  <br><br> 8月10日 ぽーまんさん、床のコスプレ<br>  <br><br> 8月18日 アルパカプリン<br>  <br><br> 8月23日 とうふさんが演じるやぶみちゃんの日<br>  <br><br> 8月23日 神妙な顔のぽ－まんさん<br>  <br><br> 8月26日 恋のアルパカキューピット<br>  <br><br> 8月27日 仲良く激辛火鍋<br>  <br><br> 8月28日 Microsoftが「Mono」をWineチームに寄贈<br>  <br><br> 9月12日 もの発射<br>  <br><br> 9月19日 ロクヨウさんヒツジ化<br>  <br><br> 9月20日 ゴリラ食べてバナナになったロクヨウさん<br>  <br><br> 10月13日 頭が増えるぽーまんさん<br>  <br><br> 10月24日 カメムシと青いうさぎ<br>  <br><br> 10月25日 ATMとお話しするポーマンさん<br>  <br><br> 10月26日 パペェ<br>  <br><br> 10月26日 ぺどがわさん<br>  <br><br> 11月7日 伸び縮みぺぇ<br>  <br><br> 11月10日 座布団で寝るぽーまんさん<br>  <br><br> 11月17日 5等分のぽーまん<br>  <br><br> 11月27日 ルンバブルな部屋<br>  <br><br> 11月28日 ７人のぽーまん、那月さんに祓われる<br>  <br><br> 11月29日 捕鯨ぽーまん<br>  <br><br> 11月30日 ぽーまんさん脳内のゴミカスサンバ♪<br>  <br><br> 楽しい1年でした。<br> Nostrのみなさま、たのしい話題をありがとうございます。<br><br> 明日の「[Nostr Advent Calendar 2024](https://adventar.org/calendars/10004)」は、OHASHI Hideyaさんです。<br>しーゆー。

@ 21ac2956:09d1e2df

## [kakoi](https://github.com/betonetojp/kakoi) の仕様についてのメモ ### キーボード操作 * 左手での操作に最適化 | キー | 動作 | |:-|:-| | ESC | 設定画面 | | F1 / F12 | ポストバーの表示と非表示 | | F2 | 時間の表示と非表示 | | F3 | ユーザーアイコンの表示と非表示 | | F4 | 名前の表示と非表示 | | F9 / Z | コンテンツの折り返し表示の切り替え （余白ダブルクリックでも動作） | | F10 | ユーザーリストとキーワード通知の設定画面 （余白右クリックでも動作） | | F11 | メイン画面の表示と非表示 （ポストバー表示） | | Shift + W | イベント最上行へ移動 | | W / ↑| イベント選択上移動 | | S / ↓ | イベント選択下移動 | | Shift + S | イベント最下行へ移動 | | A / ← | Webビューを開く （イベントを右クリックでも動作） | | F / → | リアクションを送信 （イベントをダブルクリックでも動作） | | 1 ～ 0 | リアクションを選択 | | R | 返信 | | B | リポスト | | Q | 引用 | | C | Webビューを閉じる | | Ctrl + Shift + A | メイン画面をアクティブにする | ### タイムライン * kind:1, 6, 7, 16を取得して表示する * フォロイーの名前の前には * が付く ### フォローリスト（kind:3） * 参照のみで更新はしない * F10 で開くユーザーリストでユーザーを選択し petname セルをクリックすることで未フォローユーザーにもペットネームを設定可能（ローカル保存） ### プロフィール（kind:0） * F10 で開くユーザーリストでユーザーを選択し picture セルをクリックすることでユーザーのアイコン表示を変更可能（ローカル保存） ### 返信（[NIP-10](https://github.com/nostr-protocol/nips/blob/master/10.md) kind:1） * kakoi のタイムラインに流れるすべてのイベント種に返信可能とする * スレッドを考慮せず、単一イベントへの単発返信とする * e タグは marker と返信先 pubkey は設定していない。 relay-url には空文字を設定 ```json ["e", "返信先 event-id", ""] ``` * p タグは 返信先 pubkey ひとつだけを指定 ### リポスト（[NIP-18](https://github.com/nostr-protocol/nips/blob/master/18.md) kind:6 , 16） * kakoi のタイムラインに流れるすべてのイベント種をリポスト可能 * kind:1はkind:6。その他はkind:16でリポストする * e タグは relay-url に空文字を設定 ```json ["e", "リポスト元 event-id", ""] ``` ### 引用（[NIP-18](https://github.com/nostr-protocol/nips/blob/master/18.md) kind:1） * q タグは relay-url に空文字を設定 ```json ["q", "引用元 event-id", ""] ```

@ d7c6d014:a6abb6b8

こんにちは！kohei です。 久々のエントリ投下ですが、今回は先日弊 TL で話題になっていた、Android を P2P のローカルリレーサーバー化して Tor で公開する方法を紹介していこうと思います。 ## 用意するもの 1. Android 端末 2. Orbot 3. Citrine 4. Amethyst ## 前提と下準備 今回は、Orbot の詳細設定は省いて、Power User Mode の設定が完了している前提でお話を進めます。 Android 端末を用意して、2~4 のアプリをインストールしておいてください。 ## 設定方法 それでは早速設定していきましょう。 まず、Citrine を起動して、Settings のタブからローカルリレーの詳細を設定します。  設定が終了したら、ローカルリレーを起動します。  また、ここで表示されるポート番号をメモしてください。  次に、More のタブに移り、Hosted Onion Services へアクセスし、Service Type の項目で User Services にチェックを入れて、右下の + マークをタップすると以下のポップアップが表示されます。(Orbot がスクショを許してくれないので一部画像割愛） 表示されたら、Name に任意の名前を、Local Port と Onion Port に先ほどメモした Citrine のポート番号を入力します。  入力したら再起動を求められるので再起動してください。 再起動後に Hosted Onion Services の項目に .onion のアドレスが表示されたら成功です (何故か私の環境では、一回の再起動では設定が反映されなかったのですが、もし同じような現象が起きた場合は、再起動 -> Connect -> .onion アドレスが発行されてるかの確認、を数回試すと発行されるはずです) 発行されたら、.onion アドレスをタップしてクリップボードにコピーします。 次に、Amethyst を起動して、リレーの設定画面に入り、Outbox の設定にコピーした .onion アドレスを貼り付けて保存します。  後は、Amethyst 側で Orbot のポート番号を設定して Orbot に接続すれば BOOM! 設定完了です。  お疲れ様でした！ 素敵な Nostr ライフを！

@ 21ac2956:09d1e2df

## [kakoi](https://github.com/betonetojp/kakoi) の仕様についてのメモ ### キーボード操作 * 左手での操作に最適化 | キー | 動作 | |:-|:-| | ESC | 設定画面 | | F1 / F12 | ポストバーの表示と非表示 | | F2 | 時間の表示と非表示 | | F3 | ユーザーアイコンの表示と非表示 | | F4 | 名前の表示と非表示 | | F9 / Z | コンテンツの折り返し表示の切り替え （余白ダブルクリックでも動作） | | F10 | ユーザーリストとキーワード通知の設定画面 （余白右クリックでも動作） | | F11 | メイン画面の表示と非表示 （ポストバー表示） | | Shift + W | イベント最上行へ移動 | | W / ↑| イベント選択上移動 | | S / ↓ | イベント選択下移動 | | Shift + S | イベント最下行へ移動 | | A / ← | Webビューを開く （イベントを右クリックでも動作） | | F / → | リアクションを送信 （イベントをダブルクリックでも動作） | | 1 ～ 0 | リアクションを選択 | | R | 返信 | | B | リポスト | | Q | 引用 | | C | Webビューを閉じる | | Ctrl + Shift + A | メイン画面をアクティブにする | ### タイムライン * kind:1, 6, 7, 16を取得して表示する * フォロイーの名前の前には * が付く ### フォローリスト（kind:3） * 参照のみで更新はしない * F10 で開くユーザーリストでユーザーを選択し petname セルをクリックすることで未フォローユーザーにもペットネームを設定可能（ローカル保存） ### プロフィール（kind:0） * F10 で開くユーザーリストでユーザーを選択し picture セルをクリックすることでユーザーのアイコン表示を変更可能（ローカル保存） ### 返信（[NIP-10](https://github.com/nostr-protocol/nips/blob/master/10.md) kind:1） * kakoi のタイムラインに流れるすべてのイベント種に返信可能とする * スレッドを考慮せず、単一イベントへの単発返信とする * e タグは marker と返信先 pubkey は設定していない。 relay-url には空文字を設定 ```json ["e", "返信先 event-id", ""] ``` * p タグは 返信先 pubkey ひとつだけを指定 ### リポスト（[NIP-18](https://github.com/nostr-protocol/nips/blob/master/18.md) kind:6 , 16） * kakoi のタイムラインに流れるすべてのイベント種をリポスト可能 * kind:1はkind:6。その他はkind:16でリポストする * e タグは relay-url に空文字を設定 ```json ["e", "リポスト元 event-id", ""] ``` ### 引用（[NIP-18](https://github.com/nostr-protocol/nips/blob/master/18.md) kind:1） * q タグは relay-url に空文字を設定 ```json ["q", "引用元 event-id", ""] ```

@ 6b0a60cf:b952e7d4

ビットコインのウォレットは取引形態によって2種類に分かれます。 <dl> <dt>オンチェーン(L1)</dt> <dd>取引がブロックチェーンに刻まれるタイプ。時間がかかるし手数料が高い。</dd> <dt>ライトニングネットワーク(L2)</dt> <dd>ブロックチェーンに刻む前の少額決済を目的としたレイヤー。高速で手数料が安い。</dd> </dl> NostrでZapを利用する場合はライトニングネットワーク(以下、LNと呼びます)のウォレットが使われますが、さらにその中でもZap対応/非対応で分かれることになります。 また、秘密鍵を誰が管理するかによっても2種類の呼び方に分かれます。 <dl> <dt>カストディアル</dt> <dd>秘密鍵をサービスの運営に預けるタイプ。</dd> <dt>ノンカストディアル/セルフカストディアル</dt> <dd>秘密鍵(シードフレーズ)を自分で持っておくタイプ。</dd> </dl> Nostrで人気がある[Wallet of Satoshi](https://www.walletofsatoshi.com/)(以下、WoSと呼びます)はLNのカストディアルウォレットです。 今回はLNのセルフカストディアルウォレットである[Phoenix](https://phoenix.acinq.co/)を使ってみて、その仕組みや注意点など、学んだことを記録したいと思います。 Phoenixでウォレットを作る場合、初回でシードフレーズ(12個の単語)が作られますので、大切に控えておきましょう。 ## WoSからPhoenixに送金してみる メイン画面左下にあるReciaveからQRCode表示画面へ遷移します。そこでcopyボタンを押して`Lightning invoice(text)`をコピーしましょう。   次に、WoSの画面からSendを選択し、クリップボードからの貼り付けを選択します。   金額を指定して送金します。  ## 送金した額が満額届いてないんだけど？  下の方に`Service Fees`とありますが、これはPhoenix運営(ACINQ)へのお布施ですね。結構高く見えますが初回だけです。 また`Miner Fees`という項目は、[mempool](https://mempool.space/)のfeeに連動して変わるようですが、これはチャネルを太くする(送受信できる金額の上限を上げる)ために使われる手数料になります。 ### 財布が重たくなると手数料が取られる？ 有り体に言えばそういうことになります。以下のように10,000satsをもらう度にチャネル拡張のための手数料が引かれています。  上記の8,000satsを受け取っている時には手数料が発生していませんね。これはチャネル拡張が必要ないギリギリの金額を狙って送金したためです。送金前は8,859satsの余裕がありました。送金後は1,719satsに減っています。(余裕分がぴったり8,000sats減るわけではないようです。このへんの仕組みはよくわかりません。) (画面は左上⚙️マークの設定からPayment channelsから。)   ### 財布が軽くなると余裕が増える？ 逆にPhoenixからWoSに5,000satsほど送金してみます。(手数料として24satsほど余計に抜かれました)   余裕(Inbound Liquidity)が5,883satsまで復活しています。受け取るばかりでなく、バランスよく送ることで財布を重たくしなければチャネル拡張せずに使い続けることができそうです。(太くしたチャネルは永遠に残るわけではなく、[1年まで](https://phoenix.acinq.co/faq#what-happens-after-a-year-of-reserving-liquidity)らしいです) ### 自動でチャネル拡張にsatsを使われたくない！ 自動チャネル拡張を設定で無効化できます。左上⚙️マークの設定から`Channel management`から。   これでチャネル拡張が必要なほどの金額を送金しようとするとエラーになり失敗します。  ## まとめ セルフカストディアルウォレットならではの概念があり、謎の手数料が発生したりして怖いイメージがありましたが、どういう理由で手数料が発生するのかを知り、設定でのコントロールの仕方を習得することである程度怖いイメージを払拭することができました。 しかしカストディアルウォレット(特にWoS)の使いやすさを再認識することにもなりました。ただ自分で管理することの重要性も理解していますので、徐々に知識を深めていこうと思います。 ## 参考/謝辞 - [Phoenix wallet（フェニックスウォレット）の使い方！ビットコインのセルフカストディができるアプリを解説 - 知っとこ！ビットコイン図鑑](https://bitcoin-zukan.com/practical/phoenix-wallet/) - nostr:npub10zeurmg22wc89l8m3npw9cyu45cun0lvs6w3ep69cdpa25pna65s0994qz 様

@ ec42c765:328c0600

# 2024年3月 フィリピンのセブ島へ旅行。初海外。  Nostrに投稿したらこんなリプライが nostr:nevent1qqsff87kdxh6szf9pe3egtruwfz2uw09rzwr6zwpe7nxwtngmagrhhqc2qwq5 nostr:nevent1qqs9c8fcsw0mcrfuwuzceeq9jqg4exuncvhas5lhrvzpedeqhh30qkcstfluj （ビットコイン関係なく普通の旅行のつもりで行ってた。というか常にビットコインのこと考えてるわけではないんだけど…） #### そういえばフィリピンでビットコイン決済できるお店って多いのかな？ ### 海外でビットコイン決済ってなんかかっこいいな！ ## やりたい！ <br> ----------- <br> # ビットコイン決済してみよう！ in セブ島 [BTCMap](https://btcmap.org/map#14/10.31403/123.91797) でビットコイン決済できるところを探す 本場はビットコインアイランドと言われてるボラカイ島みたいだけど セブにもそれなりにあった！  なんでもいいからビットコイン決済したいだけなので近くて買いやすい店へ いざタピオカミルクティー屋！  ちゃんとビットコインのステッカーが貼ってある！  つたない英語とGoogle翻訳を使ってビットコイン決済できるか店員に聞いたら ### 店員「ビットコインで支払いはできません」 （えーーーー、なんで…ステッカー貼ってあるやん…。） まぁなんか知らんけどできないらしい。 店員に色々質問したかったけど質問する英語力もないのでする気が起きなかった 結局、せっかく店まで足を運んだので普通に現金でタピオカミルクティーを買った <br> タピオカミルクティー 話題になってた時も特に興味なくて飲んでなかったので、これが初タピオカミルクティーになった 法定通貨の味がした。  ### どこでもいいからなんでもいいから ### 海外でビットコイン決済してみたい <br> ----------- <br> # ビットコイン決済させてくれ！ in ボラカイ島 ビットコインアイランドと呼ばれるボラカイ島はめちゃくちゃビットコイン決済できるとこが多いらしい でもやめてしまった店も多いらしい でも300もあったならいくつかはできるとこあるやろ！ nostr:nevent1qqsw0n6utldy6y970wcmc6tymk20fdjxt6055890nh8sfjzt64989cslrvd9l 行くしかねぇ！ <br> ## ビットコインアイランドへ フィリピンの国内線だぁ  ``` 行き方： Mactan-Cebu International Airport ↓飛行機 Godofredo P. Ramos Airport (Caticlan International Airport, Boracay Airport) ↓バスなど Caticlan フェリーターミナル ↓船 ボラカイ島 料金： 飛行機（受託手荷物付き） 往復 21,000円くらい 空港～ボラカイ島のホテルまで（バス、船、諸経費） 往復 3,300円くらい （klookからSouthwest Toursを利用） このページが色々詳しい https://smaryu.com/column/d/91761/ ``` 空港おりたらSouthwestのバスに乗る 事前にネットで申し込みをしている場合は5番窓口へ  港！  船！（めっちゃ速い）  ボラカイついた！  ### ボラカイ島の移動手段 セブの移動はgrabタクシーが使えるがボラカイにはない。 ネットで検索するとトライシクルという三輪タクシーがおすすめされている。  （トライシクル：開放的で風がきもちいい） トライシクルの欠点はふっかけられるので値切り交渉をしないといけないところ。 最初に300phpくらいを提示され、行き先によるけど150phpくらいまでは下げられる。 これはこれで楽しい値切り交渉だけど、個人的にはトライシクルよりバスの方が気楽。 Hop On Hop Off バス： https://www.hohoboracay.com/pass.php 一日乗り放題250phpなので往復や途中でどこか立ち寄ったりを考えるとお得。  バスは現金が使えないので事前にどこかでカードを買うか車内で買う。 私は何も知らずに乗って車内で乗務員さんから現金でカードを買った。 バスは狭い島内を数本がグルグル巡回してるので20～30分に1本くらいは来るイメージ。 逆にトライシクルは待たなくても捕まえればすぐに乗れるところがいいところかもしれない。 <br> ## 現実 ボラカイ島 BTC Map  BTC決済できるとこめっちゃある <br> さっそく店に行く！ 「bitcoin accepted here」のステッカーを見つける！ 店員にビットコイン支払いできるか聞く！ できないと言われる！ <br> もう一軒行く 「bitcoin accepted here」のステッカーを見つける 店員にビットコイン支払いできるか聞く できないと言われる <br> 5件くらいは回った 全部できない！ <br> 悲しい <br> で、ネットでビットコインアイランドで検索してみると 旅行日の一か月前くらいにアップロードされた動画があったので見てみた 要約 - ビットコイン決済はpouch.phというスタートアップ企業がボラカイ島の店にシステムを導入した - ビットコインアイランドとすることで観光客が10％～30％増加つまり数百～千人程度のビットコインユーザーが来ると考えた - しかし実際には3～5人だった - 結果的に200の店舗がビットコイン決済を導入しても使われたのはごく一部だった - ビットコイン決済があまり使われないので店員がやり方を忘れてしまった - 店は関心を失いpouchのアプリを消した https://youtu.be/uaqx6794ipc?si=Afq58BowY1ZrkwaQ <iframe width="560" height="315" src="https://www.youtube.com/embed/uaqx6794ipc?si=S3kf0K49Z4NASxJt&amp;start=254" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> なるほどね～ しゃあないわ <br> ## 聖地巡礼 動画内でpouchのオフィスだったところが紹介されていた これは半年以上前の画像らしい  現在はオフィスが閉鎖されビットコインの看板は色あせている  おもしろいからここに行ってみよう！となった で行ってみた 看板の色、更に薄くなってね！？  記念撮影  これはこれで楽しかった 場所はこの辺 https://maps.app.goo.gl/WhpEV35xjmUw367A8 ボラカイ島の中心部の結構いいとこ みんな～ビットコイン（の残骸）の聖地巡礼、行こうぜ！ <br> ## 最後の店 Nattoさんから情報が <blockquote class="twitter-tweet"><p lang="ja" dir="ltr">なんかあんまりネットでも今年になってからの情報はないような…<a href="https://t.co/hiO2R28sfO">https://t.co/hiO2R28sfO</a><br><br>ここは比較的最近…？<a href="https://t.co/CHLGZuUz04">https://t.co/CHLGZuUz04</a></p>&mdash; Natto (@madeofsoya) <a href="https://twitter.com/madeofsoya/status/1771219778906014156?ref_src=twsrc%5Etfw">March 22, 2024</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> もうこれで最後だと思ってダメもとで行ってみた なんだろうアジア料理屋さん？  もはや信頼度0の「bitcoin accepted here」  ビットコイン払いできますか？ 店員「できますよ」 え？ほんとに？ビットコイン払いできる？ 店員「できます」 できる！！！！ なんかできるらしい。 <br> 適当に商品を注文して 印刷されたQRコードを出されたので読み取る ここでスマートに決済できればよかったのだが結構慌てた 自分は英語がわからないし相手はビットコインがわからない それにビットコイン決済は日本で１回したことがあるだけだった  どうもライトニングアドレスのようだ 送金額はこちらで指定しないといけない 店員はフィリピンペソ建ての金額しか教えてくれない 何sats送ればいいのか分からない ここでめっちゃ混乱した でもウォレットの設定変えればいいと気付いた 普段円建てにしているのをフィリピンペソ建てに変更すればいいだけだった 設定を変更したら相手が提示している金額を入力して送金 送金は2、3秒で完了した <br> やった！ ### 海外でビットコイン決済したぞ！ ログ  PORK CHAR SIU BUN とかいうやつを買った  普通にめっちゃおいしかった なんかビットコイン決済できることにビビッて焦って一品しか注文しなかったけどもっと頼めばよかった ここです。みなさん行ってください。 Bunbun Boracay https://maps.app.goo.gl/DX8UWM8Y6sEtzYyK6 ### めでたしめでたし <br> ----------- <br> # 以下、普通の観光写真 ## セブ島 ジンベエザメと泳いだ  スミロン島でシュノーケリング  市場の路地裏のちょっとしたダウンタウン？スラム？をビビりながら歩いた  ## ボホール島 なんか変な山  メガネザル  現地の子供が飛び込みを披露してくれた  ## ボラカイ島 ビーチ   夕日  藻  ボラカイ島にはいくつかビーチがあって宿が多いところに近い南西のビーチ、ホワイトビーチは藻が多かった（時期によるかも） 北側のプカシェルビーチは全然藻もなく、水も綺麗でめちゃくちゃよかった  プカシェルビーチ    <br> ----------- <br> # おわり！

@ 6bcc27d2:b67d296e

yugoです。 この記事は「[Nostrasia2024 逆アドベントカレンダー](https://chouseisan.com/s?h=b17c221dd4bb4d5cb13ca0828d030e6e)」10/19の分です。Nostrasiaの当日はリアルタイムで配信を視聴していました。Nostrを使ってアプリケーションの再発明をすべきという発表を聴き、自分だったらどんなものを作ってみたいかを考えて少し調べたり試みたりしたのでその記録を書きます。また、超簡単なものですがおそらく世界初となるvisionOS対応のNostrクライアントをつくってみたので最後の方に紹介します。 アプリケーションを再発明する話があったのは、「[What is Nostr Other Stuff?](https://www.youtube.com/watch?v=5SI5Ct4bS9E)」と題したkaijiさんの発表でした。 Nostrプロトコルを使って既存のアプリケーションを再発明することで、ユーザ体験を損なわずにゆるやかな分散を促すことができ、プロトコルとしてのNostrも成長していくというような内容でした。 自分はまだNostrで何かをつくった経験はなかったので、実装に必要な仕様の知識がほとんどない状態からどのようなアプリケーションをつくってみたいかを考えました。 最初に思いついたのは、Scrapboxのようなネットワーク型のナレッジベースです。自分は最近visionOS勉強会をやっており、勉強会でナレッジを共有する手段としてScrapboxの導入を検討していました。 Nostrコミュニティにも有志によるScrapboxがありますが、Nostrクライアントがあればそれを使うだろうから同じくらいの実用性を備えたクライアントはまだ存在しないのではないかという見立てでした。 長文投稿やpublic chatなどの機能を組み合わせることで実現できるだろうか。そう思っていた矢先、NIP-54のWikiという規格があることを知りました。 https://github.com/nostr-protocol/nips/blob/master/54.md まだちゃんとは読めていないですが、Scrapboxもwikiソフトウェアだし参考になりそうと思っています。正式な仕様に組み込まれていないようで、採用しているクライアントはfiatjafによるリファレンス実装(?)の[wikistr](https://github.com/fiatjaf/wikistr)くらいしか見つかりませんでした。 Scrapboxのようなナレッジベースを志向するNostrクライアントがあれば、後述するvisionOS対応クライアントの存在もありアカウントを使いまわせて嬉しいので試してみたいです。もし他にも似たようなサービスをどなたか知っていたら教えてください。 また現在は、勉強会やワークショップ、ハッカソンなどのコラボレーションワークを支援するためのツールを自分たちでも開発しています。Apple Vision Proに搭載されているvisionOSというプラットフォームで動作します。 https://image.nostr.build/14f0c1b8fbe5ce7754825c01b09280a4c22f87bbf3c2fa6d60dd724f98919c34.png この画面で自分が入りたいスペースを選んで共有体験を開始します。 スライドなどのコンテンツや自らのアバターを同期させることで、遠隔地にいてもまるでオフラインかのように同じ空間を共有することが可能になります。 https://image.nostr.build/cfb75d3db2a9b9cd39f502d6426d5ef4f264b3d5d693b6fc9762735d2922b85c.jpg ということなので、急遽visionOS対応のクライアントを作ってみました。検索しても1つも事例が出てこなかったので多分まだ世界で実装しているアプリはないのではないでしょうか。 とはいえ、クライアントを名乗っているもののまだ大した機能はなく、リレーからデータを取得するだけの読み取り専用です。 https://image.nostr.build/96e088cc6a082528682989ccc12b4312f9cb6277656e491578e32a0851ce50fe.png 画像では自分のプロフィールデータをリレーから取得しています。 まだどのライブラリもvisionOSに対応していなかったりで手こずったものの仕様の勉強になりました。 ただvisionOSアプリはiOSアプリ同様NIP-7が使えないので秘密鍵を自分で保管しなくてはならず、今後どう対処すべきかわかりかねています。これから時間ある時に少しずつ調べていこうと思っていますが、ネイティブアプリの秘密鍵周りはあまりリソースが多くないようにも感じました。もしどなたかその辺の実装に詳しい方いたら教えていただけると嬉しいです。 準備ができたらそのうちコードも公開したいと思っています。 これから少しずつ色んな機能を実装しながらNostrで遊んでいきたいです！

@ 101b30ee:18a46a45

# 背景 Junさんが山形県在住で、車で色々案内いただけることになりました。 # メンバー (敬称略) - Jun (nostr:npub1nlnjcakw6xfkpuhx9kym3d20sr774pm6rue5kk93uj7lrca9lypqgqj7fd) - りら (nostr:npub1tuqsl6l8xzly95vv80um7wsnt7gxy8w9wgt4khp4wyv4xwhfw44slm93e9) - あめ (nostr:npub1eqw8nx0hya3cwvtc0rje6lpjzzf6gvuh0mngz898dhp6juuwrp5s5uzduw) - Don (nostr:npub1dv9xpnlnajj69vjstn9n7ufnmppzq3wtaaq085kxrz0mpw2jul2qjy6uhz) - 横谷加奈子 (nostr:npub1sd2zns7qsfster7vcyjcqkert4cev2rzfeuus0d8hnfdh74t6g7su0p4c6) - 発火大根 (nostr:npub1zqdnpm5gcfap8hngha7gcp3k363786phvs2etsvxw4nh6x9ydfzsuyk6mn) # スケジュール ## 10/12 ### 11:00 - 11:30 霞城セントラル 日本酒めぐりツアー 500円で3コインもらえて、1コインでカップ１杯分の試飲ができるシステムのようです。<br> 山形はフルーツも有名で、日本酒だけでなくワインなども試飲できました。<br> 個人的には、梨ベースのお酒が飲み口すっきりしていておいしかったです。<br> 名前は忘れました ()<br> #### 霞城公園セントラル https://yamagatakanko.com/attractions/detail_13443.html nostr:nevent1qqszfgt4vef3ncyw7cy9yykuwv06pq5v9znaf2xeehfpp6s5j27ncqg2val6m nostr:nevent1qqsvfknrdtwsyvmztdzx40adzvtx8nztxu3vscgkljzzk2zr8kfmfnce54ke0 ### 11:30 - 12:30 霞城公園散策 東北屈指の戦国大名・最上義光(もがみよしあき)公 (1546-1614)が礎を築いた「山形城」を復原整備した都市公園らしいです。<br> Junさんに聞いたところ、最上義光の妹が伊達政宗の母・義姫 (よしひめ)で、息子の伊達政宗を毒殺しようとしたことで有名らしいです。<br> 後で調べたところ、毒殺事件が捏造だったとする記事もあり、真偽はいかに。<br> また、これもJunさんに聞いたのですが山形藩は幕府重役から失脚した左遷の地と呼ばれているようです。<br> ちょっと悲しい。<br> 後に調べたところ、山形藩は計12家が収めており、入れ替わりも激しかったようです。<br> まぁ、左遷だったとしても自然豊かな地でスローライフを過ごすのもアリかもしれない。<br> 個人的には、最上義光像が精巧に出来ているなぁと感動しました。<br> 構図がナポレオンに似ていたので、もしかして身長が低かった？と思いましたが<br> 後で調べたところ、180cm以上の長身だったとする文献があるようです。<br> #### 山形藩 https://ja.wikipedia.org/wiki/%E5%B1%B1%E5%BD%A2%E8%97%A9 #### 義姫の毒殺事件について https://bushoojapan.com/bushoo/date/2024/08/12/76725 #### 最上義明の身長 http://iiwarui.blog90.fc2.com/blog-entry-13581.html #### 霞城公園セントラル https://yamagatakanko.com/attractions/detail_2304.html nostr:nevent1qqsp78jf76yudrwf6w88szq4x50t0zpeht77adkmk5pj5xsg6wplcmcv25e3g nostr:nevent1qqsfvw828mus5ek44m5myuya5ndpvj8mjhlltzx4y6ha93932cvzaxgwqwah3 nostr:nevent1qqs9sd8m43lj6pmd7hzu0quf4v0s7rm4uaq83aqp5jn5sqfy8aw6f8skg0sgv ### 12:30 - 13:30 旧済生館 済生館は1878年（明治11年）に山形県立病院として建設され、東北地方で最も早く西洋医学を取り入れたことで有名のようです。<br> 建物内部の展示物の写真撮影は禁じられていたので写真は取れていませんが、あの有名な杉田玄白の訳書「解体新書」や、明治時代の医療器具などが展示されていました。<br> 私は工業高校出身で電気科だったので、昔の医療電気機器の展示などは見ていて飽きないものがありました。<br> #### 旧済生館 https://www100.pref.yamagata.jp/110001/sangyo/sangyoushinkou/him_top/him_maincat1/him_15.html ### 13:30 - 14:30 山寺付近に移動・ランチ 山寺付近に車で移動後、玉こんにゃくを食べながら山寺方面に徒歩移動。<br> 玉こんにゃくは名産らしく、山形のいたるところで売っていました。<br> 途中で近場のお店でランチ(蕎麦)を食べました。<br> ランチを食べながら映画 (オッペンハイマー)の話とかビットコインの話をしてました。<br> ちなみに私はオッペンハイマー見れてません。<br> あめさんはオッペンハイマーを見に県外 (奈良 -> 大阪)まで行ったらしい。<br> 行動力すげぇ。<br> nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzpgqwakh6t2vm0ufy82rmwjqa2ld2z9jdl9l90v0ds7afwe6n5myl5uf5p7 nostr:nevent1qvzqqqqqqypzpjqu0xvlwfmrsuchs789n47ryyyn5seewlhxsyw2wmwr49ecuxrfqyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qpqq570ak2p9wx9q09xafjnlnulshwg2wc5c66q37z884m0pselu36sz5k7jk nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzpp8xy7nktvyq87d676pkh6hjpftm5s703fq8e8c52l2l9xupe55wyhfc0p nostr:nevent1qvzqqqqqqypzq6c2vr8l8m9952e9qhxt8acn8kzzypzuhm6q70fvvxylkzu49e75qyshwumn8ghj7un9d3shjtt2wqhxummnw3ezuamfwfjkgmn9wshx5up0qy08wumn8ghj7un9d3shjtnwdaehgu3wwa5hyetydejhgtn2wqhsqgqthnr72cp92yqv9upzg2fyplvt6eazf6kxe24h6ea6syg3mthsl5tc3r26 ### 14:30 - 16:00 山寺 (宝珠山立石寺) 宝珠山立石寺 (愛称：山寺)は山形屈指の観光スポットで、松尾芭蕉が「閑さや岩にしみ入る蝉の声」の名句を紀行文「おくのほそ道」に残したことでも知られているそうです。<br> 展望台付近まで登りましたが、**前日2時間程度しか寝れてなかった** からか、途中で何回か力尽きました。<br> 何気にずっと階段だったのが厳しかった。w <br> 展望台から見る景色が超綺麗でした。達成感あった。<br> 途中でDonさんが「松尾芭蕉も山寺登ってますよ！」と励ましてくれましたが、松尾芭蕉は服部半蔵だったのでは、といわれる説が頻繁に出るくらい、体力おばけです () <br> #### 山寺・宝珠山立石寺 https://yamagatakanko.com/attractions/detail_2352.html #### 松尾芭蕉が忍者服部半蔵ではないかと言われる都市伝説の理由５つ https://spirituabreath.com/matuobasyou-hattorihannzou-5207.html nostr:nevent1qvzqqqqqqypzp8l893mva5vnvrewvtvfhz65lq8aa2rh58enfdvtre9a7836t7gzqqs2jsu0efm0s0xnp9exv0m4xkxaw07nsraxhfjqrl6rmjd977aqcycfaf05e nostr:nevent1qvzqqqqqqypzp8l893mva5vnvrewvtvfhz65lq8aa2rh58enfdvtre9a7836t7gzqqsxmrsa8h6y6z8hmt7hzg8cmspvc373gnjjs67vlrdp24lud8wm8ncp682ev nostr:nevent1qvzqqqqqqypzq6c2vr8l8m9952e9qhxt8acn8kzzypzuhm6q70fvvxylkzu49e75qyshwumn8ghj7un9d3shjtt2wqhxummnw3ezuamfwfjkgmn9wshx5up0qy08wumn8ghj7un9d3shjtnwdaehgu3wwa5hyetydejhgtn2wqhsqgq3a6ehlurcsmpzlc4vghnnu7tnk5tekwm2kxn7e9rkrq7uslqmlu9sg6vl nostr:nevent1qvzqqqqqqypzp8l893mva5vnvrewvtvfhz65lq8aa2rh58enfdvtre9a7836t7gzqqs9lp9n8yjwjx56khduh7sqehtpgfs20d5w7x9lnjpnlt3vmqkpnmq7xfcef nostr:nevent1qvzqqqqqqypzp8l893mva5vnvrewvtvfhz65lq8aa2rh58enfdvtre9a7836t7gzqqsx4m8un5h952d6f7zuq9yraucs82lcah2p2lk4z6n9u0lduje2pcs40zhkz nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzq5pf4h2je6jkpypup9kj2k66qtlcmce3gcg9q39xpv5388u50sun6ku45d nostr:nevent1qvzqqqqqqypzpjqu0xvlwfmrsuchs789n47ryyyn5seewlhxsyw2wmwr49ecuxrfqyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qpqkdwwjagam6rcxmakpcgsylu95zkm8s0qkvae8j2km6e5l5sr9alsm8vrfn nostr:nevent1qvzqqqqqqypzq6c2vr8l8m9952e9qhxt8acn8kzzypzuhm6q70fvvxylkzu49e75qyshwumn8ghj7un9d3shjtt2wqhxummnw3ezuamfwfjkgmn9wshx5up0qy08wumn8ghj7un9d3shjtnwdaehgu3wwa5hyetydejhgtn2wqhsqg9cqvgzvegmdsnc6xc5mhwnvsn9unyx4nx6megwcqxlheaddffc8ckpk3qj ### 16:00 - 18:30 山形駅でりらさん合流・産業科学館 車で山形駅まで戻り、りらさんと合流。<br> 山形駅内の産業科学館を見て回りました。<br> 産業科学館は子供向けの知育ブースや山形県民向けの各種企業ブースもあり、見ていて飽きないものが沢山展示されていました。<br> 発電機を回してミニカーを動かすゼネコンレーシングが楽しかった。<br> また、各種企業ブースを回りながら、Junさんに山形県民憧れの就職先などを聞いていました。<br> #### 産業科学館 http://y-sunka.org/ nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzpx0ykjd6egvded9jksguphr4deluxlz56dm4rpw9n68npx9wt3hx976mcl nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzpek5k3fygrx8y0024mmmnhqxdnd7jmqed7gf7sqt2tnushcv8xu7dwwctd nostr:nevent1qvzqqqqqqypzqhcppl47wv97gtgccwlehuapxhusvgwu2ushtdwr2uge2vawjattqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpy9mhxue69uhhyetvv9uj66ns9ehx7um5wgh8w6tjv4jxuet59e48qtcqyzzfwt63psqw4w5x7s33al0k0ms2v80p88vjjjd4rx7f8t4juppkux27ek7 nostr:nevent1qvzqqqqqqypzpjqu0xvlwfmrsuchs789n47ryyyn5seewlhxsyw2wmwr49ecuxrfqyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qpqgj58fqpvpngr2vafhdcqtf5vn264960dad73kqfrem3m27hr6mpstqgs5t nostr:nevent1qvzqqqqqqypzqhcppl47wv97gtgccwlehuapxhusvgwu2ushtdwr2uge2vawjattqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpy9mhxue69uhhyetvv9uj66ns9ehx7um5wgh8w6tjv4jxuet59e48qtcqyrnaxmkc47f5p46p36v8qnf4pr5ktm5algd86fsgzw9de96n9yp4qxu6dl8 nostr:nevent1qvzqqqqqqypzqhcppl47wv97gtgccwlehuapxhusvgwu2ushtdwr2uge2vawjattqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpy9mhxue69uhhyetvv9uj66ns9ehx7um5wgh8w6tjv4jxuet59e48qtcqypehj7clkzll3yf7yftcp5t9k6dfnetvrpl943q4jd8ccy39neq66nyavjs nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzqnc3mmp8sg4lysfkcz7x4ft3c6rrulne8aetvd8lwkzz86k8fp9lt040df nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzqgdms2ltla34u9qr4whzlz69r3mpsj7e3jlpv935yltn799xsk89d3a6g4 ### 18:30 - 20:40 旅館チェックイン、夕食 私 / あめさん / りらさんで、喜三郎という温泉旅館に泊まりました。<br> ここの温泉の泉質は芒硝泉(リウマチ･高血圧･切り傷･婦人病に効くとのこと)で、保養温泉として親しまれているそうです。<br> 夕食のしゃぶしゃぶ、サザエ、釜めし、芋煮、... 全部旨かった！！！<br> 夕食を食べていたら意外と時間ギリギリになり、露天風呂は朝入ることにして爆速で風呂に入りました。 #### 温泉旅館 (喜三郎) https://kisaburo.jp/ nostr:nevent1qvzqqqqqqypzqhcppl47wv97gtgccwlehuapxhusvgwu2ushtdwr2uge2vawjattqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpy9mhxue69uhhyetvv9uj66ns9ehx7um5wgh8w6tjv4jxuet59e48qtcqyqr9wgwca9jknh88c83nq3n5nnqtflrrd4v5d7uhuh9d47a2qsl870yprel nostr:nevent1qvzqqqqqqypzqhcppl47wv97gtgccwlehuapxhusvgwu2ushtdwr2uge2vawjattqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpy9mhxue69uhhyetvv9uj66ns9ehx7um5wgh8w6tjv4jxuet59e48qtcqyr6yt65e79gqh4dp8pll2kfgaw837xulq2jh2x3y9zd4udk47lkn55pqkzm nostr:nevent1qvzqqqqqqypzpjqu0xvlwfmrsuchs789n47ryyyn5seewlhxsyw2wmwr49ecuxrfqyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qpqwdv2aa4n5z5r5k8q3z2retc9zgujytx9z36xmpsw6h9npc97250qkne529 nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzp2rhy02kfw73jtzq7t7sp2njn2gnt9elta7nm09u55csld8kg5t39lh49r nostr:nevent1qvzqqqqqqypzqhcppl47wv97gtgccwlehuapxhusvgwu2ushtdwr2uge2vawjattqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpy9mhxue69uhhyetvv9uj66ns9ehx7um5wgh8w6tjv4jxuet59e48qtcqyzv32r03thal6tvjqh4wgxk6xv6x2tkuwngw6kfv6ar49rg2yq55jc8arsp nostr:nevent1qvzqqqqqqypzpjqu0xvlwfmrsuchs789n47ryyyn5seewlhxsyw2wmwr49ecuxrfqyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qpqy2duq6xsl8jwns0r7qxgpf6703uwvawrhhlanytrepd082mnyugqxnxpj3 ### 20:40 - 23:00 二次会 二次会の居酒屋でJunさん、Donさんと再度合流。<br> Junさんの奥さんで漫画家をされている、横谷先生も来てくれました。<br> 山形の地酒を飲みながら、Nostrasia 2024での思い出 / 山形の特産品 / Junさん夫妻が東京にくるタイミングはいつか など話していました。<br> 横谷先生はM3やコミティアなど東京に来られるタイミングがいくつかありそうでしたが、Junさんが東京に来るタイミングはなかなか無さそう。<br> 山形にまた会いにいくか、東京で面白いイベントをやって呼ぶしかない！<br> また、山形には「ほや」と呼ばれる海産物が有名という話を聞きました。<br> ほや、結局食べ損ねてしまった。<br> #### 山形うまいものと地酒 母家 https://r.gnavi.co.jp/t846900/?sc_lid=smp_top_01 #### 横谷先生の読み切り : 遠い日の陽 https://comic-days.com/episode/14079602755391426482 nostr:nevent1qvzqqqqqqypzq6c2vr8l8m9952e9qhxt8acn8kzzypzuhm6q70fvvxylkzu49e75qyshwumn8ghj7un9d3shjtt2wqhxummnw3ezuamfwfjkgmn9wshx5up0qy08wumn8ghj7un9d3shjtnwdaehgu3wwa5hyetydejhgtn2wqhsqgplnrvwhk6hsl9rk979u6qtmnmrpgywdgexruznhmtkmyevsaua8s8cy2pq nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzpkwu2t5zgug7wlwqh8nfh4zyma3f6tlacx9dag4kawnq7nynkxr33rdgaz nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzpq8szzc33567mtsjnvajzgur9n8us3fuv2ckx86y0et3c7kddqd37uxuz0 ### 23:00 - 旅館に戻る・就寝 旅館まで車で送ってもらい、旅館で就寝。<br> 翌日も朝早いので、恒例(？)の枕投げやトランプをして遊ぶこともなく、12時に消灯しました。<br> ## 10/13 ### 6:00 - 起床・露天風呂 ～ 7:30 朝食 ～ 8:30 チェックアウト 前日に入れなかった露天風呂に入るため、早めに起きて露天風呂に入りました。<br> 旅館の窓を開けると須川が流れていて、天然のASMRを感じられました。<br> nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzpz260lg35sg06h758y7eppvrwzypv5kc3yj4n0t8jyx5q4f82mse3ung9s nostr:nevent1qvzqqqqqqypzpjqu0xvlwfmrsuchs789n47ryyyn5seewlhxsyw2wmwr49ecuxrfqyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qpqt6cyt5hmatsuct2plneae7t0apnkkrxm38hvee3auhu0h3hljjgs943h27 nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzp2qq9lv0d3umyxprne6xpjj70af6flzcfs2qpgsx2r347q7ukpdm2rwml4 nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzqgaugf683lhlww8ynlgd7qfhgj2d3zlkecm72td35lfw6m4tkvhke4k8jt nostr:nevent1qvzqqqqqqypzqhcppl47wv97gtgccwlehuapxhusvgwu2ushtdwr2uge2vawjattqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpy9mhxue69uhhyetvv9uj66ns9ehx7um5wgh8w6tjv4jxuet59e48qtcqyz750rwdqdk0x8r08m96fcyf5l4wp9pmc0rz8mle02ygtrdzdhf0gjwc823 nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzqq36wgay36wz58kmjvsucple6whamvd28pqrhu082wsdkkpvxzht34tq02 ### 8:30 - 移動・買い物 ～ 9:40 Junさんの家に移動・芋煮会開始 近隣のスーパーで芋煮会用の買い物を済ませたあと、Junさんの家に移動して芋煮会を始めました。 あめさんが帰宅の関係上、山形駅を11:11に出ねばならず、芋をよく煮るために爆速で芋煮を作る必要がありました。<br> 皆で協力して爆速で芋煮を作り、しっかり煮えた状態の芋煮をあめさんに持って帰ってもらうことができました！ nostr:nevent1qvzqqqqqqypzqyqmxrhg3sn6z00x30mu3srrdr4ru05rweq4jhqcvat805v2g6j9qy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkkmm5v9ex7tnrdakj7qg6waehxw309aex2mrp0ykk5upwwd5xjmn0xvhxuet59uqzqe03zqdcpjzakz3u7jjs07crz05y024lvgmjuvh0zysf4zal9q0la8772q nostr:nevent1qvzqqqqqqypzpjqu0xvlwfmrsuchs789n47ryyyn5seewlhxsyw2wmwr49ecuxrfqyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qpq6xaa2etzypq7hlm8zs3rkrjsc0wh5c29huupe9mfxqqeu5uanttq39l9w6 nostr:nevent1qqs0zkh2t2crsv8ljxzvmy3ndwzncyl6wwz67hfy4p09tacem3pjzwg2h4ac8 nostr:nevent1qvzqqqqqqypzpjqu0xvlwfmrsuchs789n47ryyyn5seewlhxsyw2wmwr49ecuxrfqyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qpq3ugypvt2fw886375nzltef4fzlasvk7nzj5n9tpuunwrr4p9etasskzqd6 nostr:nevent1qvzqqqqqqypzpjqu0xvlwfmrsuchs789n47ryyyn5seewlhxsyw2wmwr49ecuxrfqyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qpq9u5559ucupe755xnlm00vm5wcj7rpu3wwc3wvrdjxxdcadcwumzqjg8e6r #### 芋煮ビルド過程 nostr:nevent1qvzqqqqqqypzqhcppl47wv97gtgccwlehuapxhusvgwu2ushtdwr2uge2vawjattqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpy9mhxue69uhhyetvv9uj66ns9ehx7um5wgh8w6tjv4jxuet59e48qtcqypn3w96w3wu375rz5hwhwhnmvrc664dltaudzvt578s6dh6kzq205u0m44v nostr:nevent1qvzqqqqqqypzqhcppl47wv97gtgccwlehuapxhusvgwu2ushtdwr2uge2vawjattqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpy9mhxue69uhhyetvv9uj66ns9ehx7um5wgh8w6tjv4jxuet59e48qtcqypc0nxkt4ht0ku9l4hjmvtlv9rh5lt496r7s3755clg7q45fypnxkjms92t nostr:nevent1qvzqqqqqqypzqhcppl47wv97gtgccwlehuapxhusvgwu2ushtdwr2uge2vawjattqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpy9mhxue69uhhyetvv9uj66ns9ehx7um5wgh8w6tjv4jxuet59e48qtcqypdfx9umwcyupt4cx38klfhl0f3saf3ar47jr7rcyj69dzyxve7tqk8wmcm nostr:nevent1qqsve084cxu5kw3gvqhjaehfge202z2nyddft89ufn9j73wyynwzhwczwz8j2 nostr:nevent1qqs26rp3gc2dhz4yznynym0y3c6y257kt2u773dvaaf87uf40fzjmcqk2zxxm nostr:nevent1qqsf3jx69s6guydhfxqstcw2m5aaw0zpum74aawe79nhz3xyg7p7dks0x9gn5 nostr:nevent1qqswtgfxseqwnt424ay668ps782drdmxkyyqj8uk8lfxs264gayfnkg3ls82a nostr:nevent1qqsqd257ng55ynkrwe3v2skcx29xalz85qcgn3ghj8ug4lqt9ewqvwgshz303 nostr:nevent1qqsw04zd3wgd3c5ztave9yhhavupl7pc3e4rcke5qn4azn8gpctz23cm7e5p8 nostr:nevent1qqsv8kqnr36jyhj9tnc602p6njakhgcuf6klm0xfrsngjrxlej9068s9vz3jg nostr:nevent1qvzqqqqqqypzqhcppl47wv97gtgccwlehuapxhusvgwu2ushtdwr2uge2vawjattqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpy9mhxue69uhhyetvv9uj66ns9ehx7um5wgh8w6tjv4jxuet59e48qtcqyrpm5t3gxyjxnfw6y8eu2j0mpgf8acj83c86ueykdqke6nxchjku63rl6q5 ### 11:20 - 14:30 Junさんの家でまったり・ねるねるねるね Junさんにあめさんを駅に送ってもらった後は、残ったメンバーでテレビを見たり、ねるねるねるねを作って皆で食べたりしていました。<br> りらさんが仙台に行くため、14:30で帰っていきました。<br> nostr:nevent1qqsya6u4r9amxs32m4k45s9203ph3kwmtlyddq283zrtyufk3z7tk9gaw3dyv nostr:nevent1qqs0nr6xznhxr4hfrczatlgy26lcrlup3zg8ey6j6ldthxnu9fy3mfq7tauam ### 14:30 - 16:30 伺かレクチャーを受ける Junさんにりらさんを送ってもらっている途中、せっかく伺かベテランのDonさんがいるので<br> 伺かを始めました。<br> ※元々伺かやSSTPには興味があった<br> Donさんに伺かの基礎や「Nostr x 伺か」のOSSの機能などをレクチャーしてもらいながら、<br> Nostrと伺かで出来ることを話し合っていました。<br> 個人的に驚いたのは、一方通行で喋らせるだけだと思っていた伺かが、SSTPを通じてデスクトップマスコットとシーケンシャルに「やりとりができる」ことです。<br> 非常に拡張性が高く、Nostrと同じで無限に遊べそうな雰囲気を感じました。<br> #### 伺か (うかがか) とは 2000年5月25日に初公開されたデスクトップ常駐型のフリーウェアで、24年間色んな人が発展・メンテナンスしています。<br> SSTP (Sakura Script Transfer Protocol) と呼ばれるプロトコルで指定のポート番号 (9801番)あてにメッセージを送ると、デスクトップマスコットを喋らせたり色んなことができます。<br> プロトコル仕様が公開されており、SSTPクライアントやサーバー、ベースウェアまで自作することが可能です。 詳細 https://dic.nicovideo.jp/a/%E4%BC%BA%E3%81%8B #### 伺か参考 (ばぐとら研究所) 現在デファクトスタンダードとなっているベースウェア、SSPがここからダウンロードできます。 https://ssp.shillest.net/ nostr:nevent1qqsyrz64vff9fjkpj297qyr278d2a58l3fuysgknsm8jwyuwy6v8hcgvmn4mt nostr:nevent1qqsdzfjfvxxk5ph49x40s3hf8pdgazzq2x5xekd6ztqnqw4y4z3r8as4pdywy nostr:nevent1qqsr8sdds33g53asp7c45v3eems3vj3qhtxayvku9nxext95aauuuaq4d6t0x ### 16:30 - 17:30 四谷ラボの配信アーカイブを見る・帰宅 Nostrasia 2024やBluesky meetup、Nostr勉強会の配信アーカイブを見ながら、当時の思い出やNostrの未来について語っていました。<br> こういうのを忘年会や新年会でやっても面白いかもしれない。<br> 18時の山形駅発の新幹線を取っていたので、18時にJunさんに駅まで送ってもらい、山形を去りました。<br> #### 四谷ラボの配信アーカイブ https://www.youtube.com/@428-lab # 終わりに 私は1泊2日でしたが、山形を味わい尽くしてリフレッシュすることが出来ました！<br> 今回、Junさんには企画だけでなく車で色々連れて行ってもらったりと、本当にお世話になりました。<br> 次に直接お会いしたら、何かしらもてなしたい。<br> また、Donさんに直接会えて色々話せたのは本当に貴重でした。聞くところによると、Nostrのオフ会だけでなく、歴の長い伺か仲間とのオフ会も出たことがないらしいです。<br> また山形に行きたい！と思えるようなオフ会でした。

@ 82b30d30:40c6c003

#[3] #[4] #[5] #[6] #[7] #[8] #[9] #[10] #[11] #[12] #[13] #[14] #[15] #[16] #[17] #[18] #[19] #[20] #[21] #[22] #[23] #[24] #[25] #[26] #[27] #[28] #[29] #[30] #[31] #[32] #[33] #[34]

@ 5f010feb:3ae9756b

#[3] #[4] #[5] #[6] #[7] #[8] #[9] #[10] #[11] #[12] #[13] #[14] #[15] #[16] #[17] #[18] #[19] #[20] #[21] #[22] #[23] #[24] #[25] #[26] #[27] #[28] #[29] #[30] #[31] #[32] #[33] #[34] #[35] #[36] #[37] #[38] #[39] #[40] #[41] #[42] #[43] #[44] #[45] #[46] #[47] #[48] #[49] #[50] #[51] #[52] #[53] #[54] #[55] #[56] #[57] #[58] #[59] #[60] #[61] #[62] #[63] #[64] #[65] #[66] #[67] #[68] #[69] #[70] #[71] #[72] #[73] #[74] #[75] #[76] #[77] #[78] #[79] #[80] #[81] #[82] #[83] #[84] #[85] #[86] #[87] #[88] #[89] #[90] #[91] #[92] #[93] #[94] #[95] #[96] #[97] #[98] #[99] #[100] #[101] #[102] #[103] #[104] #[105] #[106] #[107] #[108] #[109] #[110] #[111] #[112] #[113] #[114] #[115] #[116] #[117] #[118] #[119] #[120] #[121] #[122] #[123] #[124] #[125] #[126] #[127] #[128] #[129] #[130] #[131] #[132] #[133] #[134] #[135] #[136] #[137] #[138] #[139] #[140] #[141] #[142] #[143] #[144] #[145] #[146] #[147] #[148] #[149] #[150] #[151] #[152] #[153] #[154] #[155] #[156] #[157] #[158] #[159] #[160] #[161] #[162] #[163] #[164] #[165] #[166] #[167] #[168] #[169] #[170] #[171] #[172] #[173] #[174] #[175] #[176] #[177] #[178] #[179] #[180] #[181] #[182] #[183] #[184]

@ 101b30ee:18a46a45

昨日 (2024/9/30), お世話になった会社を退職しました。<br> 2023/7/1入社のため、在籍期間は1年3か月でした。<br> ## どんな会社だったの？ 会社名は伏せますが、BtoBtoCのサブスク課金型Webサービスを展開している会社のインフラエンジニアをやっていました。<br><br> 職務内容は多岐にわたり、<br> - 開発・商用環境の構築 <br> - サービスのデプロイ<br> - DNS関連の設定 <br> - サービス加入時や解約時の定期作業 <br> - 社内のセキュリティ意識向上のための啓蒙 <br> - 情シス業務<br> - サービスのバックエンド(PHP)のリファクタ<br> - OS含めた各種ソフトウェアのバージョン移行<br> などなど。<br> インフラエンジニアという職種ではあったものの、開発系のタスクも多く経験させてもらいました。<br> ## なぜ退職したの？ 売上が芳しくなく業務縮小することになり、退職しないかと勧められました。<br> この希望退職は私だけではなく、ほとんどの社員に話がいっていたようです。<br> 実際、社員数は半分以下になっていたようで、統合により消えた部署や、1人しか残らなくなった部署もあります。<br> 個人的にはまだ1年少ししか在籍しておらず少し未練はあったものの、これをチャンスと捉えて希望退職に乗ることにしました。<br> 幸い、いくつかコミュニティ活動をしているので、リファラルで声をかけて頂いている会社様が何社かあります。<br> ## 会社の良かった所 大きなカンファレンスで複数回登壇されているような凄い方と一緒に仕事が出来たり、レンタル出来る技術書が多かったり、月一で社内LT大会兼交流会があって会社経費でピザや寿司が食えたり、良かった所は沢山ありました！<br> 最後に参加したLT会は、これで最後かと思うとちょっと泣きそうになりました。<br> ちなみに、私は社内LT会の運営をやったり、LT自体もこの1年で4回ほど行いました。<br> ## これから 色々ありましたが、会社への恨みのようなものは全くありません。感謝しかないです。<br> ただ、自社の仕事がもう少し楽になるような土台を作りたかったな、というのは心残りではあります。<br> 人数も減って状況は厳しくなっていると思いますが、V字回復してくれることを祈るばかりです。<br> 次の会社も、自社開発系の企業でバックエンドないしインフラ系の職種で働けたらと考えています。<br> 今日 (2024/10/1)から無職です！会社受けまくります！頑張るぞい！

@ 5f010feb:3ae9756b

こんにちは。小牧りらです。 こちらは「[Nostrasia2024 逆アドベントカレンダー](https://chouseisan.com/s?h=b17c221dd4bb4d5cb13ca0828d030e6e)」2日目の記事です。 1日目は[しのさん](nostr:npub1l60d6h2uvdwa9yq0r7r2suhgrnsadcst6nsx2j03xwhxhu2cjyascejxe5)の「[Nostrasia イベントレポート #1](https://blog.428lab.net/entry/2024/09/29/141759)」です。 この記事はオタクなら一度は考える夢、「コスプレ」(主語デカ)を夢見ていたオタクの、人生初のコスプレを記録したものです。 ### Nostrasia2024の開催が現実味を帯びる 2024年7月、四谷ラボDiscordで「Nostrasiaをもう一度。」と高まっていた機運が動き出しました。Nostrasia2024の始動です。テイザーサイトの作成、サイトやNostr、Connpasでの告知に始まり、会場の選定、当日のタイムラインの作成など、7月〜9月前半でNostrasiaはその全貌を顕にしていきました。私はDiscordには入っているものの、仕事が忙しく(という言い訳)特に貢献もしないままグループを眺めていました。そんな中当日スタッフとして協力させていただけることとなり、何か盛り上がりに貢献できないか？と考えた結果、「コスプレするしかない」との結論に至りました。 ### 1週間前に動き出すコスプレ製作記 以前から技術書典など「Nostr関連のイベントでNostr関連キャラクターのコスプレができたらな〜」、という思いや、「オタクたるもの人生で一度はちゃんとしたコスプレをしたい！」、という思いを抱えていた私。ではこのNostrasia2024で誰のコスプレをするか？が課題となっていきます。自律分散型コミュニティのNostr、日本人コミュニティも成立から1年以上が経過し、実に多くのキャラクターが生み出されてきました。その中でも直近で話題沸騰中のキャラクター、「りとりん」のコスプレをしよう！と思い、生みの親である[かすてらふぃさん](nostr:npub168ghgug469n4r2tuyw05dmqhqv5jcwm7nxytn67afmz8qkc4a4zqsu2dlc)と[たーごいるさん](nostr:npub1targ0yle577hpqnumt2u2em78eve07jn6zfq42kyuvp2cr2garnseahjvn)の許可を得て製作に取り掛かりました。女オタクの聖地、池袋に繰り出しウィッグや毛糸などの買い出しを行いました(この時点で1週間前)。池袋は新しくなったアニメイトにコスプレコーナーがあったり、今回は入っていないですがウィッグ専門店のアシストウィッグさん、そしてユザワヤなどの手芸店に100均などコスプレに必要な資材を購入する店舗に事欠きません。3時間近く店舗を渡り歩いた結果、アニメイトとダイソーで必要な資材を揃えました。 資材一覧 ＜アニメイト＞ ・ピンクのウィッグ ・水色の毛束 ・耳を取り付けるためのピン ・ピンクのアイブロウ ・ウィッグ固定用の両面テープ ＜ダイソー＞ ・ピンクの毛糸(耳としっぽ) ・針金(耳としっぽの芯) ・ヘアアクセサリー(ヘアピン、ヘアゴム) ・ウィッグネット ・ペット用ブラシ ### Nostrasia当日 平日仕事終わりに作業を進める時間もなく、前日、前々日の土日でぶっつけ本番のウィッグ製作に取り掛かりました。ミディアムボブのウィッグを、動画やメイキング記事を見ながら切ったり、毛束をつけたり、結んだり…。失敗したら即終了の緊張感が走る中、慎重に作業を進めていきます。並行してアクリル毛糸と針金でけも耳・けもしっぽを作りました。ペット用ブラシをガシガシして毛並みを作っていく作業、そしてその過程で発生した抜け毛はもはやリアル。膝の上にりとりんが居るのではないか、と思いながら作業を進めました。最終的に当日スタートのギリギリまで作業し(会場でポニテにしたり耳を取り付けたりしていました)、ギリギリオープニングには間に合いました。ウィッグを付けた瞬間は「重い！暑い！」となりましたが、意外と室内半日であれば耐えられるな、という感想でした。  これはマグロを心待ちにするりとりん ### まとめ ・とりあえず池袋に行けばなんとかなる ・ウィッグの構造に驚く ・ネットで調べれば扱い方、作り方が分かる ・製作には余裕を持って(当日会場で作業するな) ### おわりに Nostrasiaとりとりんというビッグウェーブに乗りながら、オタクとしての夢であったコスプレが実現できたこと、とても良い経験になりました！そして世の中のだいたいのものごとは調べてやったらなんとかなると感じました。次回、Nostr関連でコスプレする機会があればさらにバージョンアップしたりとりんをやりたい！という気持ちと、衣装製作も楽しめるキャラクターをやりたい！という気持ちが湧き上がってきました。その時はちゃんと工程管理します…。 3日目は[junさん](nostr:npub1nlnjcakw6xfkpuhx9kym3d20sr774pm6rue5kk93uj7lrca9lypqgqj7fd)の「[Nostr のフォロワーネットワークにおけるクラスタリング係数](https://fivebythree.net/project/clusteringcoeff/introduction/)」です。

@ 91687725:a0de48ea

こんにちは。Kateです。 最近ちょっとお休みしていますが、日本でビットコインを専門に扱う[Diamond Hands Magazine](https://diamondhandscommunity.substack.com/)に寄稿したりしてます。 私がビットコインと出会ったのは2011年、まだビットコイン利用者はとても少なかった時代です。たまたま身内にビットコイン界隈の人がいました。もしかしたら今でいうビト妻だったかも？ まだビットコインが1ドル以下でおもちゃみたいな存在だった頃に知ったわけですが、その後勢いづいて、100ドル、1000ドルと価値が上がっていきました。 それを見て、ビットコインを少しずつ買って貯めておけば、将来リタイヤの蓄えになるかもと思ってお小遣い程度のビットコインを積立してました。でも、アクシデントで失くしちゃったんですよね。 その後、身内のごたごたで自分の生活が天地がひっくり返るように一変し、気がつけばカナダでただお金がないアジア系移民シングルマザー、しかも周りに家族が誰もいないという、非常にマイノリティな立場になりました。 人生、何事も経験。一度ビットコインを失くし、傷心もあり、数年はビットコインから離れました。でも気がつけばビットコインは冬の時代を終えて、また元気になっていたんですね。自分は海外でひとり子育てに追われ、なんとか生きてた感じですが！ ビットコインが500ドルくらいになっていた時に困窮していた私は、ふとペーパーウォレットと呼ばれた当時の携帯可能ウォレット？に0.5btc 残っていたのを発見して速攻換金しましたね。悔やまれます。 その後、2017年頃、カナダで当時大手の割と使い勝手のいい取引所があることを知って、再度ビットコイン貯蓄にチャレンジしました。2年ほどで、ほぼ1ビットコインと10ETHくらいあったんですけどね、今度は取引所の代表者が行方不明になり、またもやビットコインを失くしました。 ふつうだったら、もうやめますよね。2回もなくしたら。 けれど、自分はかつてインターネットが始まったころのワクワクを経験していました。90年代半ば、新宿にできたばかりのインターネットカフェで、GIFがかろうじて表示できるグレーのブラウザ画面と対面しました。世界を変える技術を体験した時の感動は今でも忘れられません。 （こう書くと立派なオバサンなのがバレちゃいますね。ビットコインネイティブ世代の中では年長者） それから15年以上たって、初めてサトシナカモトのホワイトペーパーを読んだ時に、同じ衝撃を受けたのです。初めて実用化されたインターネット上で世界の誰とでも送り合えるマネー。その可能性は無限∞。 そのビットコインの進化を、実際に買ってみたり、使ってみたり、なくしたりしつつ、より深く知ろうと付き合ってきた自分は、いつの間にかビットコインを通して世の中のいろいろを見て考えるようになりました。 ビットコインが生まれ、実験段階を経て、すでに15年が経ちます。けれども、ビットコインは今でも多くの人から最も誤解されている技術・発明のように見えます。ここまで来たら、自分が生きている間に、ビットコインが世界とどう関わっていくのか見届けたいと思います！ そして、私自身がビットコインを知ることで発見した世界や新しい価値観を、誰かに伝えられたらいいなと願って、このブログをスタートすることにしました。 今回は自己紹介という形になりましたが、私がビットコインを通して学んだことや気づいたことをこれから少しづつアップしてみます！ 週1くらいのペースで投稿が目標です。よろしくお願いします。

@ f240c9c2:6c0c0a86

⚠️一部のクライアントでは表示が崩れている場合があります。[Habla](https://habla.news/a/naddr1qvzqqqr4gupzpujqe8p9zrpuv0f4ykk3rmgnqa6p6r0lan0t8ewd0ksj89kqcz5xqqgrjdmrxqmxzv3hvenrxv35xp3rj76mgnj)や[Yakihonne](https://www.yakihonne.com/article/ikanoasi10@ikanoasi10.github.io/97c06a27ff3240b9)から見てください --- NIP-51のkind:30007に関する[Pull Request](https://github.com/nostr-protocol/nips/pull/1172)が承認され、2024/08/20時点で本家NIPsにもマージされました。今後「リポスト」や「リアクション」などの特定のkind[^1]をミュートするためのセット[^2]が対応するクライアントで使えるようになります。 kind mute set(kind:30007)にて、`"d"`タグには対応するイベントの種類の番号(リポストなら`"6"`、リアクションなら`"7"`)を入れ、`"p"`タグにはユーザの公開鍵(pubkey)を入れるそうです。 nostrクライアントの[nostter](https://nostter.app/)は、これに[対応](https://github.com/SnowCait/nostter/pull/1282)したことで、Twitter(現:X)の「リポストをオフのする」機能のように"特定ユーザーのリポストをクライアント上で非表示にする"といったことができるようになりました。リアクションも同様に非表示にできます。 nostterでは、2024/07/29以降、ユーザーのプロフィール画面からこれらの設定を行えるようになっています。  2024/06/22 20時の時点では、nostter上ではこれを設定する画面が用意されていなかったので、別アプリを用いたり、イベントを自分で投げるなどして別途設定する必要がありました。 以下は、別アプリを用いて設定した際の手順です。 # 手順 kind:30007は[のすとびうあ](https://nostviewstr.vercel.app)というWebアプリで設定しました。 以下のようにのすとびうあのホーム画面「リストの種類」で30007を入力するか、  `https://nostviewstr.vercel.app/<npub文字列>/30007`にアクセスして設定画面にいけました[^3]。 左下の方にある≡を押して  ポップアップの「編集」を押して  ここではリポストのミュートのため、IDの欄に対応するイベントの種類の番号である「6」を入れて  右下にある青いボタン押して  Userの欄にリポストをミュートするユーザーの公開鍵の**npub文字列**を入れ、public(ミュート状況が公開される)あるいはprivate(非公開)のボタンを押したら  そのユーザーが追加されて設定完了！  この設定を行うことで、入力した公開鍵(ユーザー)のリポストをnostter上でもミュートできました🙌 リポストやリアクションがどのように表示されるかをユーザーがコントロールできると便利なので、今後いろんなクライアントで対応されればいいな〜と思います！ [^1]: イベントの種類。 [^2]: セット：リストをさらに複数のカテゴリに分けられるようにした感じのもの。(たぶん) [^3]: ティル父さんのポスト(nevent1qqs2vdf9vxta64qy0rxu3e5fczcfzdufwg6hfr3gnga5y0yk9shw9mgc5wwpt)より。

@ 3bf0c63f:aefa459d

# Why relay hints are important Recently [Coracle has removed support](nostr:nevent1qqsfmgthccjuz7quucel20wjanh80sp8nxf5ujgpj5hwdzk8japavzgpzemhxue69uhky6t5vdhkjmn9wgh8xmmrd9skcq3qjlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qca68ht) for following relay hints in Nostr event references. Supposedly Coracle is now relying only on public key hints and `kind:10002` events to determine where to fetch events from a user. That is a catastrophic idea that destroys much of Nostr's flexibility for no gain at all. * Someone makes a post inside a community (either a NIP-29 community or a NIP-87 community) and others want to refer to that post in discussions in the external Nostr world of `kind:1`s -- now that cannot work because the person who created the post doesn't have the relays specific to those communities in their outbox list; * There is a discussion happening in a niche relay, for example, a relay that can only be accessed by the participants of a conference for the duration of that conference -- since that relay is not in anyone's public outbox list, it's impossible for anyone outside of the conference to ever refer to these events; * Some big public relays, say, _relay.damus.io_, decide to nuke their databases or periodically delete old events, a user keeps using that big relay as their outbox because it is fast and reliable, but chooses to archive their old events in a dedicated archival relay, say, _cellar.nostr.wine_, while prudently not including that in their outbox list because that would make no sense -- now it is impossible for anyone to refer to old notes from this user even though they are publicly accessible in _cellar.nostr.wine_; * There are [topical relays](nostr:naddr1qqyrze35vscrzvfcqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0z85e2) that curate content relating to niche (non-microblogging) topics, say, cooking recipes, and users choose to publish their recipes to these relays only -- but now they can't refer to these relays in the external Nostr world of `kind:1`s because these topical relays are not in their outbox lists. * Suppose a user wants to maintain two different identities under the same keypair, say, one identity only talks about soccer in English, while the other only talks about art history in French, and the user very prudently keeps two different `kind:10002` events in two different sets of "indexer" relays (or does it in some better way of announcing different relay sets) -- now one of this user's audiences cannot ever see notes created by him with their other persona, one half of the content of this user will be inacessible to the other half and vice-versa. * If for any reason a relay does not want to accept events of a certain kind a user may publish to other relays, and it would all work fine if the user referenced that externally-published event from a normal event, but now that externally-published event is not reachable because the external relay is not in the user's outbox list. * If someone, say, Alex Jones, is hard-banned everywhere and cannot event broadcast `kind:10002` events to any of the commonly used index relays, that person will now appear as banned in most clients: in an ideal world in which clients followed `nprofile` and other relay hints Alex Jones could still live a normal Nostr life: he would print business cards with his `nprofile` instead of an `npub` and clients would immediately know from what relay to fetch his posts. When other users shared his posts or replied to it, they would include a relay hint to his personal relay and others would be able to see and then start following him on that relay directly -- now Alex Jones's events cannot be read by anyone that doesn't already know his relay.

@ 3bf0c63f:aefa459d

# How to do curation and businesses on Nostr Suppose you want to start a Nostr business. You might be tempted to make a closed platform that reuses Nostr identities and grabs (some) content from the external Nostr network, only to imprison it inside your thing -- and then you're going to run an amazing AI-powered algorithm on that content and "surface" only the best stuff and people will flock to your app. This will be specially good if you're going after one of the many unexplored niches of Nostr in which reading immediately from people you know doesn't work as you generally want to discover new things from the outer world, such as: - food recipe sharing; - sharing of long articles about varying topics; - markets for used goods; - freelancer work and job offers; - specific in-game lobbies and matchmaking; - directories of accredited professionals; - sharing of original music, drawings and other artistic creations; - restaurant recommendations - and so on. But that is not the correct approach and damages the freedom and interoperability of Nostr, posing a centralization threat to the protocol. Even if it "works" and your business is incredibly successful it will just enshrine you as the head of a _platform_ that controls users and thus is prone to all the bad things that happen to all these platforms. Your company will start to display ads and shape the public discourse, you'll need a big legal team, the FBI will talk to you, advertisers will play a big role and so on. If you are interested in Nostr today that must be because you appreciate the fact that it is not owned by any companies, so it's safe to assume you don't want to be that company that owns it. **So what should you do instead?** Here's an idea in two steps: 1. **Write a Nostr client tailored to the niche you want to cover** If it's a music sharing thing, then the client will have a way to play the audio and so on; if it's a restaurant sharing it will have maps with the locations of the restaurants or whatever, you get the idea. Hopefully there will be a NIP or a NUD specifying how to create and interact with events relating to this niche, or you will write or contribute with the creation of one, because without interoperability none of this matters much. The client should work independently of any special backend requirements and ideally be open-source. It should have a way for users to configure to which relays they want to connect to see "global" content -- i.e., they might want to connect to `wss://nostr.chrysalisrecords.com/` to see only the latest music releases accredited by that label or to `wss://nostr.indiemusic.com/` to get music from independent producers from that community. 2. **Run a relay that does all the magic** This is where your value-adding capabilities come into play: if you have that magic sauce you should be able to apply it here. Your service, let's call it `wss://magicsaucemusic.com/`, will charge people or do some KYM (know your music) validation or use some very advanced AI sorcery to filter out the spam and the garbage and display the best content to your users who will request the global feed from it (`["REQ", "_", {}]`), and this will cause people to want to publish to your relay while others will want to read from it. You set your relay as the default option in the client and let things happen. Your relay is like your "website" and people are free to connect to it or not. You don't own the network, you're just competing against other websites on a leveled playing field, so you're not responsible for it. Users get seamless browsing across multiple websites, unified identities, a unified interface (that could be different in a different client) and social interaction capabilities that work in the same way for all, and **they do not depend on you, therefore they're more likely to trust you**. --- Does this centralize the network still? But this a simple and easy way to go about the matter and scales well in all aspects. Besides allowing users to connect to specific relays for getting a feed of curated content, such clients should also do all kinds of "social" (i.e. following, commenting etc) activities (if they choose to do that) using the outbox model -- i.e. if I find a musician I like under `wss://magicsaucemusic.com` and I decide to follow them I should keep getting updates from them even if they get banned from that relay and start publishing on `wss://nos.lol` or `wss://relay.damus.io` or whatever relay that doesn't even know what music is. The hardcoded defaults and manual typing of relay URLs can be annoying. But I think it works well at the current stage of Nostr development. Soon, though, we can create events that recommend other relays or share relay lists specific to each kind of activity so users can get in-app suggestions of relays their friends are using to get their music from and so on. That kind of stuff can go a long way.

@ 3bf0c63f:aefa459d

# About Nostr, email and subscriptions I check my emails like once or twice a week, always when I am looking for something specific in there. Then I go there and I see a bunch of other stuff I had no idea I was missing. Even many things I wish I had seen before actually. And sometimes people just expect and assume I would have checked emails instantly as they arrived. It's so weird because I'm not making a point, I just don't remember to open the damn "gmail.com" URL. --- I remember some people were making some a Nostr service a while ago that sent a DM to people with Nostr articles inside -- or some other forms of "subscription services on Nostr". It makes no sense at all. Pulling in DMs from relays is exactly the same process (actually slightly more convoluted) than pulling normal public events, so why would a service assume that "sending a DM" was more likely to reach the target subscriber when the target had explicitly subscribed to that topic or writer? Maybe due to how some specific clients work that is true, but fundamentally it is a very broken assumption that comes from some fantastic past era in which emails were 100% always seen and there was no way for anyone to subscribe to someone else's posts. Building around such broken assumptions is the wrong approach. Instead we should be building new flows for subscribing to specific content from specific Nostr-native sources (creators directly or manual or automated curation providers, communities, relays etc), which is essentially what most clients are already doing anyway, but specifically Coracle's new custom feeds come to mind now. --- This also [reminds me](nostr:nevent1qqsda83vup73lhv6m4mee2wka83dzuwf78e95wtpn70r6ce99e8ah4gpr9mhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vammnc95) of the interviewer asking the Farcaster creator if Farcaster made "email addresses available to content creators" completely ignoring all the cryptography and nature of the protocol (Farcaster is shit, but at least they tried, and in this example you could imagine the interviewer asking the same thing about Nostr). I imagine that if the interviewer had asked these people who were working (or suggesting) the Nostr DM subscription flow they would have answered: "no, you don't get their email addresses, but you can send them uncensorable DMs!" -- and that, again, is getting everything backwards.

@ 3bf0c63f:aefa459d

# Nostr is not decentralized nor censorship-resistant Peter Todd has been [saying this](nostr:nevent1qqsq5zzu9ezhgq6es36jgg94wxsa2xh55p4tfa56yklsvjemsw7vj3cpp4mhxue69uhkummn9ekx7mqpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qy8hwumn8ghj7mn0wd68ytnddaksz9rhwden5te0dehhxarj9ehhsarj9ejx2aspzfmhxue69uhk7enxvd5xz6tw9ec82cspz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnyqy28wumn8ghj7un9d3shjtnwdaehgu3wvfnsz9nhwden5te0wfjkccte9ec8y6tdv9kzumn9wspzpn92tr3hexwgt0z7w4qz3fcch4ryshja8jeng453aj4c83646jxvxkyvs4) for a long time and all the time I've been thinking he is misunderstanding everything, but I guess a more charitable interpretation is that he is right. Nostr _today_ is indeed centralized. Yesterday I published two harmless notes with the exact same content at the same time. In two minutes the notes had a noticeable difference in responses:  The top one was published to `wss://nostr.wine`, `wss://nos.lol`, `wss://pyramid.fiatjaf.com`. The second was published to the relay where I generally publish all my notes to, `wss://pyramid.fiatjaf.com`, and that is announced on my [NIP-05 file](https://fiatjaf.com/.well-known/nostr.json) and on my [NIP-65](https://nips.nostr.com/65) relay list. A few minutes later I published that screenshot again in two identical notes to the same sets of relays, asking if people understood the implications. The difference in quantity of responses can still be seen today:  These results are skewed now by the fact that the two notes got rebroadcasted to multiple relays after some time, but the fundamental point remains. What happened was that a huge lot more of people saw the first note compared to the second, and if Nostr was really censorship-resistant that shouldn't have happened at all. Some people implied in the comments, with an air of obviousness, that publishing the note to "more relays" should have predictably resulted in more replies, which, again, shouldn't be the case if Nostr is really censorship-resistant. What happens is that most people who engaged with the note are _following me_, in the sense that they have instructed their clients to fetch my notes on their behalf and present them in the UI, and clients are failing to do that despite me making it clear in multiple ways that my notes are to be found on `wss://pyramid.fiatjaf.com`. If we were talking not about me, but about some public figure that was being censored by the State and got banned (or shadowbanned) by the 3 biggest public relays, the sad reality would be that the person would immediately get his reach reduced to ~10% of what they had before. This is not at all unlike what happened to dozens of personalities that were banned from the corporate social media platforms and then moved to other platforms -- how many of their original followers switched to these other platforms? Probably some small percentage close to 10%. In that sense Nostr today is similar to what we had before. Peter Todd is right that if the way Nostr works is that you just subscribe to a small set of relays and expect to get everything from them then it tends to get very centralized very fast, and this is the reality today. Peter Todd is wrong that Nostr is _inherently_ centralized or that it needs a _protocol change_ to become what it has always purported to be. He is in fact wrong today, because what is written above is not valid for all clients of today, and if we [drive in the right direction](nostr:naddr1qqykycekxd3nxdpcvgq3zamnwvaz7tmxd9shg6npvchxxmmdqgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqa2803ksy8) we can successfully make Peter Todd be more and more wrong as time passes, instead of the contrary. --- See also: - [Censorship-resistant relay discovery in Nostr](nostr:naddr1qqykycekxd3nxdpcvgq3zamnwvaz7tmxd9shg6npvchxxmmdqgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqa2803ksy8) - [A vision for content discovery and relay usage for basic social-networking in Nostr](nostr:naddr1qqyrxe33xqmxgve3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cywwjvq)

@ 3bf0c63f:aefa459d

# Censorship-resistant relay discovery in Nostr In [Nostr is not decentralized nor censorship-resistant](nostr:naddr1qqyrsdmpxgcrsepeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c4n8rw6) I said Nostr is centralized. Peter Todd thinks it is centralized by design, but I disagree. Nostr wasn't designed to be centralized. The idea was always that clients would follow people in the relays they decided to publish to, even if it was a single-user relay hosted in an island in the middle of the Pacific ocean. But the Nostr explanations never had any guidance about how to do this, and the protocol itself never had any enforcement mechanisms for any of this (because it would be impossible). My original idea was that clients would use some undefined combination of relay hints in reply tags and the (now defunct) `kind:2` relay-recommendation events plus some form of manual action ("it looks like Bob is publishing on relay X, do you want to follow him there?") to accomplish this. With the expectation that we would have a better idea of how to properly implement all this with more experience, Branle, my first working client didn't have any of that implemented, instead it used a stupid static list of relays with read/write toggle -- although it did publish relay hints and kept track of those internally and supported `kind:2` events, these things were not really useful. [Gossip](https://github.com/mikedilger/gossip) was the first client to implement a [truly censorship-resistant relay discovery mechanism](https://mikedilger.com/gossip-relay-model.mp4) that used NIP-05 hints (originally proposed by [Mike Dilger](nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgua442w)) relay hints and `kind:3` relay lists, and then with the simple insight of [NIP-65](https://nips.nostr.com/65) that got much better. After seeing it in more concrete terms, it became simpler to reason about it and the approach got popularized as the "gossip model", then implemented in clients like [Coracle](https://coracle.social) and [Snort](https://snort.social). Today when people mention the "gossip model" (or "outbox model") they simply think about NIP-65 though. Which I think is ok, but too restrictive. I still think there is a place for the NIP-05 hints, `nprofile` and `nevent` relay hints and specially relay hints in event tags. All these mechanisms are used together in [ZBD Social](nostr:naddr1qqyxgvek8qmryc3eqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chekfst), for example, but I believe also in the clients listed above. I don't think we should stop here, though. I think there are other ways, perhaps drastically different ways, to approach content propagation and relay discovery. I think manual action by users is underrated and could go a long way if presented in a nice UX (not conceived by people that think users are dumb animals), and who knows what. Reliance on third-parties, hardcoded values, social graph, and specially a mix of multiple approaches, is what Nostr needs to be censorship-resistant and what I hope to see in the future.

@ 450f1fea:d9473ecc

A German article, published by lawyer Viviane Fisher, available [here](https://2020news.de/bomb-shell-wie-die-italienischen-richter-auf-linie-gebracht-wurden/), proves corruption in the Italian judiciary against Covid injection victims. The whole article is available below, translated to English, and chillingly underlines the need for initiatives like [We The People](nostr:naddr1qqxnzdesxuunydfexumnzdfjqgsy2rclafajlcqg428lgue5rzk3ru6y7vqqlhapju9vwqr9m9rnanqrqsqqqa28s2qdjt) where the general public removes judicial matters from totally corrupt judiciaries. Listen to the article: https://media.nostr.build/av/201d5c6cb80e815f7e42777037230b9bc5c231b13aa3653825f44553062703a3.mp3 ### Bomb Shell: How the Italian judges were brought into line. Italian journalist [Andrea Zambrano](https://lanuovabq.it/it/andrea-zambrano) has discovered what may have been one of the reasons for the almost unanimous rulings in favor of vaccination narratives and against fundamental individual rights throughout Italy: a decision-making guide penned by the Italian Supreme Court. Text modules from the "Report for judges number 103 on legislative novelties of October 28, 2021", with which future lawsuits should be rejected, have found themselves as hot tracks in various judgments. With explanations on the topics of "*safe and effective vaccines*", "*constitutional conformity of the measures*", "*just obligation for oneself and others*", the judges were sworn in to the state narrative, which in Italy included mandatory vaccination for people over 50 years of age and for all healthcare workers, all teachers, law enforcement officers and all employees of the judiciary, as well as extremely strict 2G rules. The statements were based on false assumptions regarding a "*general consensus of the scientific community on the efficacy and safety*" of so-called "*vaccinations*". In part, these assumptions had already been refuted on October 28, 2021, but at the very least there was clear evidence of reasonable doubt about the accuracy of the presentation. The judge's report categorized the "*vaccines*" as absolutely safe and by definition effective, citing the unanimous conviction of all scientists. Compulsory vaccination - out of loyalty to the Republic - is fair and just, both for the vaccinated person and for others. The constitutional requirements were complied with in every case. On this line of argument, the discriminated, injured, disabled citizens and employees without the solidary green passport had to appear like a horde of baselessly rebellious egomaniacs to the judges called upon to rule in civil, criminal and administrative cases. The legally non-binding but impressive decision guide did not come from any judges but from the Italian Supreme Court, the equivalent of the German Federal Court of Justice. The Italian Supreme Court is responsible for the systematic and analytical review of case law and draws up maxims, reports and reviews of everything that is pronounced in the name of the Italian people. What would have happened if this vademecum, this guide to action for judges, had not existed? Would individual judges then have made greater use of their autonomy, which is particularly pronounced in Italy? In Italy, judges are appointed by a body of judges, the National Council of Judges, so their careers are not dependent on the mercy of the Minister of Justice, as they are in Germany. They are, however, dependent on the goodwill of their fellow judges. What is piquant in this context is that the chairman of the National Council of Judges is the President of the Republic, [Sergio Mattarella](https://www.google.com/search?client=safari&sca_esv=59f9c62adf8353ec&rls=en&q=Sergio+Mattarella&stick=H4sIAAAAAAAAAONgVuLSz9U3ME4uMLQsesRoyi3w8sc9YSmdSWtOXmNU4-IKzsgvd80rySypFJLgYoOy-KR4uJC08SxiFQxOLUrPzFfwTSwpSSxKzclJBACoVJrUWgAAAA&sa=X&ved=2ahUKEwijy-eAhaOEAxXFqP0HHfx-ABYQzIcDKAB6BAgmEAE), who, together with the then Prime Minister Mario Draghi, constantly proclaimed the fairy tale of safe and effective "*vaccination*" to the public. The two of them repeatedly told the population like a prayer wheel: "*If you don't get vaccinated, you kill yourself and others.*" The document in question, entitled "*The vaccination against Covid-19 and the obligation of the Green Pass in the current constitutional and legislative framework*", which is exclusively available in full to [La Nuova Bussola Quotidiana](https://lanuovabq.it/it/la-cassazione-dettava-la-linea-sugli-effetti-avversi-trascurabili) magazine, bears the signature of Judge Maria Acierno and her deputy Antonietta Scrima. The same document can be found in a slightly condensed version in the 2021 Yearbook, the collection of publications and files of the Supreme Court for the year 2021 ([printed there](https://lanuovabq.it/storage/docs/volume-iv-2021-massimario-civile-approfondimenti-tematici.pdf) from page 116 onwards).  It was written in October 2021, in the middle of the vaccination campaign to administer the third dose. This was the time when the scientific literature was already casting serious doubt on both the efficacy and the risk-free nature of the vaccination. The Astrazeneca product had already been rejected as unsuitable for mass use due to the occurrence of thromboses. The ninth report by AIFA, the Italian regulatory authority, available at the time pointed to 608 deaths following COVID-19 vaccinations. This alarming development was not included in the text written by Judge Milena D'Oriano. The most recently published yearbook for 2022 contains no updates on the topic, and the 2023 yearbook is not yet available to the public. The use of the vaccines to implement the vaccination obligation and the 2G rule constituted an off-label use in Italy, as it was used to allegedly prevent a viral infection with SARS CoV2 instead of only to prevent a severe course of COVID-19.  The conviction expressed in the action guide and thus conveyed to the judges is that "*all legal acts in the first phase of the emergency, such as the Emergency Ordinance, the D.P.C.M., and the ordinances of the Ministry of Health have also entailed restrictions on rights and constitutional freedoms*", but that these have been borne by the "*concern of authoritative jurists*". The difficult relationship between "*compulsory vaccination and the burden of vaccination*" requires the "*expression of the individual's duty of solidarity towards the community*" to be weighed against the "*expression of the individual's right to self-determination*". It is clear that, if one contrasts a supposedly risk-free "vaccination" that protects everyone with the seemingly excessive, individual self-determination excesses of the "vaccination opponents", a decision in favor of the solidarity-based vaccination requirement of a "small prick" is likely to be made. "*Self-determination is certainly a valuable asset, but it can exceed limits based on the duty of solidarity in the interest of the community*," writes Judge D'Oriano, concluding that "*the periodic bulletins on the course of the epidemic by the ISS (...) prove that vaccination prophylaxis is effective both in containing the symptoms of the disease, drastically reducing the risk of severe syndromes and in preventing the transmission of the infection*". The ISS, or Instituto Superiore de la Sanità, is the Italian equivalent of the RKI and attracted attention during the crisis by unleashing a huge shitstorm against its own critical employees who dared to express doubts about the safety of the "vaccinations" in the summer of 2022. Just as in Germany the word of the PEI and RKI about safe and effective "vaccination" was and is considered irrefutable - despite a large number of contradictory expert opinions such as those presented in the Solden trial - only the officially announced findings should be relevant to the Italian judges' decisions. However, why then did Judge D'Oriano not also take note of the EMA documents that had already appeared on the AIFA website on December 21, 2020, on the eve of the mass vaccination campaign, proving the inability of the Pfizer "vaccine" to prevent infection, giving the lie to Draghi's infamous catchphrase "*They don't get vaccinated - he, she gets infected and dies*"? Further evidence of substantial problems with the "vaccines" came from science and industry: The British Medical Journal published the news on February 10, 2022 that vaccinated people could become infected just as easily as unvaccinated people. Lancet publications also showed that the effectiveness against symptomatic Covid infection in vaccinated people decreases rapidly until it drops completely after about 6-7 months and even becomes negative. Wolfgang Philipp, Director of the European Health Agency HERA, told the European Parliamentary Committee of Inquiry into COVID19: "*If you want to have a vaccine that prevents transmission, good luck. We have not managed to find it, it is not yet available*". By order of the US Food and Drug Administration (FDA), Pfizer was forced to submit a report on its pharmacovigilance, which was conducted from December 1, 2020 to February 28, 2021. It revealed that "there were a total of 42,000 cases containing 158,000 reported adverse reactions, of which 25,000 were from Italy alone". None of this was included in the judge's report in 2022. Following the Supreme Court's assessment, the judges dismissed most of the lawsuits filed by citizens for suspension of work and wages due to their refusal to submit to the - allegedly constitutional - solidarity act of vaccination. The magazine La Bussola names cases: e.g. the tragic story of young Runa Cody and his unexplained death from pericarditis. The mother had already brought many documents to the courtroom in June 2021 proving the occurrence of perimyocarditis after "vaccination" by providing Aifa documents. The response of the competent judge in Civitavecchia was: "*At the time of administration and even today, the scientific literature on this subject was extremely scarce or absent*". Although deaths and harm had already been documented in international pharmacovigilance and addressed by renowned scientists, the Supreme Court report of October 28, 2021 shows a willingness to completely deny the existence of significant adverse effects. It relies exclusively on the latest available AIFA report of October 22, 2021, which later turned out to be manipulated. Worrying information about serious side effects has been deliberately suppressed by the decision-makers, which is now the subject of proceedings before the court in Rome and the ministerial court for former health minister Roberto Speranza, 2020News reported. On page 13 of the guide to action for their fellow judges, judges Maria Acierno and Antonietta Scripa write: "*It is scientifically proven and recognized that vaccines are one of the most effective preventive measures with a particularly high risk-benefit ratio and a very relevant ethical value as an expression of the duty of solidarity*". And - to justify compliance with Article 32 of the Constitution - they point out that "according to the Constitution, compulsory health treatment complies with the requirements of Article 32 if it is aimed at improving or maintaining the state of health of the subject to whom it is addressed and does not affect the health of the recipient". The constitutionality of compulsory vaccination could therefore only be claimed if all the already known and dramatically emerging multiple harms were consistently denied or if the sacrifice of the individual for the collective could be affirmed in a false risk-benefit assessment. In reality, however, the risk must be weighed up on an individual basis: the risk of the individual becoming infected with the virus and ending up in hospital in danger of death must be assessed in comparison to the (alleged) benefits they would gain from a "vaccination". On page 18 of the report, the judges state: "*In terms of safety, the monitoring carried out by AIFA through the pharmacovigilance system, which collects and evaluates all adverse event reports, shows a perfectly acceptable risk-benefit balance, since the harms resulting from the administration of the vaccine for SARS COV 2, which, given the extreme rarity of occurrence, must be considered rare and correlatable events that meet a statistical normality criterion with a very low and slightly higher incidence of short-term adverse reactions than has been known for years for ordinary vaccines*". They conclude that a possible Covid vaccination obligation, which would be provided for by law, would most likely have to be considered constitutional. A judge who would have wanted to counter such a convincing assessment of the factual and legal situation presented by the highest authority with his own arguments would have had to fear being exposed to similar hostility as the alleged "*anti-vaccinationists*" themselves.  How many judges have trusted this official and authoritative Supreme Court report and therefore dismissed the claims of the many victims who were forced to be vaccinated? It is high time to update the report with all the evidence that has emerged in the meantime and thus provide judges, public prosecutors and lawyers with better guidance for the legal proceedings. Not only with regard to the alleged effectiveness, but also and especially with regard to the high risks of the "vaccinations". Have other countries also been influenced in this way from "the very top"? We are staying on top of the issue.

@ f240c9c2:6c0c0a86

noStrudel、早いし機能も充実していてとても良いクライアント。でも個人的に画面下部のタブバーがごちゃっとしてるのが気に入らなかったので、雑にUIを破壊してみた。 ついでにフォントサイズがちょっと小さくて見づらかったので気持ち大きくした。 ## before  ## after  ## ブックマークレット版 ```js javascript:applyStyle%3D()%3D%3E%7B(customStyle%3Ddocument.createElement(%22style%22)).innerText%3D%60%20body%7Bfont-size%3Alarger%3B%7Dbutton%5Baria-label%3D%22Launchpad%22%5D%7Bdisplay%3Anone%3B%7Dbutton%5Baria-label%3D%22New%20Note%22%5D%7Bposition%3Aabsolute%3Bwidth%3A4rem%3Bheight%3A4rem%3Bbottom%3A4rem%3Bright%3A1.25rem%3Bborder-radius%3A50%25%3B%7D%60%2Cdocument.getElementsByTagName(%22head%22).item(0).appendChild(customStyle)%7D%2C-1%3D%3D%3Dwindow.location.href.search(%2F%5C%2F%5C%2Fnostrudel%5C.ninja%2F)%3Falert(%22noStrudelで実行しなはれ～%22)%3AapplyStyle()%3Bvoid(0); ``` [追加用リンク](javascript:applyStyle%3D()%3D%3E%7B(customStyle%3Ddocument.createElement(%22style%22)).innerText%3D%60%20body%7Bfont-size%3Alarge%3B%7Dbutton%5Baria-label%3D%22Launchpad%22%5D%7Bdisplay%3Anone%3B%7Dbutton%5Baria-label%3D%22New%20Note%22%5D%7Bposition%3Aabsolute%3Bwidth%3A4rem%3Bheight%3A4rem%3Bbottom%3A4rem%3Bright%3A1.25rem%3Bborder-radius%3A50%25%3B%7D%60%2Cdocument.getElementsByTagName(%22head%22).item(0).appendChild(customStyle)%7D%2C-1%3D%3D%3Dwindow.location.href.search(%2F%5C%2F%5C%2Fnostrudel%5C.ninja%2F)%3Falert(%22nostrudelで実行しなはれ～%22)%3AapplyStyle()%3Bvoid(0);) ## UserStyle版 「iOS Safariだからユーザースタイルとか使えなさそ〜」と思い込んでたら[普通に使えた](https://blog.kentokanai.net/userscripts/)のでブックマークレットにする必要なかった。 ```css /* ==UserStyle== @name noStrudelCustomStyle @include https://nostrudel.ninja/* ==/UserStyle== */ body{font-size:larger;} button[aria-label="Launchpad"]{display:none;} button[aria-label="New Note"]{position:absolute;width:4rem;height:4rem;bottom:4rem;right:1.25rem;border-radius:50%;} ``` [保存用リンク](https://gist.githubusercontent.com/ikanoasi10/1592ba02de4eeea13fb84c09ebdc5299/raw/2408427bc5eba6a1af07c794d113ec79a849e5c5/noStrudelCustomStyle.css)

@ d1d17471:5b15ed44

Nostrプロトコルを利用したアプリケーションの開発に役立つ資料をまとめていく場です。 ## プロトコル仕様書 ### nostr-protocol/nips https://github.com/nostr-protocol/nips Nostrプロトコルの仕様を定めるNIPs(Nostr Implementation Possibilities)を取りまとめるリポジトリ。 また、issue・PRは新規NIPの提案や既存NIPの改善などに関する議論を交わす場となっている。 必須仕様はすべて **NIP-01** にまとまっているので、まずはNIP-01を読みましょう ### nips-ja https://github.com/nostr-jp/nips-ja NIPsの日本語訳プロジェクト。 ## プロトコルの解説 ### Web記事 - [Nostrプロトコル(damus)を触ってみた](https://qiita.com/gpsnmeajp/items/77eee9535fb1a092e286) - [Nostr の面白さをエンジニア目線で解説してみる](https://zenn.dev/mattn/articles/cf43423178d65c) - [Nostr Scrapbox](https://scrapbox.io/nostr/) ### 書籍 - [Hello, Nostr! 先住民が教えるNostrの歩き方](https://nip-book.nostr-jp.org/book/1/) - [learn-nostr-by-crafting](https://github.com/nostr-jp/learn-nostr-by-crafting): 本書内記事「手を動かして学ぶNostrプロトコル」の演習用リポジトリ - [Hello, Nostr! Yo Bluesky! 分散SNSの最前線](https://nip-book.nostr-jp.org/book/2/) - [learn-nostr-by-crafting-2](https://github.com/nostr-jp/learn-nostr-by-crafting-2): 本書内記事「演習！作ってみよう「日本語 TL のぞき窓」の演習用リポジトリ - [Software Design誌 連載「新時代の分散SNS Nostr」(2023年7月号~12月号)](https://gihyo.jp/magazine/SD/backnumber) - 第1回(7月号)〜第3回(9月号): Nostrプロトコルやアプリケーションの紹介 - 第4回(10月号): Nostrプロトコルの解説 - 第5回(11月号), 第6回(12月号): Nostrアプリケーションの実装解説 ### 動画 - [分散型SNSプロトコル nostrの解説](https://www.youtube.com/watch?v=vB905DhX9nQ) ## ライブラリ ### nostr-tools https://github.com/nbd-wtf/nostr-tools Nostrアプリケーションの開発で頻出する処理を提供するJS/TSライブラリ。 - 秘密鍵の生成・秘密鍵から公開鍵への変換 - イベントの署名・検証 - リレーとの通信(イベント購読・発行) - bech32形式識別子(`npub`, `nsec`, `nevent`などから始まる識別子、NIP-19)のencode/decode - ドメイン認証(NIP-05)の検証 - etc... ### NDK https://github.com/nostr-dev-kit/ndk Nostrプロトコルに対する、nostr-toolsよりも高いレイヤの抽象を提供するJS/TSライブラリ [ドキュメント](https://ndk.fyi/docs/) ### rx-nostr https://github.com/penpenpng/rx-nostr イベント購読をはじめとするNostrリレーとのやり取りを、RxのSubscriptionとして扱えるようにするJS/TSライブラリ。 [ドキュメント](https://penpenpng.github.io/rx-nostr/) ### nostr-fetch https://github.com/jiftechnify/nostr-fetch Nostrリレーから過去のイベントを取得する機能を提供するJS/TSライブラリ。最新のReplaceable Eventの取得にも便利。 (リレーから過去のイベントを正確に取得しようと思うと、落とし穴が多くて意外と大変。詳細は[こちら](https://speakerdeck.com/jiftechnify/nostrnorirekaralou-renakusubetenoibentowoqu-tutekuruji-shu)) ### rust-nostr https://github.com/rust-nostr/nostr Rust向けにNostrプロトコル全般の抽象を提供するライブラリ。機能ごとにクレートが分割されている。 - nostr: Nostrプロトコルの低レイヤの実装 - nostr-sdk: nostrクレートをベースとする、より高レイヤの抽象。クライアントの実装向け - nostr-database: Nostrイベントの永続化処理に関する抽象。 - etc また、さまざまなプログラミング言語向けのbindingが提供されている ### go-nostr https://github.com/nbd-wtf/go-nostr Nostrプロトコル全般の抽象を提供するGoライブラリ。 ### eventstore https://github.com/fiatjaf/eventstore Nostrイベントの永続化処理に関する抽象を提供するGoライブラリ。 ### khatru https://github.com/fiatjaf/khatru Go向けのNostrリレー実装用のフレームワーク。

@ b3e43e8c:e3068b5f

ああテストだよテストだよ

@ 3bf0c63f:aefa459d

# Nostr: a quick introduction, attempt #1  Nostr doesn't have a material existence, it is not a website or an app. Nostr is just a description what kind of messages each computer can send to the others and vice-versa. It's a very simple thing, but the fact that such description exists allows different apps to connect to different servers automatically, without people having to talk behind the scenes or sign contracts or anything like that. When you use a Nostr _client_ that is what happens, your _client_ will connect to a bunch of servers, called _relays_, and all these _relays_ will speak the same "language" so your _client_ will be able to publish notes to them all and also download notes from other people. That's basically what Nostr is: this communication layer between the _client_ you run on your phone or desktop computer and the _relay_ that someone else is running on some server somewhere. There is no central authority dictating who can connect to whom or even anyone who knows for sure where each note is stored. If you think about it, Nostr is very much like the internet itself: there are millions of websites out there, and basically anyone can run a new one, and there are websites that allow you to store and publish your stuff on them. The added benefit of Nostr is that this unified "language" that all Nostr _clients_ speak allow them to switch very easily and cleanly between _relays_. So if one _relay_ decides to ban someone that person can switch to publishing to others _relays_ and their audience will quickly follow them there. Likewise, it becomes much easier for _relays_ to impose any restrictions they want on their users: no _relay_ has to uphold a moral ground of "absolute free speech": each _relay_ can decide to delete notes or ban users for no reason, or even only store notes from a preselected set of people and no one will be entitled to complain about that. There are some bad things about this design: on Nostr there are no guarantees that _relays_ will have the notes you want to read or that they will store the notes you're sending to them. We can't just assume all _relays_ will have everything — much to the contrary, as Nostr grows more _relays_ will exist and people will tend to publishing to a small set of all the _relays_, so depending on the decisions each _client_ takes when publishing and when fetching notes, users may see a different set of replies to a note, for example, and be confused. Another problem with the idea of publishing to multiple servers is that they may be run by all sorts of malicious people that may edit your notes. Since no one wants to see garbage published under their name, Nostr fixes that by requiring notes to have a cryptographic signature. This signature is attached to the note and verified by everybody at all times, which ensures the notes weren't tampered (if any part of the note is changed even by a single character that would cause the signature to become invalid and then the note would be dropped). The fix is perfect, except for the fact that it introduces the requirement that each user must now hold this 63-character code that starts with "nsec1", which they must not reveal to anyone. Although annoying, this requirement brings another benefit: that users can automatically have the same identity in many different contexts and even use their Nostr identity to login to non-Nostr websites easily without having to rely on any third-party. To conclude: Nostr is like the internet (or the internet of some decades ago): a little chaotic, but very open. It is better than the internet because it is structured and actions can be automated, but, like in the internet itself, nothing is guaranteed to work at all times and users many have to do some manual work from time to time to fix things. Plus, there is the cryptographic key stuff, which is painful, but cool.

@ 3bf0c63f:aefa459d

# Anglicismos estúpidos no português contemporâneo Palavras e expressões que ninguém deveria usar porque não têm o sentido que as pessoas acham que têm, são apenas aportuguesamentos de palavras inglesas que por nuances da história têm um sentido ligeiramente diferente em inglês. Cada erro é acompanhado também de uma sugestão de como corrigi-lo. ### Palavras que existem em português com sentido diferente - _submissão_ (de trabalhos): **envio**, **apresentação** - _disrupção_: **perturbação** - _assumir_: **considerar**, **pressupor**, **presumir** - _realizar_: **perceber** - _endereçar_: **tratar de** - _suporte_ (ao cliente): **atendimento** - _suportar_ (uma idéia, um projeto): **apoiar**, **financiar** - _suportar_ (uma função, recurso, característica): **oferecer**, **ser compatível com** - _literacia_: **instrução**, **alfabetização** - _convoluto_: **complicado**. - _acurácia_: **precisão**. - _resiliência_: **resistência**. ### Aportuguesamentos desnecessários - _estartar_: **iniciar**, **começar** - _treidar_: **negociar**, **especular** ### Expressões - _"não é sobre..."_: **"não se trata de..."** ## Ver também - [Algumas expressões e ditados excelentes da língua portuguesa, e outras não tão excelentes assim](https://fiatjaf.alhur.es/expressões-e-ditados.txt)

@ 3bf0c63f:aefa459d

# Pequenos problemas que o Estado cria para a sociedade e que não são sempre lembrados - **vale-transporte**: transferir o custo com o transporte do funcionário para um terceiro o estimula a morar longe de onde trabalha, já que morar perto é normalmente mais caro e a economia com transporte é inexistente. - **atestado médico**: o direito a faltar o trabalho com atestado médico cria a exigência desse atestado para todas as situações, substituindo o livre acordo entre patrão e empregado e sobrecarregando os médicos e postos de saúde com visitas desnecessárias de assalariados resfriados. - **prisões**: com dinheiro mal-administrado, burocracia e péssima alocação de recursos -- problemas que empresas privadas em competição (ou mesmo sem qualquer competição) saberiam resolver muito melhor -- o Estado fica sem presídios, com os poucos existentes entupidos, muito acima de sua alocação máxima, e com isto, segundo a bizarra corrente de responsabilidades que culpa o juiz que condenou o criminoso por sua morte na cadeia, juízes deixam de condenar à prisão os bandidos, soltando-os na rua. - **justiça**: entrar com processos é grátis e isto faz proliferar a atividade dos advogados que se dedicam a criar problemas judiciais onde não seria necessário e a entupir os tribunais, impedindo-os de fazer o que mais deveriam fazer. - **justiça**: como a justiça só obedece às leis e ignora acordos pessoais, escritos ou não, as pessoas não fazem acordos, recorrem sempre à justiça estatal, e entopem-na de assuntos que seriam muito melhor resolvidos entre vizinhos. - **leis civis**: as leis criadas pelos parlamentares ignoram os costumes da sociedade e são um incentivo a que as pessoas não respeitem nem criem normas sociais -- que seriam maneiras mais rápidas, baratas e satisfatórias de resolver problemas. - **leis de trãnsito**: quanto mais leis de trânsito, mais serviço de fiscalização são delegados aos policiais, que deixam de combater crimes por isto (afinal de contas, eles não querem de fato arriscar suas vidas combatendo o crime, a fiscalização é uma excelente desculpa para se esquivarem a esta responsabilidade). - **financiamento educacional**: é uma espécie de subsídio às faculdades privadas que faz com que se criem cursos e mais cursos que são cada vez menos recheados de algum conhecimento ou técnica útil e cada vez mais inúteis. - **leis de tombamento**: são um incentivo a que o dono de qualquer área ou construção "histórica" destrua todo e qualquer vestígio de história que houver nele antes que as autoridades descubram, o que poderia não acontecer se ele pudesse, por exemplo, usar, mostrar e se beneficiar da história daquele local sem correr o risco de perder, de fato, a sua propriedade. - **zoneamento urbano**: torna as cidades mais espalhadas, criando uma necessidade gigantesca de carros, ônibus e outros meios de transporte para as pessoas se locomoverem das zonas de moradia para as zonas de trabalho. - **zoneamento urbano**: faz com que as pessoas percam horas no trânsito todos os dias, o que é, além de um desperdício, um atentado contra a sua saúde, que estaria muito melhor servida numa caminhada diária entre a casa e o trabalho. - **zoneamento urbano**: torna ruas e as casas menos seguras criando zonas enormes, tanto de residências quanto de indústrias, onde não há movimento de gente alguma. - **escola obrigatória + currículo escolar nacional**: emburrece todas as crianças. - **leis contra trabalho infantil**: tira das crianças a oportunidade de aprender ofícios úteis e levar um dinheiro para ajudar a família. - **licitações**: como não existem os critérios do mercado para decidir qual é o melhor prestador de serviço, criam-se comissões de pessoas que vão decidir coisas. isto incentiva os prestadores de serviço que estão concorrendo na licitação a tentar comprar os membros dessas comissões. isto, fora a corrupção, gera problemas reais: __(i)__ a escolha dos serviços acaba sendo a pior possível, já que a empresa prestadora que vence está claramente mais dedicada a comprar comissões do que a fazer um bom trabalho (este problema afeta tantas áreas, desde a construção de estradas até a qualidade da merenda escolar, que é impossível listar aqui); __(ii)__ o processo corruptor acaba, no longo prazo, eliminando as empresas que prestavam e deixando para competir apenas as corruptas, e a qualidade tende a piorar progressivamente. - **cartéis**: o Estado em geral cria e depois fica refém de vários grupos de interesse. o caso dos taxistas contra o Uber é o que está na moda hoje (e o que mostra como os Estados se comportam da mesma forma no mundo todo). - **multas**: quando algum indivíduo ou empresa comete uma fraude financeira, ou causa algum dano material involuntário, as vítimas do caso são as pessoas que sofreram o dano ou perderam dinheiro, mas o Estado tem sempre leis que prevêem multas para os responsáveis. A justiça estatal é sempre muito rígida e rápida na aplicação dessas multas, mas relapsa e vaga no que diz respeito à indenização das vítimas. O que em geral acontece é que o Estado aplica uma enorme multa ao responsável pelo mal, retirando deste os recursos que dispunha para indenizar as vítimas, e se retira do caso, deixando estas desamparadas. - **desapropriação**: o Estado pode pegar qualquer propriedade de qualquer pessoa mediante uma indenização que é necessariamente inferior ao valor da propriedade para o seu presente dono (caso contrário ele a teria vendido voluntariamente). - **seguro-desemprego**: se há, por exemplo, um prazo mínimo de 1 ano para o sujeito ter direito a receber seguro-desemprego, isto o incentiva a planejar ficar apenas 1 ano em cada emprego (ano este que será sucedido por um período de desemprego remunerado), matando todas as possibilidades de aprendizado ou aquisição de experiência naquela empresa específica ou ascensão hierárquica. - **previdência**: a previdência social tem todos os defeitos de cálculo do mundo, e não importa muito ela ser uma forma horrível de poupar dinheiro, porque ela tem garantias bizarras de longevidade fornecidas pelo Estado, além de ser compulsória. Isso serve para criar no imaginário geral a idéia da __aposentadoria__, uma época mágica em que todos os dias serão finais de semana. A idéia da aposentadoria influencia o sujeito a não se preocupar em ter um emprego que faça sentido, mas sim em ter um trabalho qualquer, que o permita se aposentar. - **regulamentação impossível**: milhares de coisas são proibidas, há regulamentações sobre os aspectos mais mínimos de cada empreendimento ou construção ou espaço. se todas essas regulamentações fossem exigidas não haveria condições de produção e todos morreriam. portanto, elas não são exigidas. porém, o Estado, ou um agente individual imbuído do poder estatal pode, se desejar, exigi-las todas de um cidadão inimigo seu. qualquer pessoa pode viver a vida inteira sem cumprir nem 10% das regulamentações estatais, mas viverá também todo esse tempo com medo de se tornar um alvo de sua exigência, num estado de terror psicológico. - **perversão de critérios**: para muitas coisas sobre as quais a sociedade normalmente chegaria a um valor ou comportamento "razoável" espontaneamente, o Estado dita regras. estas regras muitas vezes não são obrigatórias, são mais "sugestões" ou limites, como o salário mínimo, ou as 44 horas semanais de trabalho. a sociedade, porém, passa a usar esses valores como se fossem o normal. são raras, por exemplo, as ofertas de emprego que fogem à regra das 44h semanais. - **inflação**: subir os preços é difícil e constrangedor para as empresas, pedir aumento de salário é difícil e constrangedor para o funcionário. a inflação força as pessoas a fazer isso, mas o aumento não é automático, como alguns economistas podem pensar (enquanto alguns outros ficam muito satisfeitos de que esse processo seja demorado e difícil). - **inflação**: a inflação destrói a capacidade das pessoas de julgar preços entre concorrentes usando a própria memória. - **inflação**: a inflação destrói os cálculos de lucro/prejuízo das empresas e prejudica enormemente as decisões empresariais que seriam baseadas neles. - **inflação**: a inflação redistribui a riqueza dos mais pobres e mais afastados do sistema financeiro para os mais ricos, os bancos e as megaempresas. - **inflação**: a inflação estimula o endividamento e o consumismo. - **lixo:** ao prover coleta e armazenamento de lixo "grátis para todos" o Estado incentiva a criação de lixo. se tivessem que pagar para que recolhessem o seu lixo, as pessoas (e conseqüentemente as empresas) se empenhariam mais em produzir coisas usando menos plástico, menos embalagens, menos sacolas. - **leis contra crimes financeiros:** ao criar legislação para dificultar acesso ao sistema financeiro por parte de criminosos a dificuldade e os custos para acesso a esse mesmo sistema pelas pessoas de bem cresce absurdamente, levando a um percentual enorme de gente incapaz de usá-lo, para detrimento de todos -- e no final das contas os grandes criminosos ainda conseguem burlar tudo.

@ 3bf0c63f:aefa459d

# `bitcoind` decentralization It is better to have multiple curator teams, with different vetting processes and release schedules for `bitcoind` than a single one. "More eyes on code", "Contribute to Core", "Everybody should audit the code". All these points repeated again and again fell to Earth on the day it was discovered that Bitcoin Core developers merged a variable name change from "blacklist" to "blocklist" without even discussing or acknowledging the fact that that innocent pull request opened by a sybil account was a social attack. After a big lot of people manifested their dissatisfaction with that event on Twitter and on GitHub, most Core developers simply ignored everybody's concerns or even personally attacked people who were complaining. The event has shown that: 1) Bitcoin Core ultimately rests on the hands of a couple maintainers and they decide what goes on the GitHub repository[^pr-merged-very-quickly] and the binary releases that will be downloaded by thousands; 2) Bitcoin Core is susceptible to social attacks; 2) "More eyes on code" don't matter, as these extra eyes can be ignored and dismissed. ## Solution: `bitcoind` decentralization If usage was spread across 10 different `bitcoind` flavors, the network would be much more resistant to social attacks to a single team. This has nothing to do with the question on if it is better to have multiple different Bitcoin node implementations or not, because here we're basically talking about the same software. Multiple teams, each with their own release process, their own logo, some subtle changes, or perhaps no changes at all, just a different name for their `bitcoind` flavor, and that's it. Every day or week or month or year, each flavor merges all changes from Bitcoin Core on their own fork. If there's anything suspicious or too leftist (or perhaps too rightist, in case there's a leftist `bitcoind` flavor), maybe they will spot it and not merge. This way we keep the best of both worlds: all software development, bugfixes, improvements goes on Bitcoin Core, other flavors just copy. If there's some non-consensus change whose efficacy is debatable, one of the flavors will merge on their fork and test, and later others -- including Core -- can copy that too. Plus, we get resistant to attacks: in case there is an attack on Bitcoin Core, only 10% of the network would be compromised. the other flavors would be safe. ## Run Bitcoin Knots The first example of a `bitcoind` software that follows Bitcoin Core closely, adds some small changes, but has an independent vetting and release process is [Bitcoin Knots][knots], maintained by the incorruptible Luke DashJr. Next time you decide to run `bitcoind`, run Bitcoin Knots instead and contribute to `bitcoind` decentralization! --- ### See also: - [How to attack Bitcoin, Anthony Towns' take](nostr:naddr1qqyrywphxdskzwp5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cwx779x) [^pr-merged-very-quickly]: See [PR 20624](https://github.com/bitcoin/bitcoin/pull/20624), for example, a very complicated change that [could be introducing bugs or be a deliberate attack](http://www.erisian.com.au/wordpress/2021/01/07/bitcoin-in-2021), merged in 3 days without time for discussion. [knots]: https://bitcoinknots.org/

@ 3bf0c63f:aefa459d

# Drivechain Understanding Drivechain requires a shift from the paradigm most bitcoiners are used to. It is not about "trustlessness" or "mathematical certainty", but game theory and incentives. (Well, Bitcoin in general is also that, but people prefer to ignore it and focus on some illusion of trustlessness provided by mathematics.) Here we will describe the basic mechanism (simple) and incentives (complex) of ["hashrate escrow"](https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki) and how it enables a 2-way peg between the mainchain (Bitcoin) and various sidechains. The full concept of "Drivechain" also involves blind merged mining (i.e., the sidechains mine themselves by publishing their block hashes to the mainchain without the miners having to run the sidechain software), but this is much easier to understand and can be accomplished either by [the BIP-301 mechanism](https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki) or by [the Spacechains mechanism](https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5). ## How does hashrate escrow work from the point of view of Bitcoin? A new address type is created. Anything that goes in that is locked and can only be spent if all miners agree on the _Withdrawal Transaction_ (`WT^`) that will spend it for 6 months. There is one of these special addresses for each sidechain. To gather miners' agreement `bitcoind` keeps track of the "score" of all transactions that could possibly spend from that address. On every block mined, for each sidechain, the miner can use a portion of their coinbase to either increase the score of one `WT^` by 1 while decreasing the score of all others by 1; or they can decrease the score of all `WT^`s by 1; or they can do nothing. Once a transaction has gotten a score high enough, it is published and funds are effectively transferred from the sidechain to the withdrawing users. If a timeout of 6 months passes and the score doesn't meet the threshold, that `WT^` is discarded. ## What does the above procedure _mean_? It means that people can transfer coins from the mainchain to a sidechain by depositing to the special address. Then they can withdraw from the sidechain by making a special withdraw transaction in the sidechain. The special transaction somehow freezes funds in the sidechain while a transaction that aggregates all withdrawals into a single mainchain `WT^`, which is then submitted to the mainchain miners so they can start voting on it and finally after some months it is published. Now the crucial part: _the validity of the `WT^` is not verified by the Bitcoin mainchain rules_, i.e., if Bob has requested a withdraw from the sidechain to his mainchain address, but someone publishes a wrong `WT^` that instead takes Bob's funds and sends them to Alice's main address there is no way the mainchain will know that. What determines the "validity" of the `WT^` is the miner vote score and only that. It is the job of miners to vote correctly -- and for that they may want to run the sidechain node in SPV mode so they can attest for the existence of a reference to the `WT^` transaction in the sidechain blockchain (which then ensures it is ok) or do these checks by some other means. ## What? 6 months to get my money back? Yes. But no, in practice anyone who wants their money back will be able to use an atomic swap, submarine swap or other similar service to transfer funds from the sidechain to the mainchain and vice-versa. The long delayed withdraw costs would be incurred by few liquidity providers that would gain some small profit from it. ## Why bother with this at all? Drivechains solve many different problems: ### It enables experimentation and new use cases for Bitcoin Issued assets, fully private transactions, stateful blockchain contracts, turing-completeness, decentralized games, some "DeFi" aspects, prediction markets, futarchy, decentralized and yet meaningful human-readable names, big blocks with a ton of normal transactions on them, a chain optimized only for Lighting-style networks to be built on top of it. These are some ideas that may have merit to them, but were never _actually_ tried because they couldn't be tried with real Bitcoin or inferfacing with real bitcoins. They were either relegated to the shitcoin territory or to custodial solutions like Liquid or RSK that may have failed to gain network effect because of that. ### It solves conflicts and infighting Some people want fully private transactions in a UTXO model, others want "accounts" they can tie to their name and build reputation on top; some people want simple multisig solutions, others want complex code that reads a ton of variables; some people want to put all the transactions on a global chain in batches every 10 minutes, others want off-chain instant transactions backed by funds previously locked in channels; some want to spend, others want to just hold; some want to use blockchain technology to solve all the problems in the world, others just want to solve money. With Drivechain-based sidechains all these groups can be happy simultaneously and don't fight. Meanwhile they will all be using the same money and contributing to each other's ecosystem even unwillingly, it's also easy and free for them to change their group affiliation later, which reduces cognitive dissonance. ### It solves "scaling" Multiple chains like the ones described above would certainly do a lot to accomodate many more transactions that the current Bitcoin chain can. One could have special Lightning Network chains, but even just big block chains or big-block-mimblewimble chains or whatnot could probably do a good job. Or even something less cool like 200 independent chains just like Bitcoin is today, no extra features (and you can call it "sharding"), just that would already multiply the current total capacity by 200. Use your imagination. ### It solves the blockchain security budget issue The calculation is simple: you imagine what security budget is reasonable for each block in a world without block subsidy and divide that for the amount of bytes you can fit in a single block: that is the price to be paid in _satoshis per byte_. In reasonable estimative, the price necessary for every Bitcoin transaction goes to very large amounts, such that not only any day-to-day transaction has insanely prohibitive costs, but also Lightning channel opens and closes are impracticable. So without a solution like Drivechain you'll be left with only one alternative: pushing Bitcoin usage to trusted services like Liquid and RSK or custodial Lightning wallets. With Drivechain, though, there could be thousands of transactions happening in sidechains and being all aggregated into a sidechain block that would then pay a very large fee to be published (via blind merged mining) to the mainchain. Bitcoin security guaranteed. ### It keeps Bitcoin decentralized Once we have sidechains to accomodate the normal transactions, the mainchain functionality can be reduced to be only a "hub" for the sidechains' comings and goings, and then the maximum block size for the mainchain can be reduced to, say, 100kb, which would make running a full node very very easy. ## Can miners steal? Yes. If a group of coordinated miners are able to secure the majority of the hashpower and keep their coordination for 6 months, they can publish a `WT^` that takes the money from the sidechains and pays to themselves. ## Will miners steal? No, because the incentives are such that they won't. Although it may look at first that stealing is an obvious strategy for miners as it is free money, there are many costs involved: 1. The cost of **ceasing blind-merged mining returns** -- as stealing will kill a sidechain, all the fees from it that miners would be expected to earn for the next years are gone; 2. The cost of **Bitcoin price going down**: If a steal is successful that will mean Drivechains are not safe, therefore Bitcoin is less useful, and miner credibility will also be hurt, which are likely to cause the Bitcoin price to go down, which in turn may kill the miners' businesses and savings; 3. The cost of **coordination** -- assuming miners are just normal businesses, they just want to do their work and get paid, but stealing from a Drivechain will require coordination with other miners to conduct an immoral act in a way that has many pitfalls and is likely to be broken over the months; 4. The cost of **miners leaving your mining pool**: when we talked about "miners" above we were actually talking about mining pools operators, so they must also consider the risk of miners migrating from their mining pool to others as they begin the process of stealing; 5. The cost of **community goodwill** -- when participating in a steal operation, a miner will suffer a ton of backlash from the community. Even if the attempt fails at the end, the fact that it was attempted will contribute to growing concerns over exaggerated miners power over the Bitcoin ecosystem, which may end up causing the community to agree on a hard-fork to change the mining algorithm in the future, or to do something to increase participation of more entities in the mining process (such as development or cheapment of new ASICs), which have a chance of decreasing the profits of current miners. Another point to take in consideration is that one may be inclined to think a newly-created sidechain or a sidechain with relatively low usage may be more easily stolen from, since the blind merged mining returns from it (point 1 above) are going to be small -- but the fact is also that a sidechain with small usage will also have less money to be stolen from, and since the other costs besides 1 are less elastic at the end it will not be worth stealing from these too. All of the above consideration are valid only if miners are stealing from _good sidechains_. If there is a sidechain that is doing things wrong, scamming people, not being used at all, or is full of bugs, for example, that will be perceived as a bad sidechain, and then miners can and will safely steal from it and kill it, which will be perceived as a good thing by everybody. ## What do we do if miners steal? Paul Sztorc has suggested in the past that a user-activated soft-fork could prevent miners from stealing, i.e., most Bitcoin users and nodes issue a rule [similar to this one](https://twitter.com/LukeDashjr/status/1126221228182843398) to invalidate the inclusion of a faulty `WT^` and thus cause any miner that includes it in a block to be relegated to their own Bitcoin fork that other nodes won't accept. This suggestion has made people think Drivechain is a sidechain solution _backed by user-actived soft-forks for safety_, which is very far from the truth. Drivechains must not and will not rely on this kind of soft-fork, although they are possible, as the coordination costs are too high and no one should ever expect these things to happen. If even with all the incentives against them (see above) miners do still steal from a _good sidechain_ that will mean _the failure of the Drivechain experiment_. It will very likely also mean _the failure of the Bitcoin experiment_ too, as it will be proven that miners can coordinate to act maliciously over a prolonged period of time regardless of economic and social incentives, meaning they are probably in it just for attacking Bitcoin, backed by nation-states or something else, and therefore no Bitcoin transaction in the mainchain is to be expected to be safe ever again. ## Why use this and not a full-blown trustless and open sidechain technology? Because it is impossible. If you ever heard someone saying "just use a sidechain", "do this in a sidechain" or anything like that, be aware that these people are either talking about "federated" sidechains (i.e., funds are kept in custody by a group of entities) or they are talking about Drivechain, or they are disillusioned and think it is possible to do sidechains in any other manner. ### No, I mean a trustless 2-way peg with correctness of the withdrawals verified by the Bitcoin protocol! That is not possible unless Bitcoin verifies all transactions that happen in all the sidechains, which would be akin to drastically increasing the blocksize and expanding the Bitcoin rules in tons of ways, i.e., a terrible idea that no one wants. ### What about the Blockstream sidechains whitepaper? Yes, that was a way to do it. The Drivechain hashrate escrow is a conceptually simpler way to achieve the same thing with improved incentives, less junk in the chain, more safety. ## Isn't the hashrate escrow a very complex soft-fork? Yes, but it is much simpler than SegWit. And, unlike SegWit, it doesn't force anything on users, i.e., it isn't a mandatory blocksize increase. ## Why should we expect miners to care enough to participate in the voting mechanism? Because it's in their own self-interest to do it, and it costs very little. Today over half of the miners mine RSK. It's not blind merged mining, it's a [very convoluted process that requires them to run a RSK full node](https://developers.rsk.co/rsk/architecture/mining/implementation-guide/). For the Drivechain sidechains, an SPV node would be enough, or maybe just getting data from a block explorer API, so much much simpler. ## What if I still don't like Drivechain even after reading this? That is the entire point! You don't have to like it or use it as long as you're fine with other people using it. The hashrate escrow special addresses will not impact you at all, validation cost is minimal, and you get the benefit of people who want to use Drivechain migrating to their own sidechains and freeing up space for you in the mainchain. See also the point above about infighting. ## See also * [Podcast episode with Ruben Somsen and Aaron van Wirdum explaining Drivechain](https://www.youtube.com/watch?v=DhU6nsB5Z-0) * [Alternatives to Drivechain](nostr:naddr1qqyrqenzvvukvcfkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823csjg2t6) * [Drivechain comparison with Ethereum](nostr:naddr1qqyx2dp58qcx2wpjqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cane7px)

@ 3bf0c63f:aefa459d

# A violência é uma forma de comunicação A violência é uma forma de comunicação: um serial killer, um pai que bate no filho, uma briga de torcidas, uma sessão de tortura, uma guerra, um assassinato passional, uma briga de bar. Em todos esses se pode enxergar uma mensagem que está tentando ser transmitida, que não foi compreendida pelo outro lado, que não pôde ser expressa, e, quando o transmissor da mensagem sentiu que não podia ser totalmente compreendido em palavras, usou essa outra forma de comunicação. Quando uma ofensa em um bar descamba para uma briga, por exemplo, o que há é claramente uma tentativa de uma ofensa maior ainda pelo lado do que iniciou a primeira, a briga não teria acontecido se ele a tivesse conseguido expressar em palavras tão claras que toda a audiência de bêbados compreendesse, o que estaria além dos limites da linguagem, naquele caso, o soco com o mão direita foi mais eficiente. Poderia ser também a defesa argumentativa: "eu não sou um covarde como você está dizendo" -- mas o bar não acreditaria nessa frase solta, a comunicação não teria obtido o sucesso desejado. A explicação para o fato da redução da violência à medida em que houve progresso da civilização está na melhora da eficiência da comunicação humana: a escrita, o refinamento da expressão lingüística, o aumento do alcance da palavra falada com rádio, a televisão e a internet. Se essa eficiência diminuir, porque não há mais acordo quanto ao significado das palavras, porque as pessoas não estão nem aí para se o que escrevem é bom ou não, ou porque são incapazes de compreender qualquer coisa, deve aumentar proporcionalmente a violência.

@ 3bf0c63f:aefa459d

# Problemas com Russell Kirk A idéia central da “política da prudência[^1]” de Russell Kirk me parece muito correta, embora tenha sido melhor formulada pior no seu enorme livro do que em uma pequena frase do joanadarquista Lucas Souza: “o conservadorismo é importante, porque tem muita gente com idéia errada por aí, e nós podemos não saber distingüi-las”. Porém, há alguns problemas que precisam ser esclarecidos, ou melhor explicados, e que me impedem de enxergar os seus argumentos como refutação final do meu já tão humilde (embora feroz) anarquismo. São eles: I Percebo alguma coisa errada, não sei bem onde, entre a afirmação de que toda ideologia é ruim, ou “todas as ideologias causam confusão[^2]”, e a proposta conservadora de “conservar o mundo da ordem que herdamos, ainda que em estado imperfeito, de nossos ancestrais[^3]”. Ora, sem precisar cair em exemplos como o do partido conservador inglês -- que conservava a política inglesa sempre onde estava, e se alternava no governo com o partido trabalhista, que a levava cada vez mais um pouco à esquerda --, está embutida nessa frase, talvez, a idéia, que ao mesmo tempo é clara e ferrenhamente combatida pelos próprios conservadores, de que a história é da humanidade é uma história de progresso linear rumo a uma situação melhor. Querer conservar o mundo da ordem que herdamos significa conservar também os vários erros que podem ter sido cometidos pelos nossos ancestrais mais recentes, e conservá-los mesmo assim, acusando toda e qualquer tentativa de propôr soluções a esses erros de ideologia? Ou será que conservar o mundo da ordem é escolher um período determinado que seja tido como o auge da história humana e tentar restaurá-lo em nosso próprio tempo? Não seria isto ideologia? Ou, ainda, será que conservar o mundo da ordem é selecionar, entre vários períodos do passado, alguns pedaços que o conservador considerar ótimos em cada sociedade, fazer dali uma mistura de sociedade ideal baseada no passado e então tentar implementá-la? Quem saberia dizer quais são as partes certas? II Sobre a questão do que mantém a sociedade civil coesa, Russell Kirk, opondo-a à posição libertária de que o nexo da sociedade é o autointeresse, declara que a posição conservadora é a de que “a sociedade é uma comunidade de almas, que une os mortos, os vivos e os ainda não nascidos, e que se harmoniza por aquilo que Aristóteles chamou de amizade e os cristãos chamam de caridade ou amor ao próximo”. Esta é uma posição muito correta, mas me parece estar em contradição com a defesa do Estado que ele faz na mesma página e na seguinte. O que me parece errado é que a sociedade não pode ser, ao mesmo tempo, uma “comunidade baseada no amor ao próximo” e uma comunidade que “requer não somente que as paixões dos indivíduos sejam subjugadas, mas que, mesmo no povo e no corpo social, bem como nos indivíduos, as inclinações dos homens, amiúde, devam ser frustradas, a vontade controlada e as paixões subjugadas” e, pior, que “isso somente pode ser feito por um poder exterior”. Disto aí podemos tirar que, da mesma forma que Kirk define a posição libertária como sendo a de que o autointeresse é que mantém a sociedade civil coesa, a posição conservadora seria então a de que essa coesão vem apenas do Estado, e não de qualquer ligação entre vivos e mortos, ou do amor ao próximo. Já que, sem o Estado, diz, ele, citando Thomas Hobbes, a condição do homem é “solitária, pobre, sórdida, embrutecida e curta”? [^1]: este é o nome do livro e também um outro nome que ele dá para o próprio conservadorismo (p.99). [^2]: p. 101 [^3]: p. 102

@ 3bf0c63f:aefa459d

 A command line utility to create and manage personal graphs, then write them to dot and make images with graphviz. It manages a bunch of YAML files, one for each entity in the graph. Each file lists the incoming and outgoing links it has (could have listen only the outgoing, now that I'm tihnking about it). Each run of the tool lets you select from existing nodes or add new ones to generate a single link type from one to one, one to many, many to one or many to many -- then updates the YAML files accordingly. It also includes a command that generates graphs with graphviz, and it can accept a template file that lets you customize the `dot` that is generated and thus the graphviz graph. # rel - <https://github.com/fiatjaf/rel>

@ 3bf0c63f:aefa459d

# GraphQL vs REST Today I saw this: https://github.com/stickfigure/blog/wiki/How-to-(and-how-not-to)-design-REST-APIs And it reminded me why GraphQL is so much better. It has also reminded me why HTTP is so confusing and awful as a protocol, especially as a protocol for structured data APIs, with all its status codes and headers and bodies and querystrings and content-types -- but let's not talk about that for now. People complain about GraphQL being great for frontend developers and bad for backend developers, but I don't know who are these people that apparently love reading guides like the one above of how to properly construct ad-hoc path routers, decide how to properly build the JSON, what to include and in which circumstance, what status codes and headers to use, all without having any idea of what the frontend or the API consumer will want to do with their data. It is a much less stressful environment that one in which we can just actually perform the task and fit the data in a preexistent schema with types and a structure that we don't have to decide again and again while anticipating with very incomplete knowledge the usage of an extraneous person -- i.e., an environment with GraphQL, or something like GraphQL. By the way, I know there are some people that say that these HTTP JSON APIs are not the real REST, but that is irrelevant for now.

@ 3bf0c63f:aefa459d

# nostr - Notes and Other Stuff Transmitted by Relays The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all. It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and signatures, so it is tamperproof; it does not rely on P2P techniques, therefore it works. ## Very short summary of how it works, if you don't plan to read anything else: Everybody runs a client. It can be a native client, a web client, etc. To publish something, you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself). To get updates from other people, you ask multiple relays if they know anything about these other people. Anyone can run a relay. A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted. Signatures are verified on the client side. ## This is needed because other solutions are broken: ### The problem with Twitter - Twitter has ads; - Twitter uses bizarre techniques to keep you addicted; - Twitter doesn't show an actual historical feed from people you follow; - Twitter bans people; - Twitter shadowbans people. - Twitter has a lot of spam. ### The problem with Mastodon and similar programs - User identities are attached to domain names controlled by third-parties; - Server owners can ban you, just like Twitter; Server owners can also block other servers; - Migration between servers is an afterthought and can only be accomplished if servers cooperate. It doesn't work in an adversarial environment (all followers are lost); - There are no clear incentives to run servers, therefore they tend to be run by enthusiasts and people who want to have their name attached to a cool domain. Then, users are subject to the despotism of a single person, which is often worse than that of a big company like Twitter, and they can't migrate out; - Since servers tend to be run amateurishly, they are often abandoned after a while — which is effectively the same as banning everybody; - It doesn't make sense to have a ton of servers if updates from every server will have to be painfully pushed (and saved!) to a ton of other servers. This point is exacerbated by the fact that servers tend to exist in huge numbers, therefore more data has to be passed to more places more often; - For the specific example of video sharing, ActivityPub enthusiasts realized it would be completely impossible to transmit video from server to server the way text notes are, so they decided to keep the video hosted only from the single instance where it was posted to, which is similar to the Nostr approach. ### The problem with SSB (Secure Scuttlebutt) - It doesn't have many problems. I think it's great. In fact, I was going to use it as a basis for this, but - its protocol is too complicated because it wasn't thought about being an open protocol at all. It was just written in JavaScript in probably a quick way to solve a specific problem and grew from that, therefore it has weird and unnecessary quirks like signing a JSON string which must strictly follow the rules of [_ECMA-262 6th Edition_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify); - It insists on having a chain of updates from a single user, which feels unnecessary to me and something that adds bloat and rigidity to the thing — each server/user needs to store all the chain of posts to be sure the new one is valid. Why? (Maybe they have a good reason); - It is not as simple as Nostr, as it was primarily made for P2P syncing, with "pubs" being an afterthought; - Still, it may be worth considering using SSB instead of this custom protocol and just adapting it to the client-relay server model, because reusing a standard is always better than trying to get people in a new one. ### The problem with other solutions that require everybody to run their own server - They require everybody to run their own server; - Sometimes people can still be censored in these because domain names can be censored. ## How does Nostr work? - There are two components: __clients__ and __relays__. Each user runs a client. Anyone can run a relay. - Every user is identified by a public key. Every post is signed. Every client validates these signatures. - Clients fetch data from relays of their choice and publish data to other relays of their choice. A relay doesn't talk to another relay, only directly to users. - For example, to "follow" someone a user just instructs their client to query the relays it knows for posts from that public key. - On startup, a client queries data from all relays it knows for all users it follows (for example, all updates from the last day), then displays that data to the user chronologically. - A "post" can contain any kind of structured data, but the most used ones are going to find their way into the standard so all clients and relays can handle them seamlessly. ## How does it solve the problems the networks above can't? - **Users getting banned and servers being closed** - A relay can block a user from publishing anything there, but that has no effect on them as they can still publish to other relays. Since users are identified by a public key, they don't lose their identities and their follower base when they get banned. - Instead of requiring users to manually type new relay addresses (although this should also be supported), whenever someone you're following posts a server recommendation, the client should automatically add that to the list of relays it will query. - If someone is using a relay to publish their data but wants to migrate to another one, they can publish a server recommendation to that previous relay and go; - If someone gets banned from many relays such that they can't get their server recommendations broadcasted, they may still let some close friends know through other means with which relay they are publishing now. Then, these close friends can publish server recommendations to that new server, and slowly, the old follower base of the banned user will begin finding their posts again from the new relay. - All of the above is valid too for when a relay ceases its operations. - **Censorship-resistance** - Each user can publish their updates to any number of relays. - A relay can charge a fee (the negotiation of that fee is outside of the protocol for now) from users to publish there, which ensures censorship-resistance (there will always be some Russian server willing to take your money in exchange for serving your posts). - **Spam** - If spam is a concern for a relay, it can require payment for publication or some other form of authentication, such as an email address or phone, and associate these internally with a pubkey that then gets to publish to that relay — or other anti-spam techniques, like hashcash or captchas. If a relay is being used as a spam vector, it can easily be unlisted by clients, which can continue to fetch updates from other relays. - **Data storage** - For the network to stay healthy, there is no need for hundreds of active relays. In fact, it can work just fine with just a handful, given the fact that new relays can be created and spread through the network easily in case the existing relays start misbehaving. Therefore, the amount of data storage required, in general, is relatively less than Mastodon or similar software. - Or considering a different outcome: one in which there exist hundreds of niche relays run by amateurs, each relaying updates from a small group of users. The architecture scales just as well: data is sent from users to a single server, and from that server directly to the users who will consume that. It doesn't have to be stored by anyone else. In this situation, it is not a big burden for any single server to process updates from others, and having amateur servers is not a problem. - **Video and other heavy content** - It's easy for a relay to reject large content, or to charge for accepting and hosting large content. When information and incentives are clear, it's easy for the market forces to solve the problem. - **Techniques to trick the user** - Each client can decide how to best show posts to users, so there is always the option of just consuming what you want in the manner you want — from using an AI to decide the order of the updates you'll see to just reading them in chronological order. ## FAQ - **This is very simple. Why hasn't anyone done it before?** I don't know, but I imagine it has to do with the fact that people making social networks are either companies wanting to make money or P2P activists who want to make a thing completely without servers. They both fail to see the specific mix of both worlds that Nostr uses. - **How do I find people to follow?** First, you must know them and get their public key somehow, either by asking or by seeing it referenced somewhere. Once you're inside a Nostr social network you'll be able to see them interacting with other people and then you can also start following and interacting with these others. - **How do I find relays? What happens if I'm not connected to the same relays someone else is?** You won't be able to communicate with that person. But there are hints on events that can be used so that your client software (or you, manually) knows how to connect to the other person's relay and interact with them. There are other ideas on how to solve this too in the future but we can't ever promise perfect reachability, no protocol can. - **Can I know how many people are following me?** No, but you can get some estimates if relays cooperate in an extra-protocol way. - **What incentive is there for people to run relays?** The question is misleading. It assumes that relays are free dumb pipes that exist such that people can move data around through them. In this case yes, the incentives would not exist. This in fact could be said of DHT nodes in all other p2p network stacks: what incentive is there for people to run DHT nodes? - **Nostr enables you to move between server relays or use multiple relays but if these relays are just on AWS or Azure what’s the difference?** There are literally thousands of VPS providers scattered all around the globe today, there is not only AWS or Azure. AWS or Azure are exactly the providers used by single centralized service providers that need a lot of scale, and even then not just these two. For smaller relay servers any VPS will do the job very well.

@ 3bf0c63f:aefa459d

# Parallel Chains We want merged-mined blockchains. We want them because it is possible to do things in them that aren't doable in the normal Bitcoin blockchain because it is rightfully too expensive, but there are other things beside the world money that could benefit from a "distributed ledger" -- just like people believed in 2013 --, like issued assets and domain names (just the most obvious examples). On the other hand we can't have -- like people believed in 2013 -- a copy of Bitcoin for every little idea with its own native token that is mined by proof-of-work and must get off the ground from being completely valueless into having some value by way of a miracle that operated only once with Bitcoin. It's also not a good idea to have blockchains with custom merged-mining protocol (like Namecoin and Rootstock) that require Bitcoin miners to run their software and be an active participant and miner for that other network besides Bitcoin, because it's too cumbersome for everybody. Luckily [Ruben Somsen invented this protocol for blind merged-mining](https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5) that solves the issue above. Although it doesn't solve the fact that each parallel chain still needs some form of "native" token to pay miners -- or it must use another method that doesn't use a native token, such as trusted payments outside the chain. ## How does it work With the `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT` soft-fork[^eltoo] it becomes possible to create presigned transactions that aren't related to any previous UTXO. Then you create a long sequence of transactions (sufficient to last for many many years), each with an `nLockTime` of 1 and each spending the next (you create them from the last to the first). Since their `scriptSig` (the unlocking script) will use `SIGHASH_ANYPREVOUT` you can obtain a transaction id/hash that doesn't include the previous TXO, you can, for example, in a sequence of transactions `A0-->B` (B spends output 0 from A), include the signature for "spending A0 on B" inside the `scriptPubKey` (the locking script) of "A0". With the contraption described above it is possible to make that long string of transactions everybody will know (and know how to generate) but each transaction can only be spent by the next previously decided transaction, no matter what anyone does, and there always must be at least one block of difference between them. Then you combine it with `RBF`, `SIGHASH_SINGLE` and `SIGHASH_ANYONECANPAY` so parallel chain miners can add inputs and outputs to be able to compete on fees by including their own outputs and getting change back while at the same time writing a hash of the parallel block in the change output and you get everything working perfectly: everybody trying to spend the same output from the long string, each with a different parallel block hash, only the highest bidder will get the transaction included on the Bitcoin chain and thus only one parallel block will be mined. ## See also - [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) [^eltoo]: The same thing used in [Eltoo](nostr:naddr1qqyxvenyvejnwdejqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c6qlqxc).

@ 3bf0c63f:aefa459d

# A estrutura lógica do livro didático Todos os livros didáticos e cursos expõem seus conteúdos a partir de uma organização lógica prévia, um esquema de todo o conteúdo que julgam relevante, tudo muito organizadinho em tópicos e subtópicos segundo a ordem lógica que mais se aproxima da ordem natural das coisas. Imagine um sumário de um manual ou livro didático. A minha experiência é a de que esse método serve muito bem para ninguém entender nada. A organização lógica perfeita de um campo de conhecimento é o resultado **final** de um estudo, não o seu início. As pessoas que escrevem esses manuais e dão esses cursos, mesmo quando sabem do que estão falando (um acontecimento aparentemente raro), o fazem a partir do seu próprio ponto de vista, atingido após uma vida de dedicação ao assunto (ou então copiando outros manuais e livros didáticos, o que eu chutaria que é o método mais comum). Para o neófito, a melhor maneira de entender algo é através de imersões em micro-tópicos, sem muita noção da posição daquele tópico na hierarquia geral da ciência. * [Revista Educativa](nostr:naddr1qqyxgvfcxajkxe3cqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cfx0trx), um exemplo de como não ensinar nada às crianças. * [Zettelkasten](nostr:naddr1qqyrwwfh8yurgefnqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7qmjrw), a ordem surgindo do caos, ao invés de temas se encaixando numa ordem preexistentes.

@ 3bf0c63f:aefa459d

# Boardthreads This was a very badly done service for turning a Trello list into a helpdesk UI. Surprisingly, it had more paying users than [Websites For Trello](nostr:naddr1qqyrydpkvverwvehqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9d4yku), which I was working on simultaneously and dedicating much more time to it. The Neo4j database I used for this was a very poor choice, it was probably the cause of all the bugs.  -<https://github.com/fiatjaf/boardthreads>

@ 3bf0c63f:aefa459d

# Channels without HTLCs HTLCs below the dust limit are not possible, because they're uneconomical. So currently whenever a payment below the dust limit is to be made Lightning peers adjust their commitment transactions to pay that amount as fees in case the channel is closed. That's a form of reserving that amount and incentivizing peers to resolve the payment, either successfully (in case it goes to the receiving node's balance) or not (it then goes back to the sender's balance). SOLUTION I didn't think too much about if it is possible to do what I think can be done in the current implementation on Lightning channels, but in the context of Eltoo it seems possible. Eltoo channels have UPDATE transactions that can be published to the blockchain and SETTLEMENT transactions that spend them (after a relative time) to each peer. The barebones script for UPDATE transactions is something like (copied from the paper, because I don't understand these things): ``` OP_IF # to spend from a settlement transaction (presigned) 10 OP_CSV 2 As,i Bs,i 2 OP_CHECKMULTISIGVERIFY OP_ELSE # to spend from a future update transaction <Si+1> OP_CHECKLOCKTIMEVERIFY 2 Au Bu 2 OP_CHECKMULTISIGVERIFY OP_ENDIF ``` During a payment of 1 satoshi it could be updated to something like (I'll probably get this thing completely wrong): ``` OP_HASH256 <payment_hash> OP_EQUAL OP_IF # for B to spend from settlement transaction 1 in case the payment went through # and they have a preimage 10 OP_CSV 2 As,i1 Bs,i1 2 OP_CHECKMULTISIGVERIFY OP_ELSE OP_IF # for A to spend from settlement transaction 2 in case the payment didn't went through # and the other peer is uncooperative <now + 1day> OP_CHECKLOCKTIMEVERIFY 2 As,i2 Bs,i2 2 OP_CHECKMULTISIGVERIFY OP_ELSE # to spend from a future update transaction <Si+1> OP_CHECKLOCKTIMEVERIFY 2 Au Bu 2 OP_CHECKMULTISIGVERIFY OP_ENDIF OP_ENDIF ``` Then peers would have two presigned SETTLEMENT transactions, 1 and 2 (with different signature pairs, as badly shown in the script). On SETTLEMENT 1, funds are, say, 999sat for A and 1001sat for B, while on SETTLEMENT 2 funds are 1000sat for A and 1000sat for B. As soon as B gets the preimage from the next peer in the route it can give it to A and them can sign a new UPDATE transaction that replaces the above gimmick with something simpler without hashes involved. If the preimage doesn't come in viable time, peers can agree to make a new UPDATE transaction anyway. Otherwise A will have to close the channel, which may be bad, but B wasn't a good peer anyway.

@ 3bf0c63f:aefa459d

# Criteria for activating Drivechain on Bitcoin [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) is, in essence, just a way to give Bitcoin users the option to deposit their coins in a hashrate escrow. If Bitcoin is about coin ownership, in theory there should be no objection from anyone on users having the option to do that: my keys, my coins etc. In other words: even if you think hashrate escrows are a terrible idea and miners will steal all coins from that, you shouldn't care about what other people do with their own money. There are only two reasonable objections that could be raised by normal Bitcoin users against Drivechain: 1. Drivechain adds code complexity to `bitcoind` 2. Drivechain perverts miner incentives of the Bitcoin chain If these two objections can be reasonably answered there remains no reason for not activating the Drivechain soft-fork. ## 1 To address **1** we can just take a look at the code once it's done (which I haven't) but from my understanding the extra validation steps needed for ensuring hashrate escrows work are very minimal and self-contained, they shouldn't affect anything else and the risks of introducing some catastrophic bug are roughly zero (or the same as the risks of any of the dozens of refactors that happen every week on Bitcoin Core). For the BMM/BIP-301 part, again the surface is very small, but we arguably do not need that at all, since [anyprevout](https://anyprevout.xyz/) (once that is merged) enables blind merge-mining in way that is probably better than BIP-301, and that soft-fork is also very simple, plus already loved and accepted by most of the Bitcoin community, implemented and reviewed on Bitcoin Inquisition and is live on the official Bitcoin Core signet. ## 2 To address **2** we must only point that BMM ensures that Bitcoin miners don't have to do any extra work to earn basically all the fees that would come from the sidechain, as competition for mining sidechain blocks would bid the fee paid to Bitcoin miners up to the maximum economical amount. It is irrelevant if there is MEV on the sidechain or not, everything that reaches the Bitcoin chain does that in form of fees paid in a single high-fee transaction paid to any Bitcoin miner, regardless of them knowing about the sidechain or not. Therefore, there are no centralization pressure or pervert mining incentives that can affect Bitcoin land. Sometimes it's argued that Drivechain may facilitate the ocurrence of a transaction paying a fee so high it would create incentives for reorging the Bitcoin chain. There is no reason to believe Drivechain would make this more likely than an actual attack than anyone can already do today or, as has happened, some rich person typing numbers wrong on his wallet. In fact, if a drivechain is consistently paying high fees on its BMM transactions that is an incentive for Bitcoin miners to keep mining those transactions one after the other and not harm the users of sidechain by reorging Bitcoin. Moreover, there are many factors that exist today that can be seen as centralization vectors for Bitcoin mining: arguably one of them is non-blind merge mining, of which we have [a (very convoluted) example on the Stacks shitcoin](https://twitter.com/fiatjaf/status/1684171939298803712), and introducing the possibility of blind merge-mining on Bitcoin would basically remove any reasonable argument for having such schemes, therefore reducing the centralizing factor of them.

@ 3bf0c63f:aefa459d

# Um algoritmo imbecil da evolução Suponha que você queira escrever a palavra BANANA partindo de OOOOOO e usando só alterações aleatórias das letras. As alterações se dão por meio da multiplicação da palavra original em várias outras, cada uma com uma mudança diferente. No primeiro período, surgem BOOOOO e OOOOZO. E então o ambiente decide que todas as palavras que não começam com um B estão eliminadas. Sobra apenas BOOOOO e o algoritmo continua. É fácil explicar conceber a evolução das espécies acontecendo dessa maneira, se você controlar sempre a parte em que o ambiente decide quem vai sobrar. Porém, há apenas duas opções: 1. Se o ambiente decidir as coisas de maneira aleatória, a chance de você chegar na palavra correta usando esse método é tão pequena que pode ser considerada nula. 2. Se o ambiente decidir as coisas de maneira pensada, caímos no //design inteligente//. Acredito que isso seja uma enunciação decente do argumento ["no free lunch"](https://en.wikipedia.org/wiki/No_free_lunch_in_search_and_optimization) aplicado à crítica do darwinismo por William Dembski. A resposta darwinista consiste em dizer que não existe essa BANANA como objetivo final. Que as palavras podem ir se alterando aleatoriamente, e o que sobrar sobrou, não podemos dizer que um objetivo foi atingido ou deixou de sê-lo. E aí os defensores do design inteligente dirão que o resultado ao qual chegamos não pode ter sido fruto de um processo aleatório. BANANA é qualitativamente diferente de AYZOSO, e aí há várias maneiras de "provar" que sim usando modelos matemáticos e tal. Fico com a impressão, porém, de que essa coisa só pode ser resolvida como sim ou não mediante uma discussão das premissas, e chega um ponto em que não há mais provas matemáticas possíveis, apenas subjetividade. Daí eu me lembro da minha humilde solução ao problema do cão que aperta as teclas aleatoriamente de um teclado e escreve as obras completas de Shakespeare: mesmo que ele o faça, nada daquilo terá sentido sem uma inteligência de tipo humano ali para lê-las e perceber que não se trata de uma bagunça, mas sim de um texto com sentido para ele. O milagre se dá não no momento em que o cão tropeça no teclado, mas no momento em que o homem olha para a tela. Se o algoritmo da evolução chegou à palavra BANANA ou UXJHTR não faz diferença pra ela, mas faz diferença para nós, que temos uma inteligência humana, e estamos observando aquilo. O homem também pensaria que há //algo// por trás daquele evento do cão que digita as obras de Shakespeare, e como seria possível alguém em sã consciência pensar que não?

@ 3bf0c63f:aefa459d

# Gerador de tabelas de todos contra todos I don't remember exactly when I did this, but I think a friend wanted to do software that would give him money over the internet without having to work. He didn't know how to program. He mentioned this idea he had which was some kind of football championship manager solution, but I heard it like this: a website that generated a round-robin championship table for people to print. It is actually not obvious to anyone how to do it, it requires an algorithm that people will not reach casually while thinking, and there was no website doing it in Portuguese at the time, so I made this and it worked and it had a couple hundred daily visitors, and it even generated money from Google Ads (not much)! First it was a Python web app running on Heroku, then Heroku started charging or limiting the amount of free time I could have on their platform, so I migrated it to a static site that ran everything on the client. Since I didn't want to waste my Python code that actually generated the tables I used [Brython](https://brython.info/) to run Python on JavaScript, which was an interesting experience. In hindsight I could have just taken one of the many `round-robin` JavaScript libraries that exist on NPM, so eventually after a couple of more years I did that. I also removed Google Ads when Google decided it had so many requirements to send me the money it was impossible, and then the money started to vanished. - <https://github.com/fiatjaf/tabelas.alhur.es> - <https://tabelas.alhur.es/>

@ 3bf0c63f:aefa459d

# Money Supply Measurement What if we measured money supply measured by probability of being spent -- or how near it is to the point in which it is spent? bonds could be money if they're treated as that by their owners, but they are likely to be not near the spendpoint as cash, other assets can also be considered money but they might be even farther.

@ 3bf0c63f:aefa459d

# How being "flexible" can bloat a protocol (A somewhat absurd example, but you'll get the idea) Iimagine some client decides to add support for a variant of nip05 that checks for values at /.well-known/nostr.yaml besides /.well-known/nostr.json. "Why not?", they think, "I like YAML more than JSON, this can't hurt anyone". Then some user makes a nip05 file in YAML and it will work on that client, they will think their file is good since it works on that client. When the user sees that other clients are not recognizing their YAML file, they will complain to the other client developers: "Hey, your client is broken, it is not supporting my YAML file!". The developer of the other client, astonished, replies: "Oh, I am sorry, I didn't know that was part of the nip05 spec!" The user, thinking it is doing a good thing, replies: "I don't know, but it works on this other client here, see?" Now the other client adds support. The cycle repeats now with more users making YAML files, more and more clients adding YAML support, for fear of providing a client that is incomplete or provides bad user experience. The end result of this is that now nip05 extra-officially requires support for both JSON and YAML files. Every client must now check for /.well-known/nostr.yaml too besides just /.well-known/nostr.json, because a user's key could be in either of these. A lot of work was wasted for nothing. And now, going forward, any new clients will require the double of work than before to implement.

@ 3bf0c63f:aefa459d

# Token-Curated Registries ## So you want to build a TCR? TCRs (Token Curated Registries) are a construct for maintaining registries on Ethereum. Imagine you have lots of scissor brands and you want a list with only the good scissors. You want to make sure only the good scissors make into that list and not the bad scissors. For that, people will tell you, you can just create a TCR of the best scissors! It works like this: some people have the token, let's call it Scissor Token. Some other person, let's say it's a scissor manufacturer, wants to put his scissor on the list, this guy must acquire some Scissor Tokens and "stake" it. Holders of the Scissor Tokens are allowed to vote on "yes" or "no". If "no", the manufactures loses his tokens to the holders, if "yes" then its tokens are kept in deposit, but his scissor brand gets accepted into the registry. Such a simple process, they say, have strong incentives for being the best possible way of curating a registry of scissors: consumers have the incentive to consult the list because of its high quality; manufacturers have the incentive to buy tokens and apply to join the list because the list is so well-curated and consumers always consult it; token holders want the registry to accept good and reject bad scissors because that good decisions will make the list good for consumers and thus their tokens more valuable, bad decisions will do the contrary. It doesn't make sense, to reject everybody just to grab their tokens, because that would create an incentive against people trying to enter the list. Amazing! How come such a simple system of voting has such enourmous features? Now we can have lists of everything so well-curated, and for that we just need Ethereum tokens! Now let's imagine a different proposal, of my own creation: SPCR, Single-person curated registries. Single-person Curated Registries are equal to TCR, except they don't use Ethereum tokens, it's just a list in a text file kept by a single person. People can apply to join, and they will have to give the single person some amount of money, the single person can reject or accept the proposal and so on. Now let's look at the incentives of SPCR: people will want to consult the registry because it is so well curated; vendors will want to enter the registry because people are consulting it; the single person will want to accept the good and reject the bad applicants because these good decisions are what will make the list valuable. Amazing! How such a single proposal has such enourmous features! SPCR are going to take over the internet! ## What TCR enthusiasts get wrong? TCR people think they can just list a set of incentives for something to work and assume that something will work. Mix that with Ethereum hype and they think theyve found something unique and revolutionary, while in fact they're just making a poor implementation of "democracy" systems that fail almost everywhere. The life is not about listing a set of "incentives" and then considering the problems solved. Almost everybody on the Earth has the incentive for being rich: being rich has a lot of advantages over being poor, however not all people get rich! Why are the incentives failing? Curating lists is a hard problem, it involves a lot of knowledge about the problem that just holding a token won't give you, it involves personal preferences, politics, it involves knowing where is the real limit between "good" and "bad". The Single Person list may have a good result if the single person doing the curation is knowledgeable and honest (yes, you can game the system to accept your uncle's scissors and not their competitor that is much better, for example, without losing the entire list reputation), same thing for TCRs, but it can also fail miserably, and it can appear to be good but be in fact not so good. In all cases, the list entries will reflect the preferences of people choosing and other things that aren't taken into the incentives equation of TCR enthusiasts. ## We don't need lists The most important point to be made, although unrelated to the incentive story, is that we don't need lists. Imagine you're looking for a scissor. You don't want someone to tell if scissor A or B are "good" or "bad", or if A is "better" than B. You want to know if, for your specific situation, or for a class of situations, A will serve well, and do that considering A's price and if A is being sold near you and all that. Scissors are the worst example ever to make this point, but I hope you get it. If you don't, try imagining the same example with schools, doctors, plumbers, food, whatever. Recommendation systems are badly needed in our world, and TCRs don't solve these at all.

@ 3bf0c63f:aefa459d

# WelcomeBot The first bot ever created for Trello. It invited to a public board automatically anyone who commented on a card he was added to. - <https://github.com/fiatjaf/welcomebot> - <https://trello.com/welcomebot>

@ 3bf0c63f:aefa459d

# Sol e Terra A Terra não gira em torno do Sol. Tudo depende do ponto de referência e não existe um ponto de referência absoluto. Só é melhor dizer que a Terra gira em torno do Sol porque há outros planetas fazendo movimentos análogos e aí fica mais fácil para todo mundo entender os movimentos tomando o Sol como ponto de referência.

@ 3bf0c63f:aefa459d

# A list of things artificial intelligence is not doing If AI is so good why can't it: - write good glue code that wraps a documented HTTP API? - make good translations using available books and respective published translations? - extract meaningful and relevant numbers from news articles? - write mathematical models that fit perfectly to available data better than any human? - play videogames without cheating (i.e. simulating human vision, attention and click speed)? - turn pure HTML pages into pretty designs by generating CSS - predict the weather - calculate building foundations - determine stock values of companies from publicly available numbers - smartly and automatically test software to uncover bugs before releases - predict sports matches from the ball and the players' movement on the screen - continuously improve niche/local search indexes based on user input and and reaction to results - control traffic lights - predict sports matches from news articles, and teams and players' history This was posted first on [Twitter](https://twitter.com/fiatjaf/status/1477942802805837827).

@ 3bf0c63f:aefa459d

# Rede Relâmpago Ao se referir à _Lightning Network_ do [O que é Bitcoin?](nostr:naddr1qqrky6t5vdhkjmspz9mhxue69uhkv6tpw34xze3wvdhk6q3q80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsxpqqqp65wp3k3fu), nós, brasileiros e portugueses, devemos usar o termo "Relâmpago" ou "Rede Relâmpago". "Relâmpago" é uma palavra bonita e apropriada, e fácil de pronunciar por todos os nossos compatriotas. Chega de anglicismos desnecessários. Exemplo de uma conversa hipotética no Brasil usando esta nomenclatura: – Posso pagar com Relâmpago? – Opa, claro! Vou gerar um boleto aqui pra você. Repare que é bem mais natural e fácil do que a outra alternativa: – Posso pagar com láitenim? – Leite ninho?

@ 3bf0c63f:aefa459d

# idea: Custom multi-use database app Since 2015 I have this idea of making one app that could be repurposed into a full-fledged app for all kinds of uses, like powering small businesses accounts and so on. Hackable and open as an Excel file, but more efficient, without the hassle of making tables and also using ids and indexes under the hood so different kinds of things can be related together in various ways. It is not a concrete thing, just a generic idea that has taken multiple forms along the years and may take others in the future. I've made quite a few attempts at implementing it, but never finished any. I used to refer to it as a "multidimensional spreadsheet". Can also be related to [DabbleDB][dabble-db]. [dabble-db]: <https://en.wikipedia.org/wiki/Dabble_DB>

@ 3bf0c63f:aefa459d

# Reclamações - [Como não houve resposta, estou enviando de novo](nostr:naddr1qqyx2wfhvy6r2vejqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ct53y8g) - [Democracia na América](nostr:naddr1qqyrzc3ev3jn2vrpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8ynvrd) - [A "política" é a arena da vitória do estatismo](nostr:naddr1qqyx2wpnxdsnyvmpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccp2rh9) - [A biblioteca infinita](nostr:naddr1qqyryd3hv5crywp5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ce8r2jh) - [Família e propriedade](nostr:naddr1qqyrwwpnxesnqvmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c4s2ruz) - [Memórias de quando eu aprendi a ler](nostr:naddr1qqyrjve4vgunwctyqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cfdtahp) - [A chatura Kelsen](nostr:naddr1qqyr2df58qekxce3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0n53d9) - [O VAR é o grande equalizador](nostr:naddr1qqyxxwf5vesnywrpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c7j5n5x) - [Não tem solução](nostr:naddr1qqyrswtxxdnxgdtrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823csj44kn) - [A estrutura lógica do livro didático](nostr:naddr1qqyrxv3j8qenxe3eqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ctyr464) - ["House" dos economistas e o Estado](nostr:naddr1qqyxxdfnv5cxyef4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cdlmhy7) - [Revista Educativa](nostr:naddr1qqyxgvfcxajkxe3cqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cfx0trx) - [Cultura Inglesa e aprendizado extra-escolar](nostr:naddr1qqyr2errxcursvmzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8yqzwv) - [Veterano não é dono de bixete](nostr:naddr1qqyxvdm9v5ex2dmyqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823crahz92) - [Personagens de jogos e símbolos](nostr:naddr1qqyr2ctpv5crxdnpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c60jj0x) - [Músicas grudentas e conversas](nostr:naddr1qqyr2etyvcunxve5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cu35467) - [Obra aqui do lado](nostr:naddr1qqyxgd33vs6kzvf5qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8vsd0u) - [Propaganda](nostr:naddr1qqyxgvtrxpjxgdtxqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cyzfj30) - [Ver Jesus com os olhos da carne](nostr:naddr1qqyrjdek8q6ngcfhqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0zzevd) - [Processos Antifrágeis](nostr:naddr1qqyryv3hxfsnvvm9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c5jshx7) - [Cadeias, crimes e cidadãos de bem](nostr:naddr1qqyrydt9xsuxxwryqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cgq9tqq) - [Castas hindus em nova chave](nostr:naddr1qqyrzcnyxyexxetpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cqsz60h) - [Método científico](nostr:naddr1qqyr2wf3vgmx2dmrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chtnaca) - [Xampu](nostr:naddr1qqyx2wphvccngwfeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c5lczq3) - [Thafne venceu o Soletrando 2008.](nostr:naddr1qqyrgef5vdskvvr9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cwxwyt5) - [Empreendendorismo de boteco](nostr:naddr1qqyrgc33v56kzdesqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cx5t67v) - [Problemas com Russell Kirk](nostr:naddr1qqyxzct9v33rjvp4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cu9j032) - [Pequenos problemas que o Estado cria para a sociedade e que não são sempre lembrados](nostr:naddr1qqyrzdpexajkzenzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ck07uru)

@ 3bf0c63f:aefa459d

# The Lightning Network solves the problem of the decentralized commit Before reading this, see [Ripple and the problem of the decentralized commit](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6). The Bitcoin Lightning Network can be thought as a system similar to Ripple: there are conditional IOUs (HTLCs) that are sent in "prepare"-like messages across a route, and a secret `p` that must travel from the final receiver backwards through the route until it reaches the initial sender and possession of that secret serves to prove the payment as well as to make the IOU hold true. The difference is that if one of the parties don't send the "acknowledge" in time, the other has a trusted third-party with its own clock (that is the clock that is valid for everybody involved) to complain immediately at the timeout: the Bitcoin blockchain. If C has `p` and B isn't acknowleding it, C tells the Bitcoin blockchain and it will force the transfer of the amount from B to C. ## Differences (or 1 upside and 3 downside) 1. The Lightning Network differs from a "pure" Ripple network in that when we send a "prepare" message on the Lightning Network, unlike on a pure Ripple network we're not just promising we will owe something -- instead we are putting the money on the table already for the other to get if we are not responsive. 2. The feature above removes the trust element from the equation. We can now have relationships with people we don't trust, as the Bitcoin blockchain will serve as an automated escrow for our conditional payments and no one will be harmed. Therefore it is much easier to build networks and route payments if you don't always require trust relationships. 3. However it introduces the cost of the capital. A ton of capital must be made available in channels and locked in HTLCs so payments can be routed. This leads to potential issues like the ones described in <https://twitter.com/joostjgr/status/1308414364911841281>. 4. Another issue that comes with the necessity of using the Bitcoin blockchain as an arbiter is that it may cost a lot in fees -- much more than the value of the payment that is being disputed -- to enforce it on the blockchain.[^closing-channels-for-nothing] ## Solutions Because the downsides listed above are so real and problematic -- and much more so when attacks from malicious peers are taken into account --, some have argued that the Lightning Network must rely on at least some trust between peers, which partly negate the benefit. The introduction of [purely trust-backend channels](https://gist.github.com/btcontract/d4122a79911eef2620f16b3dfe2850a8) is the next step in the reasoning: if we are trusting already, why not make channels that don't touch the blockchain and don't require peers to commit large amounts of capital? The reason is, again, the ambiguity that comes from [the problem of the decentralized commit](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6). Therefore [hosted channels](https://gist.github.com/btcontract/d4122a79911eef2620f16b3dfe2850a8) can be good when trust is required only from one side, like in the final hops of payments, but they cannot work in the middle of routes without eroding trust relationships between peers (however they can be useful if employed as channels between two nodes ran by the same person). The next solution is [a revamped pure Ripple network](nostr:naddr1qqr8yatdwpkx2qg3waehxw309anxjct5dfskvtnrdaksygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqw4rsfyk3p9), one that solves the problem of the decentralized commit in a different way. [^closing-channels-for-nothing]: That is even true when, for reasons of the payment being so small that it doesn't even deserve an actual HTLC that can be enforced on the chain (as per the protocol), even then the channel between the two nodes will be closed, only to make it very clear that there was a disagreement. Leaving it online would be harmful as one of the peers could repeat the attack again and again. This is a proof that [ambiguity, in case of the pure Ripple network](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6), is a very important issue.

@ 3bf0c63f:aefa459d

# Reasons for miners to not steal See [Drivechain](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp) for an introduction. Here we'll just have a list of reasons why miners would not steal: - they will lose future fees from that specific drivechain: you can discount all future fees and condense them into a single present number in order to do some mathematical calculation. - they may lose future fees from all other Drivechains, if the users assume they will steal from those too. - Bitcoin will be devalued if they steal, because: - Bitcoin is worth more if it has Drivechains working, because it is more useful, has more use-cases, more users. Without Drivechains it necessarily has to be worth less. - Bitcoin has more fee revenue if has Drivechains working, which means it has a bigger chance of surviving going forward and being more censorship-resistant and resistant to State attacks, therefore it has to worth more if Drivechains work and less if they don't. - Bitcoin is worth more if the public perception is that Bitcoin miners are friendly and doing their work peacefully instead of being a band of revolted peons that are constantly threating to use their 75% hashrate to do evil things such as: - double-spending attacks; - censoring of transactions for a certain group of people; - selfish mining. - if Bitcoin is devalued its price is bound to fall, meaning that miners will lose on - their future mining rewards; - their ASIC investiment; - the same coins they are trying to steal from the drivechain. - if a mining pool tries to steal, they will risk losing their individual miners to other pools that don't. - whenever a steal attempt begins, the coins in the drivechain will lose value (if the steal attempt is credible their price will drop quite substantially), which means that if a coalition of miners really try to steal, there is an incentive for another coalition of miners to buy some devalued coins and then stop the steal.

@ 3bf0c63f:aefa459d

# idea: a website for feedback exchange I thought a community of people sharing feedback on mutual interests would be a good thing, so as always I broadened and generalized the idea and mixed with my old criticue-inspired idea-feedback project and turned it into a "token". You give feedback on other people's things, they give you a "point". You can then use that point to request feedback from others. This could be made as an [Etleneum](nostr:naddr1qqyrjcny8qcn2ve4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823crwzz2w) contract so these points were exchanged for satoshis using the shitswap contract (yet to be written). In this case all the Bitcoin/Lightning side of the website must be hidden until the user has properly gone through the usage flow and earned points. If it was to be built on Etleneum then it needs to emphasize the login/password login method instead of the lnurl-auth method. And then maybe it could be used to push lnurl-auth to normal people, but with a different name.

@ 3bf0c63f:aefa459d

bolt12 problems =============== - clients can't programatically build new offers by changing a path or query params (services like zbd.gg or lnurl-pay.me won't work) - impossible to use in a load-balanced custodian way -- since offers would have to be pregenerated and tied to a specific lightning node. - the existence of fiat currency fields makes it so wallets have to fetch exchange rates from somewhere on the internet (or offer a bad user experience), using HTTP which hurts user privacy. - the vendor field is misleading, can be phished very easily, not as safe as a domain name. - onion messages are an improvement over fake HTLC-based payments as a way of transmitting data, for sure. but we must decide if they are (i) suitable for transmitting all kinds of data over the internet, a replacement for tor; or (ii) not something that will scale well or on which we can count on for the future. if there was proper incentivization for data transmission it could end up being (i), the holy grail of p2p communication over the internet, but that is a very hard problem to solve and not guaranteed to yield the desired scalability results. since not even hints of attempting to solve that are being made, it's safer to conclude it is (ii). bolt12 limitations ------------------ - not flexible enough. there are some interesting fields defined in the spec, but who gets to add more fields later if necessary? very unclear. - services can't return any actionable data to the users who paid for something. it's unclear how business can be conducted without an extra communication channel. bolt12 illusions ---------------- - recurring payments is not really solved, it is just a spec that defines intervals. the actual implementation must still be done by each wallet and service. the recurring payment cannot be enforced, the wallet must still initiate the payment. even if the wallet is evil and is willing to initiate a payment without the user knowing it still needs to have funds, channels, be online, connected etc., so it's not as if the services could rely on the payments being delivered in time. - people seem to think it will enable pushing payments to mobile wallets, which it does not and cannot. - there is a confusion of contexts: it looks like offers are superior to lnurl-pay, for example, because they don't require domain names. domain names, though, are common and well-established among internet services and stores, because these services have websites, so this is not really an issue. it is an issue, though, for people that want to receive payments in their homes. for these, indeed, bolt12 offers a superior solution -- but at the same time bolt12 seems to be selling itself as a tool for merchants and service providers when it includes and highlights features as recurring payments and refunds. - the privacy gains for the receiver that are promoted as being part of bolt12 in fact come from a separate proposal, blinded paths, which should work for all normal lightning payments and indeed are a very nice solution. they are (or at least were, and should be) independent from the bolt12 proposal. a separate proposal, which can be (and already is being) used right now, also improves privacy for the receiver very much anway, it's called trampoline routing.

@ 3bf0c63f:aefa459d

# Músicas novas e conhecidas Quando for ouvir música de fundo, escolha músicas bem conhecidas. Para ouvir músicas novas, reserve um tempo e ouça-as com total atenção. Uma coisa similar é dirigir por caminhos conhecidos versus dirigir em lugares novos. a primeira opção te permite fazer coisas enquanto dirige "de fundo", a segunda requer atenção total. Com músicas, tenho errado constantemente em achar que posso conhecer músicas novas ao mesmo tempo em que me dedico a outras tarefas. ## See also: * [Músicas que você já conhece](nostr:naddr1qqyxxvn9xquxgcn9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c839sxv)

@ 3bf0c63f:aefa459d

# A Causa o Princípios de Economia Política de Menger é o único livro que enfatiza a CAUSA o tempo todo. os cientistas todos parecem não saber, ou se esquecer sempre, que as coisas têm causa, e que o conhecimento verdadeiro é o conhecimento da causa das coisas. a causa é uma categoria metafísica muito superior a qualquer correlação ou resultado de teste de hipótese, ela não pode ser descoberta por nenhum artifício econométrico ou reduzida à simples antecedência temporal estatística. a causa dos fenômenos não pode ser provada cientificamente, mas pode ser conhecida. o livro de Menger conta para o leitor as causas de vários fenômenos econômicos e as interliga de forma que o mundo caótico da economia parece adquirir uma ordem no momento em que você lê. é uma sensação mágica e indescritível. quando eu te o recomendei, queria é te imbuir com o espírito da busca pela causa das coisas. depois de ler aquilo, você está apto a perceber continuidade causal nos fenômenos mais complexos da economia atual, enxergar as causas entre toda a ação governamental e as suas várias consequências na vida humana. eu faço isso todos os dias e é a melhor sensação do mundo quando o caos das notícias do caderno de Economia do jornal -- que para o próprio jornalista que as escreveu não têm nenhum sentido (tanto é que ele escreve tudo errado) -- se incluem num sistema ordenado de causas e consequências. provavelmente eu sempre erro em alguns ou vários pontos, mas ainda assim é maravilhoso. ou então é mais maravilhoso ainda quando eu descubro o erro e reinsiro o acerto naquela racionalização bela da ordem do mundo econômico que é a ordem de Deus. _em scrap para T.P._

@ 3bf0c63f:aefa459d

# IPFS problems: Community I was an avid IPFS user until yesterday. Many many times I asked simple questions for which I couldn't find an answer on the internet in the #ipfs IRC channel on Freenode. Most of the times I didn't get an answer, and even when I got it was rarely by someone who knew IPFS deeply. I've had issues go unanswered on js-ipfs repositories for year – one of these was raising awareness of a problem that then got fixed some months later by a complete rewrite, I closed my own issue after realizing that by myself some couple of months later, I don't think the people responsible for the rewrite were ever acknowledge that he had fixed my issue. Some days ago I asked some questions about how the IPFS protocol worked internally, sincerely trying to understand the inefficiencies in finding and fetching content over IPFS. I pointed it would be a good idea to have a drawing showing that so people would understand the difficulties (which I didn't) and wouldn't be pissed off by the slowness. I was told to read the whitepaper. I had already the whitepaper, but read again the relevant parts. The whitepaper doesn't explain anything about the DHT and how IPFS finds content. I said that in the room, was told to read again. Before anyone misread this section, I want to say I understand it's a pain to keep answering people on IRC if you're busy developing stuff of interplanetary importance, and that I'm not paying anyone nor I have the right to be answered. On the other hand, if you're developing a super-important protocol, financed by many millions of dollars and a lot of people are hitting their heads against your software and there's no one to help them; you're always busy but never delivers anything that brings joy to your users, something is very wrong. I sincerely don't know what IPFS developers are working on, I wouldn't doubt they're working on important things if they said that, but what I see – and what many other users see (take a look at the IPFS Discourse forum) is bugs, bugs all over the place, confusing UX, and almost no help.

@ 3bf0c63f:aefa459d

# IPFS problems: Inefficiency Imagine you have two IPFS nodes and unique content, created by you, in the first one. From the second, you can connect to the first and everyhing looks right. You then try to fetch that content. After some seconds it starts coming, the progress bar begins to move, that's slow, very slow, doing an rsync would have been 20 times faster. The progress bar halts. You investigate, the second node is not connected to the first anymore. Why, if that was the only source for the file we're trying to fetch? It remains a mistery to this day. You reconnect manually, the progress bar moves again, halts, you're disconnected again. Instead of reconnecting you decide to add the second node to the first node's "Bootstrap" list. I once tried to run an IPFS node on a VPS and store content on S3. There are two S3 datastore plugins available. After fixing some issues in one of them, recompiling go-ipfs, figuring out how to read settings from the IPFS config file, creating an init profile and recompiling again I got the node running. It worked. My idea was to host a bunch of data on that node. Data would be fetched from S3 on demand so there would be cheap and fast access to it from any IPFS node or gateway. IPFS started doing hundreds of calls to S3 per minute – something I wouldn't have known about if I hadn't inserted some log statements in the plugin code, I mean before the huge AWS bill arrived. Apparently that was part of participation on the DHT. Adjusting some settings turned my node into a listen-only thing as I intended, but I'm not 100% sure it would work as an efficient content provider, and I'll never know, as the memory and CPU usage got too high for my humble VPS and I had to turn it down.

@ 3bf0c63f:aefa459d

# ijq An interactive REPL for `jq` with smart helpers (for example, it automatically assigns each line of input to a variable so you can reference it later, it also always referenced the previous line automatically). - <https://github.com/fiatjaf/ijq> ## See also - [jiq](nostr:naddr1qqyrqvfjv33rxcenqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cd86z7d) - [jq-web](nostr:naddr1qqyrzvrzxqcx2dfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c90hqwz)

@ 3bf0c63f:aefa459d

# Trelew A CLI tool for navigating Trello boards. It used **vorpal** for an "immersive" experience and was pretty good.  - <https://github.com/fiatjaf/trelew>

@ 3bf0c63f:aefa459d

# `OP_CHECKTEMPLATEVERIFY` and the "covenants" drama There are many ideas for "covenants" (I don't think this concept helps in the specific case of examining proposals, but fine). Some people think "we" (it's not obvious who is included in this group) should somehow examine them and come up with the perfect synthesis. It is not clear what form this magic gathering of ideas will take and who (or which ideas) will be allowed to speak, but suppose it happens and there is intense research and conversations and people (ideas) really enjoy themselves in the process. What are we left with at the end? Someone has to actually commit the time and put the effort and come up with a concrete proposal to be implemented on Bitcoin, and whatever the result is it will have trade-offs. Some great features will not make into this proposal, others will make in a worsened form, and some will be contemplated very nicely, there will be some extra costs related to maintenance or code complexity that will have to be taken. Someone, a concreate person, will decide upon these things using their own personal preferences and biases, and many people will not be pleased with their choices. That has already happened. Jeremy Rubin has already conjured all the covenant ideas in a magic gathering that lasted more than 3 years and came up with a synthesis that has the best trade-offs he could find. CTV is the result of that operation. --- The fate of CTV in the popular opinion illustrated by the thoughtless responses it has evoked such as "can we do better?" and "we need more review and research and more consideration of other ideas for covenants" is a preview of what would probably happen if these suggestions were followed again and someone spent the next 3 years again considering ideas, talking to other researchers and came up with a new synthesis. Again, that person would be faced with "can we do better?" responses from people that were not happy enough with the choices. And unless some famous Bitcoin Core or retired Bitcoin Core developers were personally attracted by this synthesis then they would take some time to review and give their blessing to this new synthesis. To summarize the argument of this article, the actual question in the current CTV drama is that there exists hidden criteria for proposals to be accepted by the general community into Bitcoin, and no one has these criteria clear in their minds. It is not as simple not as straightforward as "do research" nor it is as humanly impossible as "get consensus", it has a much bigger social element into it, but I also do not know what is the exact form of these hidden criteria. This is said not to blame anyone -- except the ignorant people who are not aware of the existence of these things and just keep repeating completely false and unhelpful advice for Jeremy Rubin and are not self-conscious enough to ever realize what they're doing.

@ 3bf0c63f:aefa459d

# idea: clarity.fm on Lightning Getting money from clients very easily, dispatching that money to "world class experts" (what a silly way to market things, but I guess it works) very easily are the job for Bitcoin and the Lightning Network. ### EDIT 2020-09-04 My idea was that people would advertise themselves, so you would book an hour with people you know already, but it seems that clarify.fm has gone through the route of offering a "catalog of experts" to potential clients, all full of verification processes probably and marketing. So I guess this is not a thing I can do. Actually I did <https://s4a.etleneum.com/> (on [Etleneum](nostr:naddr1qqyrjcny8qcn2ve4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823crwzz2w)) that is somewhat similar, but of course doesn't have the glamour and network effect and marketing -- also it's just text, when in Clarity is fancy calls. Thinking about it, this is just a simple and obvious idea: just copy things from the fiat world and make them on Lightning, but maybe it is still worth pointing these out as there are hundreds of developers out there trying to make yet another lottery game with Lightning. It may also be a good idea to not just copy fiat-businesses models, but also change them experimenting with new paradigms, like [idea: Patreon, but simple, and without subscription](nostr:naddr1qqyrgcnrvcmxxc3hqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c3cfczc).

@ 3bf0c63f:aefa459d

# Método científico o método científico não pode ser aplicado senão numa meia dúzia de casos, e no entanto ei-nos aqui, pensando nele para tudo. "formule hipóteses e teste-as independentemente", "obtenha uma quantidade de dados estatisticamente significante", teste, colete dados, mensure. não é que de repente todo mundo resolveu calcular desvios-padrão, mas sim que é comum, para as pessoas mais cultas, nível Freakonomics, acharem que têm que testar e coletar dados, e nunca jamais confiar na sua "intuição" ou, pior, num raciocínio que pode parecer certo, mas na verdade é enormemente enganador. sim, é verdade que raciocínios com explicações aparentemente sensatas nos são apresentados todos os dias -- para um exemplo fácil é só imaginar um comentarista de jornal, ou até uma matéria inocente de jornal, aliás, melhor pensar num comentarista da GloboNews --, e sim, é verdade que a maioria dessas explicações é falsa. o que está errado é achar que só o que vale é testar hipóteses. você não pode testar a explicação aparentemente sensata que o taxista te fornece sobre a crise brasileira, deve então anotá-la para testar depois? mantê-la para sempre no cabedal das teorias ainda por testar? e a explicação das redinhas que economizam água quando instaladas na torneira? essa dá pra testar, então você vai comprar um relógio de água e deixar a torneira ligada lá 5 horas com a redinha, depois 5 horas sem a redinha? obviamente não vai funcionar se você abrir o mesmo tanto, você vai precisar de um critério melhor: a satisfação da pessoa que está lavando as mãos com o resultado final _versus_ a quantidade de água gasta. daí você precisaria de muitas pessoas, mas satisfação é uma coisa imensurável, nem adianta tentar fazer entrevistas antes e depois com as pessoas. o certo então, é o quê? procurar um estudo científico publicado numa revista **de qualidade** (porque tem aquelas revistas que aceitam estudos gerados por computador, então é melhor tomar cuidado) que fala sobre redinhas? como saber se a redinha é a mesma que você comprou? e agora que você já comprou, o resultado do experimento importa? (claro: pode ser que a redinha faça gastar mais água, você nunca saberá até que faça o experimento). por que não, ao invés de condenar todos os raciocínios como enganadores e mandar que as pessoas façam experimentos científicos, ensinar a fazer raciocínios certos?

@ 3bf0c63f:aefa459d

# idea: An open log-based HTTP database for any use case A single, read/write open database for everything in the world. * A hosted database that accepts anything you put on it and stores it in order. * Anyone can update it by adding new stuff. * To make sense of the data you can read only the records that interest you, in order, and reconstruct a local state. * Each updater pays a fee (anonymously, in satoshis) to store their piece of data. * It's a single store for everything in the world. ### Cost and price estimates Prices for guaranteed storage for 3 years: 20 satoshis = 1KB 20 000 000 = 1GB <https://www.elephantsql.com/> charges $10/mo for 1GB of data, 3 600 000 satoshis for 3 years If 3 years is not enough, people can move their stuff to elsewhere when it's time, or pay to keep specific log entries for more time. ### Other considerations * People provide a unique id when adding a log so entries can be prefix-matched by it, like `myapp.something.random` * When fetching, instead of just fetching raw data, add (paid?) option to fetch and apply a `jq` map-reduce transformation to the matched entries

@ 3bf0c63f:aefa459d

# A response to Achim Warner's "Drivechain brings politics to miners" article I mean this article: https://achimwarner.medium.com/thoughts-on-drivechain-i-miners-can-do-things-about-which-we-will-argue-whether-it-is-actually-a5c3c022dbd2 There are basically two claims here: ### 1. Some corporate interests might want to secure sidechains for themselves and thus they will bribe miners to have these activated First, it's hard to imagine why they would want such a thing. Are they going to make a proprietary KYC chain only for their users? They could do that in a corporate way, or with a federation, like Facebook tried to do, and that would provide more value to their users than a cumbersome pseudo-decentralized system in which they don't even have powers to issue currency. Also, if Facebook couldn't get away with their federated shitcoin because the government was mad, what says the government won't be mad with a sidechain? And finally, why would Facebook want to give custody of their proprietary closed-garden Bitcoin-backed ecosystem coins to a random, open and always-changing set of miners? But even if they do succeed in making their sidechain and it is very popular such that it pays miners fees and people love it. Well, then why not? Let them have it. It's not going to hurt anyone more than a proprietary shitcoin would anyway. If Facebook really wants a closed ecosystem backed by Bitcoin that probably means we are winning big. ### 2. Miners will be required to vote on the validity of debatable things He cites the example of a PoS sidechain, an assassination market, a sidechain full of nazists, a sidechain deemed illegal by the US government and so on. There is a simple solution to all of this: just kill these sidechains. Either miners can take the money from these to themselves, or they can just refuse to engage and freeze the coins there forever, or they can even give the coins to governments, if they want. It is an entirely good thing that evil sidechains or sidechains that use horrible technology that doesn't even let us know who owns each coin get annihilated. And it was the responsibility of people who put money in there to evaluate beforehand and know that PoS is not deterministic, for example. About government censoring and wanting to steal money, or criminals using sidechains, I think the argument is very weak because these same things can happen today and may even be happening already: i.e., governments ordering mining pools to not mine such and such transactions from such and such people, or forcing them to reorg to steal money from criminals and whatnot. All this is expected to happen in normal Bitcoin. But both in normal Bitcoin and in Drivechain decentralization fixes that problem by making it so governments cannot catch all miners required to control the chain like that -- and in fact fixing that problem is the only reason we need decentralization.

@ 3bf0c63f:aefa459d

# idea: "numbeo" with satoshis This site has a crowdsourced database of cost-of-living in many countries and cities: <https://www.numbeo.com/cost-of-living/> and it sells the data people write there freely. It's wrong! Could be an fruitful idea to pay satoshis for people to provide data.

@ 3bf0c63f:aefa459d

# The flaw of "just use paypal/coinbase" arguments For the millionth time I read somewhere that "custodial bitcoin is not bitcoin" and that "if you're going to use custodial, better use Paypal". No, actually it was "better use Coinbase", but I had heard the "PayPal" version in the past. There are many reasons why using PayPal is not the same as using a custodial Bitcoin service or wallet that are obvious and not relevant here, such as the fact that you can't have Bitcoin balances on Bitcoin (or maybe now you can? but you can't send it around); plus all the reasons that are also valid for Coinbase such as you having to give all your data and selfies of yourself and your government documents and so on -- but let's ignore these reasons for now. The most important reason why it isn't the same thing is that when you're using Coinbase you are stuck in Coinbase. Your Coinbase coins cannot be used to pay anyone that isn't in Coinbase. So Coinbase-style custodianship doesn't help Bitcoin. If you want to move out of Coinbase you have to withdraw from Coinbase. Custodianship on Lightning is of a very different nature. You can pay people from other custodial platforms and people that are hosting their own Lightning nodes and so on. That kind of custodianship doesn't do any harm to anyone, doesn't fracture the network, doesn't reduce the network effect of Lightning, in fact it increases it.

@ 3bf0c63f:aefa459d

# A entrevista da Flávia Tavares com o Olavo de Carvalho Não li todas as reclamações que o Olavo fez, mas li algumas. Também não li toda a matéria que saiu na Época, porque não tive paciência, mas assisti aos dois vídeos da entrevista que o Olavo publicou. Tendo lido primeiro as muitas reclamações do Olavo, esperei encontrar no vídeo uma pessoa falsa, que fingiu-se de amigável para obter informações que usaria depois para destruir a imagem do Olavo, mas não vi nada disso. Claro que ela poderia ter me enganado também, se enganou ao Olavo. Mas na matéria em si, também não vi nada além de sinceridade -- talvez não excelência jornalística, mas nada que eu não esperasse de qualquer matéria de qualquer revista. Flavia Tavares não entendeu muitas coisas, mas não fingiu que não entendeu nada, foi simples e honestamente Flavia Tavares, como ela mesma declarou no final do vídeo da entrevista: "olha, eu não fingi nada aqui, viu?". --- O mais importante de tudo isso, porém, são as partes da matéria que apresentam idéias difíceis de conceber, como as que Olavo tem sobre o governo mundial ou a disseminação da pedofilia. Em toda discussão pública ou privada, essas idéias são proibidas. Muita gente pode concordar que a esquerda não presta, mas ninguém em sã consciência admitirá a possibilidade de que haja qualquer intenção significativa de implantação de um governo mundial ou da disseminação da pedofilia. A mesma carinha de deboche que seu amigo esquerdista faria à simples menção desses assuntos é a que Flavia Tavares usa no seu texto quando quer mostrar que Olavo é meio tantã. A carinha de deboche vem desacompanhada de qualquer reflexão séria ou tentativa de refutação, sempre. --- Link da tal matéria: <http://epoca.globo.com/sociedade/noticia/2017/10/olavo-de-carvalho-o-guru-da-direita-que-rejeita-o-que-dizem-seus-fas.html?utm_source=twitter&utm_medium=social&utm_campaign=post> Vídeos: <https://www.youtube.com/watch?v=C0TUsKluhok,> <https://www.youtube.com/watch?v=yR0F1haQ07Y&t=5s>

@ 3bf0c63f:aefa459d

# Lightning and its fake HTLCs Lightning is terrible but can be very good with two tweaks. ## How Lightning would work without HTLCs In a world in which HTLCs didn't exist, Lightning channels would consist only of balances. Each commitment transaction would have two outputs: one for peer `A`, the other for peer `B`, according to the current state of the channel. When a payment was being attempted to go through the channel, peers would just trust each other to update the state when necessary. For example: 1. Channel `AB`'s balances are `A[10:10]B` (in sats); 2. `A` sends a 3sat payment through `B` to `C`; 3. `A` asks `B` to route the payment. Channel `AB` doesn't change at all; 4. `B` sends the payment to `C`, `C` accepts it; 5. Channel `BC` changes from `B[20:5]C` to `B[17:8]C`; 6. `B` notifies `A` the payment was successful, `A` acknowledges that; 7. Channel `AB` changes from `A[10:10]B` to `A[7:13]B`. This in the case of a success, everything is fine, no glitches, no dishonesty. But notice that `A` could have refused to acknowledge that the payment went through, either because of a bug, or because it went offline forever, or because it is malicious. Then the channel `AB` would stay as `A[10:10]B` and `B` would have lost 3 satoshis. ## How Lightning would work with HTLCs HTLCs are introduced to remedy that situation. Now instead of commitment transactions having always only two outputs, one to each peer, now they can have HTLC outputs too. These HTLC outputs could go to either side dependending on the circumstance. Specifically, the peer that is sending the payment can redeem the HTLC after a number of blocks have passed. The peer that is receiving the payment can redeem the HTLC if they are able to provide the preimage to the hash specified in the HTLC. Now the flow is something like this: 1. Channel `AB`'s balances are `A[10:10]B`; 2. `A` sends a 3sat payment through `B` to `C`: 3. `A` asks `B` to route the payment. Their channel changes to `A[7:3:10]B` (the middle number is the HTLC). 4. `B` offers a payment to `C`. Their channel changes from `B[20:5]C` to `B[17:3:5]C`. 5. `C` tells `B` the preimage for that HTLC. Their channel changes from `B[17:3:5]C` to `B[17:8]C`. 6. `B` tells `A` the preimage for that HTLC. Their channel changes from `A[7:3:10]B` to `A[7:13]B`. Now if `A` wants to trick `B` and stop responding `B` doesn't lose money, because `B` knows the preimage, `B` just needs to publish the commitment transaction `A[7:3:10]B`, which gives him 10sat and then redeem the HTLC using the preimage he got from `C`, which gives him 3 sats more. `B` is fine now. In the same way, if `B` stops responding for any reason, `A` won't lose the money it put in that HTLC, it can publish the commitment transaction, get 7 back, then redeem the HTLC after the certain number of blocks have passed and get the other 3 sats back. ## How Lightning doesn't really work The example above about how the HTLCs work is very elegant but has a fatal flaw on it: transaction fees. Each new HTLC added increases the size of the commitment transaction and it requires yet another transaction to be redeemed. If we consider fees of 10000 satoshis that means any HTLC below that is as if it didn't existed because we can't ever redeem it anyway. In fact the Lightning protocol explicitly dictates that if HTLC output amounts are below the fee necessary to redeem them they shouldn't be created. What happens in these cases then? Nothing, the amounts that should be in HTLCs are moved to the commitment transaction miner fee instead. So considering a transaction fee of 10000sat for these HTLCs if one is sending Lightning payments below 10000sat that means they operate according to the _unsafe protocol_ described in the first section above. It is actually worse, because consider what happens in the case a channel in the middle of a route has a glitch or one of the peers is unresponsive. The other node, thinking they are operating in the _trustless protocol_, will proceed to publish the commitment transaction, i.e. close the channel, so they can redeem the HTLC -- only then they find out they are actually in the _unsafe protocol_ realm and there is no HTLC to be redeemed at all and they lose not only the money, but also the channel (which costed a lot of money to open and close, in overall transaction fees). One of the biggest features of the _trustless protocol_ are the payment proofs. Every payment is identified by a hash and whenever the payee releases the preimage relative to that hash that means the payment was complete. The incentives are in place so all nodes in the path pass the preimage back until it reaches the payer, which can then use it as the proof he has sent the payment and the payee has received it. This feature is also lost in the _unsafe protocol_: if a glitch happens or someone goes offline on the preimage's way back then there is no way the preimage will reach the payer because no HTLCs are published and redeemed on the chain. The payee may have received the money but the payer will not know -- but the payee will lose the money sent anyway. ## The end of HTLCs So considering the points above you may be sad because in some cases Lightning doesn't use these magic HTLCs that give meaning to it all. But the fact is that no matter what anyone thinks, HTLCs are destined to be used less and less as time passes. The fact that over time Bitcoin transaction fees tend to rise, and also the fact that multipart payment (MPP) are increasedly being used on Lightning for good, we can expect that soon no HTLC will ever be big enough to be actually worth redeeming and we will be at a point in which not a single HTLC is real and they're all fake. Another thing to note is that the current _unsafe protocol_ kicks out whenever the HTLC amount is below the Bitcoin transaction fee would be to redeem it, but this is not a reasonable algorithm. It is not reasonable to lose a channel and then pay 10000sat in fees to redeem a 10001sat HTLC. At which point does it become reasonable to do it? Probably in an amount many times above that, so it would be reasonable to even increase the threshold above which real HTLCs are made -- thus making their existence more and more rare. These are good things, because we don't actually need HTLCs to make a functional Lightning Network. ## We must embrace the _unsafe protocol_ and make it better So the _unsafe protocol_ is not necessarily very bad, but the way it is being done now is, because it suffers from two big problems: 1. Channels are lost all the time for no reason; 2. No guarantees of the proof-of-payment ever reaching the payer exist. The first problem we fix by just stopping the current practice of closing channels when there are no real HTLCs in them. That, however, creates a new problem -- or actually it exarcebates the second: now that we're not closing channels, what do we do with the expired payments in them? These payments should have either been canceled or fulfilled before some block x, now we're in block x+1, our peer has returned from its offline period and one of us will have to lose the money from that payment. That's fine because it's only 3sat and it's better to just lose 3sat than to lose both the 3sat and the channel anyway, so either one would be happy to eat the loss. Maybe we'll even split it 50/50! No, that doesn't work, because it creates an attack vector with peers becoming unresponsive on purpose on one side of the route and actually failing/fulfilling the payment on the other side and making a profit with that. So we actually need to know who is to blame on these payments, even if we are not going to act on that imediatelly: we need some kind of arbiter that both peers can trust, such that if one peer is trying to send the preimage or the cancellation to the other and the other is unresponsive, when the unresponsive peer comes back, the arbiter can tell them they are to blame, so they can willfully eat the loss and the channel can continue. Both peers are happy this way. If the unresponsive peer doesn't accept what the arbiter says then the peer that was operating correctly can assume the unresponsive peer is malicious and close the channel, and then blacklist it and never again open a channel with a peer they know is malicious. Again, the differences between this scheme and the current Lightning Network are that: a. In the current Lightning we always close channels, in this scheme we only close channels in case someone is malicious or in other worst case scenarios (the arbiter is unresponsive, for example). b. In the current Lightning we close the channels without having any clue on who is to blame for that, then we just proceed to reopen a channel with that same peer even in the case they were actively trying to harm us before. ## What is missing? An arbiter. The Bitcoin blockchain is the ideal arbiter, it works in the best possible way if we follow the _trustless protocol_, but as we've seen we can't use the Bitcoin blockchain because it is expensive. Therefore we need a new arbiter. That is the hard part, but not unsolvable. Notice that we don't need an absolutely perfect arbiter, anything is better than nothing, really, even an unreliable arbiter that is offline half of the day is better than what we have today, or an arbiter that lies, an arbiter that charges some satoshis for each resolution, anything. Here are some suggestions: - random nodes from the network selected by an algorithm that both peers agree to, so they can't cheat by selecting themselves. The only thing these nodes have to do is to store data from one peer, try to retransmit it to the other peer and record the results for some time. - a set of nodes preselected by the two peers when the channel is being opened -- same as above, but with more handpicked-trust involved. - some third-party cloud storage or notification provider with guarantees of having open data in it and some public log-keeping, like Twitter, GitHub or a [Nostr](https://github.com/fiatjaf/nostr) relay; - peers that get paid to do the job, selected by the fact that they own some token (I know this is stepping too close to the shitcoin territory, but could be an idea) issued in a [Spacechain](https://www.youtube.com/watch?v=N2ow4Q34Jeg); - a Spacechain itself, serving only as the storage for a bunch of `OP_RETURN`s that are published and tracked by these Lightning peers whenever there is an issue (this looks wrong, but could work). ## Key points 1. Lightning with HTLC-based routing was a cool idea, but it wasn't ever really feasible. 2. HTLCs are going to be abandoned and that's the natural course of things. 3. It is actually good that HTLCs are being abandoned, but 4. We must change the protocol to account for the existence of fake HTLCs and thus make the bulk of the Lightning Network usage viable again. ## See also - [Ripple and the problem of the decentralized commit](nostr:naddr1qqyrxcmzxa3nxv34qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cjrqar6) - [The Lightning Network solves the problem of the decentralized commit](nostr:naddr1qqyx2vekxg6rsvejqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccs2twc)

@ 3bf0c63f:aefa459d

# On HTLCs and arbiters This is another attempt and conveying the same information that should be in [Lightning and its fake HTLCs](nostr:naddr1qqyryefsxqcxgdmzqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cp0m63a). It assumes you know everything about Lightning and will just highlight a point. This is also valid for PTLCs. The protocol says HTLCs are trimmed (i.e., not actually added to the commitment transaction) when the cost of redeeming them in fees would be greater than their actual value. Although this is often dismissed as a non-important fact (often people will say "it's trusted for small payments, no big deal"), but I think it is indeed very important for 3 reasons: 1. Lightning absolutely relies on HTLCs actually existing because the payment proof requires them. The entire security of each payment comes from the fact that the payer has a preimage that comes from the payee. Without that, the state of the payment becomes an unsolvable mystery. The inexistence of an HTLC breaks the atomicity between the payment going through and the payer receiving a proof. 2. Bitcoin fees are expected to grow with time (arguably the reason Lightning exists in the first place). 3. MPP makes payment sizes shrink, therefore more and more of Lightning payments are to be trimmed. As I write this, the mempool is clear and still payments smaller than about 5000sat are being trimmed. Two weeks ago the limit was at 18000sat, which is already below the minimum most MPP splitting algorithms will allow. Therefore I think it is important that we come up with a different way of ensuring payment proofs are being passed around in the case HTLCs are trimmed. ## Channel closures Worse than not having HTLCs that can be redeemed is the fact that in the current Lightning implementations channels will be closed by the peer once an HTLC timeout is reached, either to fulfill an HTLC for which that peer has a preimage or to redeem back that expired HTLCs the other party hasn't fulfilled. For the surprise of everybody, nodes will do this even when the HTLCs in question were trimmed and therefore cannot be redeemed at all. It's very important that nodes stop doing that, because it makes no economic sense at all. However, that is not so simple, because once you decide you're not going to close the channel, what is the next step? Do you wait until the other peer tries to fulfill an expired HTLC and tell them you won't agree and that you must cancel that instead? That could work sometimes if they're honest (and they have no incentive to not be, in this case). What if they say they tried to fulfill it before but you were offline? Now you're confused, you don't know if you were offline or they were offline, or if they are trying to trick you. Then unsolvable issues start to emerge. ## Arbiters One simple idea is to use trusted arbiters for all trimmed HTLC issues. This idea solves both the protocol issue of getting the preimage to the payer once it is released by the payee -- and what to do with the channels once a trimmed HTLC expires. A simple design would be to have each node hardcode a set of trusted other nodes that can serve as arbiters. Once a channel is opened between two nodes they choose one node from both lists to serve as their mutual arbiter for that channel. Then whenever one node tries to fulfill an HTLC but the other peer is unresponsive, they can send the preimage to the arbiter instead. The arbiter will then try to contact the unresponsive peer. If it succeeds, then done, the HTLC was fulfilled offchain. If it fails then it can keep trying until the HTLC timeout. And then if the other node comes back later they can eat the loss. The arbiter will ensure they know they are the ones who must eat the loss in this case. If they don't agree to eat the loss, the first peer may then close the channel and blacklist the other peer. If the other peer believes that both the first peer and the arbiter are dishonest they can remove that arbiter from their list of trusted arbiters. The same happens in the opposite case: if a peer doesn't get a preimage they can notify the arbiter they hadn't received anything. The arbiter may try to ask the other peer for the preimage and, if that fails, settle the dispute for the side of that first peer, which can proceed to fail the HTLC is has with someone else on that route.

@ 3bf0c63f:aefa459d

# jq-finder Made with [jq-web](nostr:naddr1qqyrzvrzxqcx2dfsqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c90hqwz), a tool to explore JSON using `jq` queries that build intermediate results so you can inspect each step of the process.  - <https://jq.alhur.es/finder/> - <https://github.com/fiatjaf/jq-finder>

@ 3bf0c63f:aefa459d

# superform.xyz This was an app that allowed people to create micro apps powered by forms. Actually just one form I believe. The idea was for the micro apps to be really micro. For example, you want a list of people, but you can only have at most 10 people in the list. Your app could keep a state with list of people already added and reject any other submissions above the specified limit. This would be done with 3 lines of code and provide an automatic form for people to fill with expected data. Another example, you wanted to create a list of people that would go to an event and each would have to bring one item from a list: you created an initial state of a list of the items that should be brought, then specified a form where people could write their names and select the item they would bring, then code that for each submitted form added the name of the person plus the item they would bring to the state while also removing the selected item from the available items. Also 3 or 4 lines of data. Something like this can't be done anywhere else. But also of course it would be arcane and frighten normal people and so on (although I do believe some "normal" people would be able to use such a thing if they needed it, just like they learn to write complex Excel formulas and still don't call themselves programmers). - <https://github.com/fiatjaf/superform.xyz> ## See also - [Etleneum](nostr:naddr1qqyrjcny8qcn2ve4qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823crwzz2w), as it is basically the same core idea of a mutable state that is affected by calls, but Etleneum introduces (and actually forces the usage of) money, both in the sense that it acts as an escrow for contract results and that it mandates the payment of a small amount with each call, so it ends up not serving the same purposes.

@ 3bf0c63f:aefa459d

# Timeu Os quatro elementos, a esfera como a forma mais perfeita, os cinco sentidos, a dor como perturbação e o prazer como retorno, o demiurgo que cria da melhor maneira possível com a matéria que tem, o conceito de duro e mole, todas essas coisas que ensinam nas escolas e nos desenhos animados ou sei lá como entram na nossa consciência como se fossem uma verdade, mas sempre uma verdade provisória, infantil -- como os nomes infantis dos dedos (mata-piolho, fura-bolo etc.) --, que mesmo as crianças sabem que não é verdade mesmo. Parece que todas essas coisas estão nesse livro. Talvez até mesmo a classificação dos cinco dedos como mata-piolho e tal, mas talvez eu tenha dormido nessa parte. Me pergunto se essas coisas não eram ensinadas tradicionalmente na idade média como sendo verdade absoluta (pois afinal estava lá o Platão dizendo, em sua única obra) e persistiram até hoje numa tradição que se mantém aos trancos e barrancos, contra tudo e contra todos, sem ninguém saber como, um conhecimento em que ninguém acredita mas acha bonito mesmo assim, harmonioso, e vem despida de suas origens e fontes primárias e de todo o seu contexto perturbar o entendimento do mundo pelas crianças.

@ 3bf0c63f:aefa459d

# IPFS problems: Conceit IPFS is trying to do many things. The IPFS leaders are revolutionaries who think they're smarter than the rest of the entire industry. The fact that they've first proposed a protocol for peer-to-peer distribution of immutable, content-addressed objects, then later tried to fix [that same problem](nostr:naddr1qqyrqen9xf3nvdpeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cmdjnnj) using their own half-baked solution (IPNS) is one example. Other examples are their odd appeal to decentralization in a very non-specific way, their excessive [flirtation with Ethereum](nostr:naddr1qqyxxdpev5cnsvpkqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cta4a2e) and their never-to-be-finished can-never-work-as-advertised _Filecoin_ project. They could have focused on just making the infrastructure for distribution of objects through hashes (not saying this would actually be a good idea, but it had some potential) over a peer-to-peer network, but in trying to reinvent the entire internet they screwed everything up.

@ 3bf0c63f:aefa459d

# "Você só aprendeu mesmo uma coisa quando consegue explicar para os outros" Mentira. Tá certo que existe um ponto em que você acha que sabe algo mas não consegue explicar, mas não necessariamente isso significa não saber. Conseguir explicar não depende de saber, mas de verbalizar. Podemos saber muitas coisas sem as conseguir verbalizar. Aliás, para a maior parte das experiências humanas verbalizar é que é a parte difícil. Por último, é importante dizer que a verbalização é uma abstração e portanto quando alguém tenta explicar algo e se força a fazer uma abstração está arriscando substituir a experiência concreta ou mesmo o conhecimento difuso de algo por aquela abstração e com isso ficar mais burro -- me parece que esse é risco é maior quanto mais prematura for a tentativa de explicação e quando mais sucesso a abstração improvisada fizer.

@ 3bf0c63f:aefa459d

# Liberalismo oitocentista Quando comecei a ler sobre "liberalismo" na internet havia sempre umas listas de livros recomendados, uns Ludwig von Mises, Milton Friedman e Alexis de Tocqueville. "A Democracia na América". Pra mim parecia estranho aquele papo de democracia quando eu estava interessado era em como funcionaria um mercado livre, sem regulações e tal. Parece que Tocqueville era uma herança do mesmo povo que adorava a expressão "liberalismo clássico". O liberalismo clássico era uma coisa política que ia contra a monarquia e em favor da democracia, e aí Tocqueville se encaixava muito bem. Poucos anos se passaram e tudo mudou. Agora acho que alguém lendo na internet não vai ver menção nenhuma a Tocqueville ou liberalismo clássico, essa chatice de democracia e suas [chatices legalistas](nostr:naddr1qqyr2df58qekxce3qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c0n53d9). O "libertarianismo", também um nome infeliz, tomou conta de tudo, e cresceu muito mais do que o movimento liberal-da-internet jamais imaginou que seria possível. Os libertários brasileiros são anarquistas, detestam a democracia, reconhecem nela um [vetor de ataque](nostr:naddr1qqyrxvtxxf3nse3sqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ccyra4y) dos socialistas a qualquer pontinha de livre-mercado que exista -- e às liberdades individuais dos cidadãos (este aqui ainda um ponto em comum com os liberais oitocentistas). São inclusive muito mais propensos a defender a monarquia do que a democracia. E isso é uma coisa boa. Finalmente uma pessoa pode defender princípios razoáveis de livre-mercado e individualismo sem precisar se associar com o movimento setecentistas e oitocentista que fez coisas boas, mas também foi responsável por coisas horríveis como a revolução francesa e todos os seus absurdos, e de onde saiu todo o movimento socialista. - [Democracia na América](nostr:naddr1qqyrzc3ev3jn2vrpqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c8ynvrd)

@ 3bf0c63f:aefa459d

# lnurl-auth explained You may have seen the [lnurl-auth](https://github.com/btcontract/lnurl-rfc/blob/master/lnurl-auth.md) spec or heard about it, but might not know how it works or what is its relationship with other [lnurl](https://github.com/fiatjaf/awesome-lnurl) protocols. This document attempts to solve that. ## Relationship between lnurl-auth and other lnurl protocols First, **what is the relationship of lnurl-auth with other lnurl protocols?** The answer is none, except the fact that they all share the lnurl format for specifying `https` URLs. In fact, lnurl-auth is very unique in the sense that it doesn't even need a Lightning wallet to work, it is a standalone authentication protocol that can work anywhere. ## How does it work Now, **how does it work?** The basic idea is that each wallet has a seed, which is a random value (you may think of the BIP39 seed words, for example). Usually from that seed different keys are derived, each of these yielding a Bitcoin address, and also from that same seed may come the keys used to generate and manage Lightning channels. What lnurl-auth does is to generate a new key from that seed, and from that a new key for each service (identified by its domain) you try to authenticate with.  That way, you effectively have a new identity for each website. Two different services cannot associate your identities. **The flow goes like this:** When you visit a website, the website presents you with a QR code containing a _callback URL_ and a _challenge_. The challenge should be a random value.  When your wallet scans or opens that QR code it uses the _domain_ in the callback URL plus the _main lnurl-auth key_ to derive a key specific for that website, uses that key to sign the challenge and then sends both the public key specific for that for that website plus the signed challenge to the specified URL.  When the service receives the public key it checks it against the challenge signature and start a session for that user. The user is then **identified only by its public key**. If the service wants it can, of course, request more details from the user, associate it with an internal id or username, it is free to do anything. lnurl-auth's goals end here: no passwords, maximum possible privacy. # FAQ * What is the advantage of tying this to Bitcoin and Lightning? One big advantage is that your wallet is already keeping track of one seed, it is already a precious thing. If you had to keep track of a separate auth seed it would be arguably worse, more difficult to bootstrap the protocol, and arguably one of the reasons similar protocols, past and present, weren't successful. * Just signing in to websites? What else is this good for? No, it can be used for authenticating to installable apps and physical places, as long as there is a service running an HTTP server somewhere to read the signature sent from the wallet. But yes, signing in to websites is the main problem to solve here. * Phishing attack! Can a malicious website proxy the QR from a third website and show it to the user to it will steal the signature and be able to login on the third website? No, because the wallet will only talk to the the callback URL, and it will either be controlled by the third website, so the malicious won't see anything; or it will have a different domain, so the wallet will derive a different key and frustrate the malicious website's plan. * I heard [SQRL](https://sqrl.grc.com/) had that same idea and it went nowhere. Indeed. SQRL in its first version was basically the same thing as lnurl-auth, with one big difference: it was vulnerable to phishing attacks (see above). That was basically the only criticism it got everywhere, so the protocol creators decided to solve that by introducing complexity to the protocol. While they were at it they decided to add more complexity for managing accounts and so many more crap that in the the spec which initially was a single page ended up becoming 136 pages of highly technical gibberish. Then all the initial network effect it had, libraries and apps were trashed and nowadays no one can do anything with it (but, [see](https://sqrl.grc.com/threads/developer-documentation-conflicted-and-confusing-please-help-clarify.951/), there are still people who love the protocol writing in a 90's forum with no clue of anything besides their own Java). * We don't need this, we need WebAuthn! [WebAuthn](https://webauthn.guide/) is essentially the same thing as lnurl-auth, but instead of being simple it is complex, instead of being open and decentralized it is centralized in big corporations, and instead of relying on a key generated by your own device it requires an expensive hardware HSM you must buy and trust the manufacturer. If you like WebAuthn and you like Bitcoin you should like lnurl-auth much more. * What about [BitID](https://github.com/bitid/bitid)? This is another one that is [very similar](https://www.youtube.com/watch?v=3eepEWTnRTc) to lnurl-auth, but without the anti-phishing prevention and extra privacy given by making one different key for each service. * What about LSAT? It doesn't compete with lnurl-auth. LSAT, as far as I understand it, is for when you're buying individual resources from a server, not authenticating as a user. Of course, LSAT can be repurposed as a general authentication tool, but then it will lack features that lnurl-auth has, like the property of having keys generated independently by the user from a common seed and a standard way of passing authentication info from one medium to another (like signing in to a website at the desktop from the mobile phone, for example).

@ 3bf0c63f:aefa459d

# A Lightning penalty transaction It was a cold day and I remembered that this `lightningd` node I was running on my local desktop to work on [poncho](https://github.com/fiatjaf/poncho) actually had mainnet channels in it. Two channels, both private, bought on https://lnbig.com/ a while ago when I was trying to conduct an anonymous griefing attack on big nodes of the network just to prove it was possible (the attempts proved unsuccessful after some hours and I gave up). It is always painful to close channels because paying fees hurts me psychologically, and then it hurts even more to be left with a new small UTXO that will had to be spent to somewhere but that can barely pay for itself, but it also didn't make sense to just leave the channels there and risk forgetting them and losing them forever, so I had to do something. One of the channels had 0 satoshis on my side, so that was easy. Mutually closed and I don't have to think anymore about it. The other one had 10145 satoshis on my side -- out of a total of 100000 satoshis. Why can't I take my part all over over Lightning and leave the full channel UTXO to LNBIG? I wish I could do that, I don't want a small UTXO. I was not sure about it, but if the penalty reserve was 1% maybe I could take out abou 9000 satoshis and then close it with 1000 on my side? But then what would I do with this 1000 sat UTXO that would remain? Can't I donate it to miners or something? I was in the middle of this thoughts stream when it came to me the idea of causing a penalty transaction to give those abundant 1000 sat to Mr. LNBIG as a donation for his excellent services to the network and the cause of Bitcoin, and for having supported the development of https://sbw.app/ and the hosted channels protocol. Unfortunately `lightningd` doesn't have a command `triggerpenaltytransaction` or `trytostealusingoldstate`, so what I did was: First I stopped `lightningd` then copied the database to elsewhere: ``` cp ~/.lightningd/bitcoin/lightningd.sqlite3 ~/.lightning/bitcoin/lightningd.sqlite3.bak ``` then I restarted `lightningd` and fighted against the way-too-aggressive MPP splitting algorithm the `pay` command uses to pay invoices, but finally managed to pull about 9000 satoshis to my [Z Bot](https://t.me/zebedeebot) that lives on the terrible (but still infinitely better than Twitter DMs) "webk" flavor of the Telegram web application and which is linked to my against-bitcoin-ethos-country-censoring [ZEBEDEE Wallet](https://zbd.gg/). The operation wasn't smooth but it didn't take more than 10 invoices and `pay` commands.  With the money out and safe elsewhere, I stopped the node again, moved the database back with a reckless ``` mv ~/.lightning/bitcoin/lightningd.sqlite3.bak ~/.lightningd/bitcoin/lightningd.sqlite3 ``` and restarted it, but to prevent my `lightningd` from being super naïve and telling LNBIG that it had an old state (I don't know if this would happen) which would cause LNBIG to close the channel in a boring way, I used the `--offline` flag which apparently causes the node to not do any external connections. Finally I checked my balance using `lightning-cli listfunds` and there it was, again, the 10145 satoshis I had at the start! A fantastic money creation trick, comparable to the ones central banks execute daily.  I was ready to close the channel now, but the `lightning-cli close` command had an option for specifying how many seconds I would wait for a mutual close before proceeding to a unilateral close. There is no `forceclose` command like Éclair hasor anything like that. I was afraid that even if I gave LNBIG one second it would try to do boring things, so I paused to consider how could I just broadcast the commitment transaction manually, looked inside the SQLite database and the `channels` table with its millions of columns with cryptic names in the unbearable `.schema` output, imagined that `lightningd` maybe wouldn't know how to proceed to take the money from the `to-local` output if I managed to broadcast it manually (and in the unlikely event that LNBIG wouldn't broadcast the penalty transaction), so I decided to just accept the risk and call ``` lightning-cli close 706327x1588x0 1 ``` But it went well. The `--offline` flag apparently really works, as it just considered LNBIG to be offline and 1 second later I got the desired result.  My happiness was complete when I saw the commitment transaction with my output for 10145 satoshis published on the central database of Bitcoin, [blockstream.info](https://blockstream.info/tx/e5ceedadb98f612e5f3830985ebafd1cf1cae560b03eb5876a1fa1b14cfd0384?expand).  Then I went to eat something and it seems LNBIG wasn't offline or sleeping, he was certainly looking at all the logs from his 274 nodes in a big room full of monitors, very alert and eating an apple while drinking coffee, ready to take action, for when I came back, minutes later, I could see it, again on the single source of truth for the Bitcoin blockchain, the Blockstream explorer. I've refreshed the page and there it was, a small blue link right inside the little box that showed my `to-local` output, a notice saying it had been spent -- not by my `lightningd` since that would have to wait 9000 blocks, but by the same transaction that spent the other output, from which I could be very sure it was it, the glorious, mighty, unforgiving [**penalty transaction**](https://blockstream.info/tx/80ab328c77cbd554598c3a7b322af520a77d1687b27badfa969d2c419de785d7?input:1&expand), splitting the earth, showing itself in all its power, and taking my 10145 satoshis to their rightful owner. 

@ 3bf0c63f:aefa459d

# Trello Attachment Editor A static JS app that allowed you to authorize with your Trello account, fetch the board structure, find attachments, edit them in the browser then replace them in the cards. Quite a nice thing. I believe it was done to help with [Websites For Trello](nostr:naddr1qqyrydpkvverwvehqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c9d4yku) attached scripts and CSS files. - <https://github.com/fiatjaf/trello-attachments> - <https://fiatjaf.github.io/trello-attachments/#/login> ### See also - [Temperos](nostr:naddr1qqyrvvpevgurzwfeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823cvyhzdz)

@ 3bf0c63f:aefa459d

# Soft-fork activation through `bitcoind` competition Or: how to activate [_Drivechain_](nostr:naddr1qq9xgunfwejkx6rpd9hqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gumtjfnp). Imagine a world in which there are 10 different `bitcoind` flavors, as described in [`bitcoind` decentralization](nostr:naddr1qqyxzcfevscxzvnrqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chus9ym). Now how do you enable a soft-fork? Flavor 1 enables it. Seeing that nothing bad happened, flavor 2 enables it. Then flavor 3 enables it. And so on. When what is perceived by miners to be a big chunk of support for the proposal, a miner can try to mine a block that contains the new feature. No need for a flag day or a centralized decision making process that depends on one or two courageous leaders to enable a timer. --- This probably sounds silly, and maybe is.

@ 3bf0c63f:aefa459d

# localchat A server that creates instant chat rooms with [Server-Sent Events](https://en.wikipedia.org/wiki/Server-sent_events) and normal HTTP `POST` requests (instead of WebSockets which are an overkill most of the times). It defaults to a room named as your public IP, so if two machines in the same LAN connect they'll be in the same chat automatically -- but then you can also join someone else's LAN if you need. This is supposed to be useful.  - <https://github.com/fiatjaf/localchat> - <https://localchat.bigsun.xyz/> ## See also - [Filemap](nostr:naddr1qqyrwcekv33rze3kqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c23ya8a)

@ 3bf0c63f:aefa459d

# Veterano não é dono de bixete "VETERANO NÃO É DONO DE BIXETE". A frase em letras garrafais chama a atenção dos transeuntes neófitos. Paira sobre um cartaz amarelo que lista várias reclamações contra os "trotes machistas", que, na opinião do responsável pelo cartaz, "não é brincadeira, é opressão". Eis aí um bizarro exemplo de como são as coisas: primeiro todos os universitários aprovam a idéia do trote, apoiam sua realização e até mesmo desejam sofrer o trote -- com a condição de o poderem aplicar eles mesmos depois --, louvam as maravilhas do mundo universitário, onde a suprema sabedoria se esconde atrás de rituais iniciáticos fora do alcance da imaginação do homem comum e rude, do pobre e do filhinho-de-papai das faculdades privadas; em suma: fomentam os mais baixos, os mais animalescos instintos, a crueldade primordial, destroem em si mesmos e nos colegas quaisquer valores civilizatórios que tivessem sobrado ali, ficando todos indistingüíveis de macacos agressivos e tarados. Depois vêm aí com um cartaz protestar contra os assédios -- que sem dúvida acontecem em larguíssima escala -- sofridos pelas calouras de 17 anos e que, sendo também novatas no mundo universitário, ainda conservam um pouco de discernimento e pudor. A incompreensão do fenômeno, porém, é tão grande, que os trotes não são identificados como um problema mental, uma doença que deve ser tratada e eliminada, mas como um sintoma da opressão machista dos homens às mulheres, um produto desta civilização paternalista que, desde que Deus é chamado "o Pai" e não "a Mãe", corrompe a benéfica, pura e angélica natureza do homem primitivo e o torna esta tão torpe criatura. Na opinião dos autores desse cartaz é preciso, pois, continuar a destruir o que resta da cultura ocidental, e então esperar que haja trotes menos opressores.

@ 3bf0c63f:aefa459d

# Who will build the roads? Who will build the roads? Em Lagoa Santa, as mais novas e melhores ruas -- que na verdade acabam por formar enormes teias de bairros que se interligam -- são construídas pelos loteadores que querem as ruas para que seus lotes valham mais -- e querem que outras pessoas usem as ruas também. Também são esses mesmos loteadores que colocam os postes de luz e os encanamentos de água, não sem antes terem que se submeter a extorsões de praxe praticadas por COPASA e CEMIG. Se ao abrir um loteamento, condomínio, prédio um indivíduo ou uma empresa consegue sem muito problema passar rua, eletricidade, água e esgoto, por que não seria possível existir livre-concorrência nesses mercados? Mesmo aquela velha estória de que é ineficiente passar cabos de luz duplicados para que companhias elétricas possam competir já me parece bobagem.