魚拓リポストについての現状まとめと自身の考えを言語化しておこうのコーナー。あなたの考えも尊重します。石を投げないでください。
魚拓リポストって？
NIP-18 には引用・リポストについての仕様が書かれている。
The content of a repost event is the stringified JSON of the reposted note. It MAY also be empty, but that is not recommended.
リポストのcontentにはリポスト対象のJSONをまるっと埋め込むものとされている(しなくてもいいけど推奨しないよ、とも追記されている)
リポスト元が対象イベントを削除してもリポストされたイベントに埋め込まれたままのJSONが残っていれば完全に削除されないしリポストの署名者しか削除権限を持たないため望ましくないとしてこの仕様に反対する開発者も少なくない。
現状、海外製のクライアントは大半が魚拓リポストを実装しているのに対し、和製クライアントはcontentを空にしてリポストする実装が優勢である。^1
お前はどっち派？
筆者は魚拓リポスト反対派である。理由を言語化しておきたい。今後加筆・修正する可能性もある。
- イベントの署名者はイベントを削除できるのが当たり前である。それを真っ向から否定する仕様である。なくすべき。
- インターネットに放流したものは二度と元には戻せませんーｗｗｗみたいな話はインターネットレイヤーでやればよろしい。ActivityPubやAT ProtocolやTwitterも削除を実装していて同じことが言えるし言ってこい。
- NostrはSNSではない。テキストを通信するためのプロトコルだ。削除できないプロトコルなんてゴミでしかない。誰がそんなゴミプロトコルを使いたいのか。
- 「魚拓したい」シチュエーションはあり得る。相手の発言を咎めたい時。後から削除/修正されてしまってはその意図が反映されない。
- 「魚拓したい」という強い意思と覚悟があればすればよろしい。
- 魚拓するクライアントを実装したいという強い思想を持つなら作ればよろしい。
- そんな覚悟も持ち合わせていないでただフォロワーに見てもらいたいだけの人がリポストした際に、たまたま思想の強いクライアントを使っていてそんな覚悟と責任を負わされるのは不幸ではないだろうか。
- そんな思想の強いクライアントを使っている人の自己責任だーという批判を浴びること自体が不幸でしょ。
- それをNIPsという大元の仕様書で推奨するのは違うでしょ。
- クライアント開発者から見て、仕様として「美しい」かどうか。
- リポストは魚拓があって引用は魚拓が無い。
- 引用もリポストもリレーに問い合わせてイベントを持ってくるという共通の処理を行う。
- それで十分では？その後さらにリポストの場合だけイベントがリレーから取得できなかった場合をif文で分岐してcontentの中身をパースして復元する？？
- 共通の処理で済ませるのが美しいコードでは？
- そんな仕様無い方がよくね？
蛇足
こんなケースを想定してみる。 あなたの大好きな友人がした投稿をあなたがリポストした。 その投稿には友人の家の位置情報がうっかり埋め込まれていた。友人は急いでその投稿を削除した。 しかしあなたのリポストにはその投稿が埋め込まれていて消える気配がない。 あなたはその友人に対して「インターネットに放流したものは二度と元には戻せませんーｗｗｗ」って言うの？という話である。
プロトコルや仕様というのは使う人を幸せにするために存在するものだと筆者は考えている。 魚拓の有無はどちらも特定の人たちを幸せにする可能性があり、優劣は無い。 その仕様は誰を幸せにするためにあるのか。あなたがその人を幸せにしたいのであればその仕様を採用するのがいいと思うし、深く考えた上でそれを採用したのであれば筆者と異なる立場だとしても尊重したい。