記事: ATP/BlueskyがMarkdownではなくRichTextを採用した理由

前回: 記事: ATP/BlueskyがP2Pではない理由 | GNU social JP Web。

前回紹介した際に、他に「Why not RDF in the AT Protocol? | Paul’s Dev Notes」「Why RichText facets in Bluesky | Paul’s Dev Notes」の2件の記事が公開されていたと書きました。どちらも大事な内容に感じたので遡って紹介することにします。

今回は2024-01-15の「Why RichText facets in Bluesky | Paul’s Dev Notes」が元記事です。

ATP/Blueskyでは、テキストの表現にRichTextを採用しています。このようなテキストの表現には、Markdownが広く採用されています。しかし、これには問題が3点あります。

1. 構文拡張時の互換性の問題。
2. 解析が最悪 (特に構文拡張時)。
3. 文字数カウント: 正確な文字数カウントのためにまず解析の排除が必要になり複雑でオーバーヘッドが生じます。

ATP/Blueskyでは上記問題に対応するため、テキスト本体と注釈を別データに分離しました。例えば以下のようです。

// slightly simplified
{
  text: "Hello @bob.com",
  facets: [
    {feature: "mention", index: {start: 6, end: 14}}
  ]
}

これにより、ファセットを理解できないクライアントは単にテキストが表示されます。また、文字数カウントも簡単です。仮にクライアント側でMarkdownを使いたい場合も、ファセットを解析・変換すればいいだけで済みます。

一見まどろこっしく見えますが、処理のオーバーヘッドの排除、複雑性の排除のためには一理あるのかもしれません。