@ 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", ""] ```