査読した。結論からいうと、UIモックとしてはかなりよくできてるけど、「NIPを技術的な裏付けにして機能対応を判定する」という核心部分に、かなり大きい設計上の問題がある。単なる細かい表記ミスではなく、実データ化する前に直したほうがいいところがある。
特に重要なのはこれ。
1. 「機能 → NIP」の対応がかなりズレている【重要】
現在はたとえばこうなっている。
機能 Nosmapsで使っているNIP 問題
投稿・返信 01 / 09 / 25 09=削除、25=リアクションなので「投稿・返信」の根拠として変
DM 44 44は暗号化方式。DMそのものではない
検索 01 / 19 / 21 検索機能そのものを定義するNIP-50が抜けている
画像・動画 01 / 19 メディア機能の根拠として弱すぎる
複数アカウント 19 / 46 どちらも「複数アカウント対応」を意味しない
チャンネル 01 / 42 / 78 42はリレー認証、78はアプリ固有データ。チャンネルとはほぼ無関係
公式NIPsの現行一覧では、NIP-17がPrivate Direct Messages、NIP-50がSearch Capability、NIP-68がPicture-first feeds、NIP-71がVideo Events、NIP-29がRelay-based Groupsになっている。さらに旧Public ChatのNIP-28とModerated CommunitiesのNIP-72は現在非推奨扱い。
なので例えばDMなら、
DM → NIP-17
→ 内部の暗号化技術として NIP-44 / NIP-59
くらいの構造にするのが自然。
「NIP-44対応 → DM対応」とすると、
> 暗号化関数は実装してるけどDM UIはないライブラリ
までDM対応と判定されかねない。
---
2. featureSupport() の判定アルゴリズムが危ない【かなり重要】
ここ。
const rank = {implemented: 4, partial: 3, planned: 2, unknown: 1};
return records.map(record => record.status)
.sort((a, b) => rank[b] - rank[a])[0];
つまり、ある機能に3つNIPが紐付いていた場合、
NIP-A → implemented
NIP-B → unknown
NIP-C → unknown
でも、
機能 = 「対応」
になる。
これは「一番良いNIPの状態を採用」しているため。
たとえば現在の「投稿・返信」は01 / 09 / 25なので、
> NIP-01だけ実装
NIP-09なし
NIP-25なし
でも「投稿・返信：対応」になり得る。
むしろ機能判定は
必須NIP 補助NIP 代替NIP
を区別すべき。
たとえば、
検索
required:
- NIP-50
optional:
- NIP-19
- NIP-21
みたいにした方が圧倒的に正確。
---
3. 「NIP対応 = 機能対応」という前提自体が成立しないものがある
特にこれ。
複数アカウント
現在：
nips: ['19', '46']
NIP-19は npub / note 等のエンコード方式、NIP-46はリモート署名。公式仕様でもその位置づけ。
でも、
> アプリ内でアカウントA/B/Cを保存して切り替えられる
という機能には専用NIPなんて必要ない。
したがってここは、
NIPで判定できないUI/実装機能
というカテゴリを作った方がいい。
たとえば、
複数アカウント
判定方式: 実装観測
NIPによる直接的な規定: なし
関連NIP: NIP-46
とする。
これめちゃくちゃ重要。
Nosmapsが将来的に本物のデータベースになるなら、
「NIP対応状況」と「ユーザー向け機能」を別テーブルにする
のがいい。
---
4. 「検索」はNIP-50を入れないとかなりまずい
現在：
{id:'search', ..., nips:['01','19','21']}
だけど公式に、
> NIP-50: Search Capability
が存在する。
これは一番分かりやすい修正ポイント。
01 → 基本プロトコル
19 → bech32識別子
21 → nostr: URI
なので、「検索」の技術的裏付けと言われるとかなり違和感がある。
---
5. DMもNIP-17が抜けている
現在のNIPカタログ自体に17が入っていない。
一方、現在の公式仕様では
NIP-17 = Private Direct Messages
で、旧NIP-04は非推奨。
なので、
DM
NIP-17
├ NIP-44 Encrypted Payloads
└ NIP-59 Gift Wrap
あたりを表示できると、むしろNosmapsの「NIP裏付け」という特徴がかなり生きる。
---
6. 「チャンネル」が特に危険
現状：
nips: ['01','42','78']
NIP-42は
> Authentication of clients to relays
NIP-78は
> Application-specific data
なので、チャンネル・コミュニティ機能の直接的根拠ではない。
しかもNostrでは今、
NIP-29 Relay-based Groups
NIP-C7 Chats
NIP-7D Forum Threads
NIP-A4 Public Messages
など用途が分かれてきている。
だから「チャンネル」という1項目にまとめるより、
グループ チャット フォーラム 公開メッセージ
くらいに分けた方が現代Nostrには合ってる。
---
7. NIPカタログが意図的とはいえ少なすぎる
今収録されているのは、
01 / 02 / 05 / 09 / 11 / 19 / 21 / 23 / 25 / 42 / 44 / 46 / 47 / 57 / 65 / 78
の16件。READMEにも明記されている。
ただ2026年8月現在の公式NIPsはかなり増えていて、機能探索サイトとして重要そうな
10, 17, 18, 22, 29, 50, 51, 53, 55, 59, 60, 61, 66, 68, 71, 89, 92, 94, B0, B7, C7
などがない。
特に
17 DM
50 Search
55 Android Signer
68 Picture
71 Video
B7 Blossom
C7 Chats
あたりはNosmapsの用途からすると優先度高い。
---
8. 「OSS判定」が雑
コードは、
function isOss(tool) {
return !tool.license.startsWith('不明');
}
となっている。
つまり、
ライセンスが「不明」じゃない = OSS
としている。
将来実データ化すると、
Proprietary
Commercial
Freeware
Source-available
などを入れた瞬間壊れる。
データに
openSource: true | false | null
license: "MIT"
を別々に持たせるべき。
---
9. 「オフライン：端末キャッシュ済みデータ」は表現がやや紛らわしい
HTMLには、
> オフライン：端末キャッシュ済みデータを表示しています。
とある。
ただJS側にはService WorkerやlocalStorage等の実際のキャッシュ機構は見当たらず、READMEでもこれはUI STATE LABの表示確認用とされている。
なのでユーザー向けなら、
> オフライン表示のUIプレビューです
くらいの方が誤解しない。
今の文章だと「Nosmapsにはオフラインキャッシュ機能が実装済み」に見える。
---
一番直すべき構造
たぶんこれにすると化ける。
機能
├─ 投稿・返信
│ ├─ 判定: 実装観測
│ ├─ 中核NIP: 10 / 22
│ └─ 関連NIP: 09 / 18 / 25
│
├─ DM
│ ├─ 中核NIP: 17
│ └─ 基盤NIP: 44 / 59
│
├─ 検索
│ ├─ 中核NIP: 50
│ └─ 関連NIP: 19 / 21
│
├─ 複数アカウント
│ ├─ 判定: 実装観測
│ └─ 関連NIP: 46
│
└─ 外部署名
├─ NIP-46
└─ Android: NIP-55
つまり、
「機能をNIPから機械的に生成する」のではなく、機能を独立した概念として持ち、その技術的裏付けとしてNIPを紐付ける。
これが一番大事。
そして今のREADMEには「NIPは技術的な根拠として辿れる」と書いてあるので、この方式の方がコンセプトにも合う。
査読結果
UI/アクセシビリティ設計：かなり良い
モックであることのREADME上の説明：良い
NIP一次資料の参照：良い
NIP名称そのもの：おおむね正確
機能↔NIP対応：要大幅修正
機能対応判定アルゴリズム：要修正
特に 「検索=NIP-50なし」「DM=NIP-17なし」「チャンネル=NIP-42/78」「最大値でfeatureSupport判定」 の4つは、正式公開前なら優先して直したいレベル。ここを直せば「単なるNostrアプリ一覧」じゃなくて、かなりちゃんとした機能→標準→実装の探索器になりそう。
