entity.Statusやentity.UserのIDを整数から文字列に変更したい
Opened this issue · 2 comments
docs.joinmastodon.orgにおいて、これらの属性はStringと規定されているため。
今使っているmastodon4jは歴史的経緯というか、当時の暗黙の解釈として整数として扱っていた。
ただ、変えるとすると影響範囲がまるで読めない。Twitterではこれらの値は64bit整数だったので、Yukariでは昔からそのつもりで実装していたコードが多数あり、サービス抽象化後もそのままにして楽をしている節がある。
https://github.com/mastodon/documentation のcommit logを見る限り、当初より一貫して文字列ではあった。
mastodon/documentation@e48b116
ただ、現実のアプリケーション実装者としては文字列より整数であるほうが都合が良いこともあるため、Mastodonの実装が整数を返してくることに依存して整数としてパースしていることが多々あった。
(完全に偏見だけど「文字列として返すのはJSONの仕様上64bit整数を正確に表現できないからそうしているだけ、実際は整数であるのでそう扱えばいい」という解釈をしている人もいたんじゃないかな…… 私はそういう認識だった)
しかし、2019年1月頃にPleromaがMastodon互換のAPIエンドポイントから、整数としてストレートに解釈できないフォーマットを応答したことでトラブルとなり、喧嘩や議論が発生した。
https://mastodon.social/@tootapp/101483707041892818
https://mastodon.social/@WAHa_06x36/101483724759260289
簡潔に現状を文書化しようとしたら結局Revertになったり、別の表現で内容とソートについて言及されたり。
2023年10月現在ではガイドラインのページでこう書かれている。
Vanilla Mastodon entity IDs are generated as integers and cast to string. However, this does not mean that IDs are integers, nor should they be cast to integer! Doing so can lead to broken client apps due to integer overflow, so always treat IDs as strings.
https://docs.joinmastodon.org/api/guidelines/#id
「APIドキュメントの定義がそうなっているのだからその範囲内でどう変えてもいい」という主張自体は間違いではない。
問題があったとすれば、そのAPI体系を採用している大元のアプリケーションの実装とそれに従うサードパーティが既に存在する状況で、そこにフリーライドしているにも関わらず協調性を欠いた行動を取って、そもそも自分たちを見て作っていない人達に対して余計な火種を撒いたこと。
最初からもっと協力的に、実装上の事実に依存しないように周知するようなアプローチだって取れたのではないかと思うので。まあ、過ぎた事にそんな事言っても後知恵でしかないので、どうしようもない。
(これを受けて攻撃的な発言も出る中で何とか着地点を模索しようとしていた人々は努めて礼儀正しく振る舞おうとしていた。後知恵でケチを付けるより、まずは敬意を示すべきではある……)
ただ、現在はより良いドキュメントに落ち付いていても、そういう点ですれ違いが起きていたからこそ根に持っている人もいるので、この議論が起きるより前に実装していた人々やYukariの実装を1行目の論法で責めないでほしいな……と思う。