ActivityPub: _misskey_contentがない投稿にはHTMLとしての処理だけを行うべき #15217

WinLinux1028 · 2025-01-06T02:13:17Z

💡 Summary

contentはmediaTypeに従って処理され, mediaTypeは存在しない場合はHTMLとして処理されなければなりません.
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-content

しかし, MisskeyはHTMLとして処理した後, さらにMarkdownとして処理されているように思います.

🥰 Expected Behavior

HTMLとして処理される

この投稿のActivityPub上での表現はcontent: "> これは引用として解釈されてはいけない"となっており, mediaTypeは存在しないことからHTMLとして処理されなければなりません.

🤬 Actual Behavior

Markdownとして処理されてしまう

📝 Steps to Reproduce

上記の投稿を作成した方法を記述します.

Mastodon glitch-socを使用します.
この実装は投稿時に以下のように入力形式を選択できます.
選択した形式に応じてそれをHTMLに変換する処理が行われるため, どれを選択してもActivityPub上ではHTMLとして見えます.
投稿の形式をプレーンテキストにし, Markdownとしても解釈出来そうな文字列を投稿します.
Misskeyから該当の投稿を見ると, このバグが発生します.

💻 Frontend Environment

* Model and OS of the device(s): 自作PC, CachyOS
* Browser: Firefox 134.0b10
* Server URL: https://misskey.io/
* Misskey: 2024.5.0-io.5d

🛰 Backend Environment (for server admin)

* Installation Method or Hosting Service:
* Misskey:
* Node:
* PostgreSQL:
* Redis:
* OS and Architecture:

Do you want to address this bug yourself?

Yes, I will patch the bug myself and send a pull request

The text was updated successfully, but these errors were encountered:

kozakura913 · 2025-01-06T02:22:29Z

misskey 2024.11.0でも同様

catsmiry · 2025-01-06T02:31:55Z

こちらでは
約3年前のバージョン
12.119.2でも再現できましたので
おそらく昔からあるバグだと考えます。

syuilo · 2025-01-06T02:52:24Z

MFMはaaa **bbb** ccc という文字列があったら bbb の部分を太字にして表示してあげたら便利だよね、といった発想から実装されているものなので、これはバグではなく、意図した挙動(MFMとして解釈できる構文があれば、元のテキストのフォーマットがなんであるかに関わらずMFM（Markdown）として解釈する)になります。

samunohito · 2025-01-06T02:56:04Z

misskey/packages/backend/src/core/activitypub/models/ApNoteService.ts

Lines 188 to 196 in 5f67520

    
           // テキストのパース 
        
           let text: string | null = null; 
        
           if (note.source?.mediaType === 'text/x.misskeymarkdown' && typeof note.source.content === 'string') { 
        
           	text = note.source.content; 
        
           } else if (typeof note._misskey_content !== 'undefined') { 
        
           	text = note._misskey_content; 
        
           } else if (typeof note.content === 'string') { 
        
           	text = this.apMfmService.htmlToMfm(note.content, note.tag); 
        
           }

上記の実装を見る限り、HTMLとして解釈されたものがMFMの構文に偶然当てはまり、文字列の装飾もそれに従った形になったと推測できます。

WinLinux1028 · 2025-01-06T03:05:23Z

MFMはaaa **bbb** ccc という文字列があったら bbb の部分を太字にして表示してあげたら便利だよね、といった発想から実装されているものなので、これはバグではなく、意図した挙動(MFMとして解釈できる構文があれば、元のテキストのフォーマットがなんであるかに関わらずMFM（Markdown）として解釈する)になります。

>< という顔文字が引用と誤解されてしまうように, 便利どころか害となることがあります.
そもそも便利だとしても仕様に明確に反するのはいかがなものかと...

syuilo · 2025-01-06T03:12:10Z

>< という顔文字が引用と誤解されてしまう

><に関しては引用として解釈されるのはバグですね

仕様に明確に反する

あるテキストをどのような見た目で表示するかというのは表示者に委ねられているはず（HTMLを表示する際は絶対にこのフォントでなければならない、などと決まっていないのと同様）で、仕様に反しているわけではありません。MFMは表示者による表示方法の一種です。

syobocat · 2025-01-06T03:13:16Z

~~><ではなく> <ですね~~

(あ、空白なくても引用になるんだ)

syuilo · 2025-01-06T03:13:41Z

> <に関しても、引用扱いになるのは意図していないですね

WinLinux1028 · 2025-01-06T03:14:03Z

><ではなく> <ですね

まぁどちらでもこのバグは発生します

WinLinux1028 · 2025-01-06T03:19:19Z

>< という顔文字が引用と誤解されてしまう

><に関しては引用として解釈されるのはバグですね

仕様に明確に反する

あるテキストをどのような見た目で表示するかというのは表示者に委ねられているはず（HTMLを表示する際は絶対にこのフォントでなければならない、などと決まっていないのと同様）で、仕様に反しているわけではありません。MFMは表示者による表示方法の一種です。

仕様では, MarkdownとしてではなくHTMLとして解釈することと決められています.
Markdownとして解釈していること自体が仕様に明確に反します.

syuilo · 2025-01-06T03:23:18Z

「HTMLとして解釈」はしています。ただ、それをどのような見た目でディスプレイにレンダリングするかは表示者の自由なはずです。

例えば、コードの->というテキストを→であるとして解釈し、そのように表示するフォントが存在したりしますが、それは何かの仕様に反しているわけではありません。

他にも、プレーンテキストのURLをハイパーリンクとして扱う、という表示もいろいろなところで見られますが、これも何かに反しているわけではないと思います。

syobocat · 2025-01-06T03:23:18Z

(仕様を見る限り「デフォルトではHTML」とはあるけどそれをHTMLとして受けなければいけないとは書いていない気がする)

(そもそも一度HTMLとして処理しているのでその後は別に何してもいい気がする)

syuilo · 2025-01-06T03:28:37Z

仕様に反しているかどうかや、MFMとして表示するべき/しないべきというのは置いておいて、具体的にどのように困っているか(先ほどの><の話のように)を挙げてそれに対する解決策を考えるのが良さそうに思います

Sayamame-beans · 2025-01-06T03:30:35Z

なお、><についてはMFM自体の仕様が多分そうなってるはずなので、APというよりMFMの話になると思います。(MFMでは>の後に空白が無くても引用になるようになっていたと思います)

syobocat · 2025-01-06T03:33:09Z

><以外だとこういう事例(元投稿)がありますね

あとこれは狙って作ったものなので偶然で発生することはほぼないと思われますがこれ(元投稿)とかこれ(元投稿)とか

noellabo · 2025-01-06T03:33:58Z

MastodonのようにMFMを意図していないリモートサーバからの投稿をMisskey側がMFMとして解釈するのは『便利』ではないし過剰で困るので、困る例としてはMFM全部かな。

samunohito · 2025-01-06T03:41:12Z

MastodonのようにMFMを意図していないリモートサーバからの投稿

（自分が知る限りですが）
現状これを判断する方法はないので、対策は困難に思えます。

sakuhanight · 2025-01-06T03:55:40Z

仕様という言葉が幾度となく出ていますが、Misskey(frontend)はMFMで表示する仕様です。
MFMにバグがあるという話であれば対処のしようがあると思いますが、MFMを使いたくないということであればMisskey以外を使うべきだと思います。

noellabo · 2025-01-06T03:56:26Z

Misskeyはノートを連合する際に、HTMLでレンダリングしたcontentに加えて_misskey_contentとsourceがついてきて、sourceにはmediaType: text/x.misskeymarkdownなどタイプも明示されています。

WinLinux1028 · 2025-01-06T03:56:50Z

仕様という言葉が幾度となく出ていますが、Misskey(frontend)はMFMで表示する仕様です。 MFMにバグがあるという話であれば対処のしようがあると思いますが、MFMを使いたくないということであればMisskey以外を使うべきだと思います。

｢仕様｣というのはActivityPubの仕様のことです

Sayamame-beans · 2025-01-06T04:02:20Z

仕様という言葉が幾度となく出ていますが、Misskey(frontend)はMFMで表示する仕様です。 MFMにバグがあるという話であれば対処のしようがあると思いますが、MFMを使いたくないということであればMisskey以外を使うべきだと思います。

｢仕様｣というのはActivityPubの仕様のことです

現状、MisskeyはActivityPubで受け取った投稿をそのように処理する仕様だ、ということです。
(noellabo氏の情報を元にMisskey系の投稿にだけMFMを掛けるような仕様変更は可能かもしれませんが、MisskeyだけがMFM入り投稿を送ってくるとも限らないでしょうし、議論が必要そうです)

sakuhanight · 2025-01-06T04:05:16Z

ActivityPubの仕様のこと

ActivityPubの仕様ではJSON内のcontentフィールドの値がHTMLであるというだけで、その表示についてはフロントエンドの実装に依ると考えます。
本Issueにおいて指摘頂いているのはMisskeyにおける表示であって、ActivityPubのJSONとは関係がありません。
（また、この仕様には則っていると考えます。）

「〜を〜のように表示してほしい」のようなMFMに対するIssueであれば理解ができますが、これ以上ActivityPubの仕様を持ち出されても議論として成立しないと考えます。

syuilo · 2025-01-06T04:06:38Z

「MFMすべて」となるとメンションやハッシュタグ、リンクも無効になってしまいますね

無論、送られてきたHTMLをそのままレンダリングするようなことは当然セキュリティ上不可能なので、必ず何かしらのMFM的解釈はせざるを得ないと思われます。

WinLinux1028 · 2025-01-06T04:07:46Z

ActivityPubの仕様のこと

ActivityPubの仕様ではJSON内のcontentフィールドの値がHTMLであるというだけで、その表示についてはフロントエンドの実装に依ると考えます。本Issueにおいて指摘頂いているのはMisskeyにおける表示であって、ActivityPubのJSONとは関係がありません。（また、この仕様には則っていると考えます。）

「〜を〜のように表示してほしい」のようなMFMに対するIssueであれば理解ができますが、これ以上ActivityPubの仕様を持ち出されても議論として成立しないと考えます。

まぁ, かなり天邪鬼な解釈をすればActivityPubの仕様には従ってるとは言えそうですが, 事実これが誤爆を起こしてるので...

noellabo · 2025-01-06T21:38:35Z

下記内容のMastodonの投稿を、SNSの投稿の解釈として適切な範囲でMFM適用し、予想外の装飾的な解釈を行わないよう対応した実装を実装してみました。

> abc
>abc
>>nest

MFM 書き方 検索

```js
abc
```

\[a = 1\]

***big!***

bold
**bold**
__bold__

italic
*italic*
_italic_

strike
~~strike~~

`$abc <- 1`

\(y = 2x\)

[@[email protected]](https://fedibird.com/@noellabo) 
[#test](https://nightly.fedibird.com/tags/test) 
https://github.com/misskey-dev/mfm.js/blob/develop/docs/syntax.md


[Misskey.io](https://misskey.io/)
?[Misskey.io](https://misskey.io/)

:thinking_ai: 

$[shake 🍮]

😇

abc

misskey.ioでの表示（従来のMFMフル適用）

misskey.cloudでの表示（MFM非対応実装で期待される範囲のMFM適用 / 目標状態）

nightly.fedibird.comでの表示（オリジナル投稿）

この実装の為に必要なmfm.jsの変更については、mfm.jsの方にissueとpull requestをあげてあります。
misskey-dev/mfm.js#155
misskey-dev/mfm.js#156

Misskey側の修正については、mfm.jsの更新が適用されないとテストできませんが、現状のものをpull requestしておきますのでご確認ください。
#15222

noellabo · 2025-01-06T21:42:16Z

現状、本文中にプレーンテキストで書いたつもりのHTMLタグについてHTMLとして解釈されていますが、これはmfm.jsに渡す前に、Misskey側の前処理でエスケープしておく必要がありそうです。

rinsuki · 2025-01-07T00:24:35Z

現状、本文中にプレーンテキストで書いたつもりのHTMLタグについてHTMLとして解釈されていますが、これはmfm.jsに渡す前に、Misskey側の前処理でエスケープしておく必要がありそうです。

それを行うのだったらそもそも Misskey 側で全部エスケープする……というか MFM の AST を Misskey 側で組んで、ASTからテキスト表現にmfm.jsで変換する際にエスケープを考慮してもらうほうが筋が良いと思います (というのが #15217 (comment) と misskey-dev/mfm.js#154 です)

rinsuki · 2025-01-07T00:27:49Z

そもそもの問題は(実装当時はどうだったかわかりませんが現在は) AST が存在する複雑なプレーンテキスト文法において、AST を使わずに文字列処理だけで複雑なものを生成している部分にあり、私の案なら雑多な案を解決できると考えています。

mfm.js に新しくパースモードを追加するのは、(本当に来るのかはともかく) https://github.com/misskey-dev/mfm.rs や https://github.com/shiosyakeyakini-info/dart_mfm_parser などのサードパーティにも同様の実装が必要になるため、好ましい選択ではないと思います。

sakuhanight · 2025-01-07T04:29:53Z

@noellabo 確認ですが、あなたの主張は「Misskey外はすべてプレーンテキストにすべき」ですか？
つまりHTMLのタグを一切解釈しないようにするということですか？

anatawa12 · 2025-01-07T04:31:01Z

MFMには<plain>があるしそれで囲むようにバックエンドをいじるじゃだめなのかな

追記: もちろん</plain>がテキスト内にあると壊れるのはそうなのですが今よりは著しくマシな動作になるはず

samunohito · 2025-01-07T04:37:17Z

MFMにはがあるしそれで囲むようにバックエンドをいじるじゃだめなのかな

URLをリンク化するなども出来なくなるので（試した）、デメリットが大きそうです。

anatawa12 · 2025-01-07T04:40:03Z

Pの中の URL のリンク化も HTML として素直に解釈した結果としては行われないのが正しそう。ちゃんとリンクを想定してるなら<a href="URL">URL</a>として流れてくるべきなので。(実際流れてくる)
メンションも同様

sakuhanight · 2025-01-07T04:40:21Z

そもそもpreタグを付ければプレーンテキスト(codeblockで表示)として扱われます。
pタグは段落を表すものであり、少なくともMisskeyの実装としてはエスケープではないとされています。

sakuhanight · 2025-01-07T04:43:04Z

何も装飾してほしくないのか、適切に処理してほしいのかでアプローチが真逆になります。
まずこの点だけ整理したいです。

rinsuki · 2025-01-07T04:48:39Z

私の場合は、タイトルが

ActivityPub: _misskey_contentがない投稿にはHTMLとしての処理だけを行うべき

であるので、HTMLとして装飾したものはMFMで(できる範囲で)再現、HTML上のテキストノードは(MFMとしてパースしうる文字列が含まれていても)そのまま表示してほしい、と解釈しました。

例を出すと、次のようなHTMLがActivityPubで来た場合:

<strong>HTML上の太字です</strong> ~~なんか取り消し線っぽいけど別に取り消し線を引いてほしいわけではない文章~~

現状のMisskeyだと:

HTML上の太字です ~~なんか取り消し線っぽいけど別に取り消し線を引いてほしいわけではない文章~~

のような表示になると思いますが、これを

HTML上の太字です ~~なんか取り消し線っぽいけど別に取り消し線を引いてほしいわけではない文章~~

のように表示してほしいという解釈ですが、いかがでしょうか。 @WinLinux1028

WinLinux1028 · 2025-01-07T04:56:24Z

私の場合は、タイトルが

ActivityPub: _misskey_contentがない投稿にはHTMLとしての処理だけを行うべき

であるので、HTMLとして装飾したものはMFMで(できる範囲で)再現、HTML上のテキストノードは(MFMとしてパースしうる文字列が含まれていても)そのまま表示してほしい、と解釈しました。

例を出すと、次のようなHTMLがActivityPubで来た場合:

HTML上の太字です ~~なんか取り消し線っぽいけど別に取り消し線を引いてほしいわけではない文章~~

現状のMisskeyだと:

HTML上の太字です ~~なんか取り消し線っぽいけど別に取り消し線を引いてほしいわけではない文章~~

のような表示になると思いますが、これを

HTML上の太字です ~~なんか取り消し線っぽいけど別に取り消し線を引いてほしいわけではない文章~~

のように表示してほしいという解釈ですが、いかがでしょうか。 @WinLinux1028

その解釈で大丈夫です👍

noellabo · 2025-01-07T04:59:47Z

@noellabo 確認ですが、あなたの主張は「Misskey外はすべてプレーンテキストにすべき」ですか？つまりHTMLのタグを一切解釈しないようにするということですか？

contentはHTMLで装飾されていますので、HTMLタグはもちろん（安全面やデザイン面から許せる範囲で）生かします。

MFM未対応環境の実装を利用している投稿者が本文中に書いたHTMLタグは、HTMLタグとしての解釈を意図したものではなく、単にHTMLタグの説明などを行うために記載したものです。ついては、これをHTMLタグとして解釈する~~変換する~~のは意図に反するということです。

これ、これからみてみるけど、mfm.jsに食わせる前の前処理で<とか元に戻しちゃってるんじゃないかな？

sakuhanight · 2025-01-07T05:00:33Z

そもそもpreタグを付ければプレーンテキスト(codeblockで表示)として扱われます。

これは私の勘違いで、正しくはpre codeの場合でした。
なので、これをpreが付いてるならplainにするとかするところから始めるのがよいと思います。
また、pタグの扱いについても、現在は改行だけなので、これをどのようにしたいかという議論がよいと思います。

rinsuki · 2025-01-07T05:03:55Z

@sakuhanight あなたがなぜ  タグに執着しているのかはわかりませんが、最初の例示でpタグが使われていることが原因であれば、それは Mastodon が改行なしにプレーンテキストを投稿すると自動で  で囲んでくる、そしてMastodonがレンダリングしたActivityPub上の表現をそのまま例示として出した、以外の意味はないと思います。

sakuhanight · 2025-01-07T05:06:40Z

mfm.jsに食わせる前の前処理で<とか元に戻しちゃってるんじゃないかな？

はい、APで受け取ったものをHTML→MFMにする処理があります。
その処理の中を適切になるように変えていけるとよいのかな？と思います。

sakuhanight · 2025-01-07T05:08:35Z

@rinsuki

タグに執着

別に執着していません。例示がpであるため、それについて言及しているだけです。
あとMastodonの仕様については知りません。

noellabo · 2025-01-07T06:05:22Z

ちょっと話がそれるけど、issueタイトルにも関わるので。

現行のMisskey、導入経緯とかあると思うんだけど、sourceの方が優先になってるよね？ _misskey_contentよりも。sourceにはコンテントタイプもついてるし。

逆に、他実装からMFMを意図してActivityPubでMisskeyに伝えたい場合、最大限HTMLで再現した互換用のcontentと共に、sourceにtext/x.misskeymarkdown形式で生データを入れるのがベターかな？たぶん旧Misskeyやそのフォークなどで_misskey_contentしか受け付けないなどの理由でこっちもつけとかないといけないんだろうけど。

noellabo · 2025-01-13T06:13:54Z

Misskeyの現行の基本方針が

MFMとして解釈できる構文があれば、元のテキストのフォーマットがなんであるかに関わらずMFM（Markdown）として解釈する

であるということでしたので、あらためて仕様を再検討できるよう、材料をまとめてみました。ベースにして議論していただければ幸いです。

引用ブロック

電子メールなどで多用される行頭からの > 記号を、慣例に従い引用構文として解釈することは、投稿者の環境において解釈されていない場合においても意図に沿っており、利用者の閲覧性を高めると考えられる。

他方、引用を意図していない記号表現（下記の例など）を引用構文として解釈することで、投稿者の意図に反し、コミュニケーションを阻害することがある。

><
> <

提案

引用ブロックと解釈する利便性が高い一方で、問題になるケースは少ないように思われる。
一部の表現を除外する対応をとる場合は、パターンを抽出しておきたい。

発生頻度の低いエッジケースとして、対応しない（すべて引用ブロックとして解釈する）
引用として解釈しない
引用として解釈しない除外パターンを導入

HTMLタグ

HTMLタグを説明するために書かれたプレーンテキストの文章をHTMLとして解釈することで、投稿者の意図が失われ、コミュニケーションを阻害することがある。

<b>Bold</b>のように<b>で囲うことで太字になります。
<i>Italic</i>のように<i>で囲うことで斜体になります。
<s>Strike</s>のように<s>で囲うことで打ち消しになります。
<small>Small</small>のように<small>で囲うことで目立たない字になります。
<center>Center</center>のように<center>で囲うことで中央揃えのブロックになります。

<s>を装飾意図でHTMLタグ表記していることは稀で、ほとんどのケースで投稿者の意図しない解釈になっていると思われる。利便性を高めるケースが見当たらない。

<center>はMFMにおいて代替表現がないため、実際にHTMLタグの効果を期待している場合はありうる。

提案

HTMLタグとして解釈しない
small, center以外、HTMLタグとして解釈しない

<s>はHTMLタグではない記号で囲うMarkdown（* や _ など）で代替可能であるため、MFMから将来的に削除（Deprecated）しても良いかもしれない。

アンカーになっていないリンク可能な要素（メンション、ハッシュタグ、URL）

メンション、ハッシュタグ、URLなど、リンクできる要素として解釈可能な要素のうち、アンカーになっていないもの。利便性を高めることもあるが、そもそも理由があってアンカーを外されている可能性があり、有効にすることで問題が生じる可能性がある。

アンカーをわざと外す例：

サスペンドされたアカウント、禁止したハッシュタグなど、対象が無効な場合
IPアドレス・ローカルホスト、無効なTLDなど、URLがアンカーとして不適切な場合

また、表現力の高いネイティブ表記の互換表現としてHTML化されたcontentの場合、投稿者が意図的にアンカーにならない記法を用いている結果である。

有効であるべきメンション、ハッシュタグ、URLは既にアンカーになっていることが期待できる。

@[email protected]
#misskey
https://github.com/misskey-dev/mfm.js/blob/develop/docs/syntax.md

提案

アンカーとして再解釈する（有効性・有害性はこちらで判断する）
アンカーとして再解釈しない

数式（ブロック・インライン）

説明目的で記載されることもあるが、無意識に用いられることが想定されない表記法で、解釈しても実害はなさそう（要検証）

\[
  a = 1
\]

\(y = 2x\)

Markdown記法（太字、斜体、打ち消し、リンク記法、インラインコード、コードブロック）

Markdown記法を説明するために書かれたプレーンテキストの文章をMarkdownとして解釈することで、投稿者の意図が失われ、コミュニケーションを阻害することがある。

また、Markdown表記などネイティブなリッチ表現が可能な実装では、ActivityPubのcontentのHTMLは変換済みの互換表現であるため、HTML化されてない表現に変換すると意図に反した表現になる。

他方、リッチ表現ができない実装において、投稿者がMarkdown解釈可能な実装で解釈・表示されることを期待し、あえてプレーンテキスト環境でMarkdown記法を用いて表現することがある。この場合、解釈されれば有益で便利である。

***big!***
**bold**
__bold__
*italic*
_italic_
~~strike~~

[Misskey.io](https://misskey.io/)
?[Misskey.io](https://misskey.io/)

`$abc <- 1`

```js
abc
```

提案

Markdown記法として解釈する
Markdown記法として解釈しない

Sayamame-beans · 2025-01-13T06:22:11Z

<s>を装飾意図でHTMLタグ表記していることは稀で、ほとんどのケースで投稿者の意図しない解釈になっていると思われる。利便性を高めるケースが見当たらない。

現行Misskeyのフロントエンドでは、これらを用いた場合はbold/italic/strikeが適用されるようになっています。(掛けないようにするにはplainが必要)
small等も同様で、ユーザーはこれらを利用することがあります。

なお、bはともかく、iについては日本語等がある場合に利用され得ると考えます。_では日本語を含む場合にitalic化されません(もしかしてバグだったのでしょうか?)

noellabo · 2025-01-13T06:27:58Z

このまとめは全て、_misskey_contentがない投稿のcontentを対象とした記述ですので、Misskeyフロントエンドからの利用方法は除外してあります。

MFMがネイティブの環境では、利用ケースがあるのは当然のことと思います。

イタリックが日本語に適用されないことがあるのは、ブラウザ実装の問題だったと思います。

Sayamame-beans · 2025-01-13T06:30:45Z

なるほど
(italicについては、_italic with 日本語_のようにすると、全文italic化されず_もそのまま表示される挙動をします。iタグでは少なくとも英文部分には掛かるのではないかと思います(環境によっては日本語も))

noellabo · 2025-01-13T06:30:54Z

ところで、私の方でひとつプルリクエストしましたが、HTMLタグをエスケープする実装をつめていたら、結局はmfm.jsは変更せずすべてエスケープするだけのシンプルな実装になりました。ついては、 @anatawa12 さんの実装をベースに進めれば良さそうですので、私の方は閉じておきます。
fedibird@e9ac22d

anatawa12 · 2025-01-14T00:57:10Z

noellabo さんのメッセージは"提案"とありますが一つを提案するというよりは選択肢を示しているという認識で間違いないですかね。

引用ブロックの除外されるべき><などのパターンについては　HTML to MFM　とは独立して misskey 単体でも問題になり得る話だと思うので、独立した discussion を立てました。 #15275

WinLinux1028 · 2025-01-14T01:11:04Z

Misskey同士ならただユーザーがエスケープすればいいのではないでしょうか?
Misskeyユーザーは入力した文字列がMFMとして処理されることは想定しているはずです.

このIssueは, MFMに対応していないサーバーから送信された投稿がMFMとして処理されるということを投稿者は想定していないため, 投稿者の想定通りに表示されてほしいという意図で書きました.

syuilo · 2025-01-14T01:14:11Z

Misskeyユーザーは入力した文字列がMFMとして処理されることは想定しているはず

そこまで想定していないと思います。
MisskeyのUI的にも、「こういう形式のテキストを入力したらこうなりますよ」といった説明はしておらず、無意識的に使われる想定です。

noellabo · 2025-01-14T02:59:42Z

どの項目も考え方次第なので、皆さんに決めて頂けるよう、選択肢を示しました。

私個人としては、

引用ブロックはMFM適用（誤爆考慮）
HTMLタグは解釈しない
アンカーになっていないメンションやURLは解釈しない
数式はMFM適用
Markdown系はMFM適用

あたりのバランスがいいかなと思っています。

WinLinux1028 added the ⚠️bug? This might be a bug label Jan 6, 2025

github-project-automation bot added this to [実験中] 管理用 Jan 6, 2025

github-project-automation bot moved this to Todo in [実験中] 管理用 Jan 6, 2025

kakkokari-gtyih added the 🌌Federation The Federation/ActivityPub feature label Jan 6, 2025

samunohito added 🖍MFM The Misskey Flavored Markdown feature and removed 🌌Federation The Federation/ActivityPub feature labels Jan 6, 2025

noellabo mentioned this issue Jan 6, 2025

MFMかどうかを_misskey_contentで分岐して判断するように #15222

Closed

5 tasks

anatawa12 self-assigned this Jan 9, 2025

anatawa12 linked a pull request Jan 9, 2025 that will close this issue

HTML内のMFMっぽい部分を<plain>でエスケープするように #15241

Open

5 tasks

ActivityPub: _misskey_contentがない投稿にはHTMLとしての処理だけを行うべき #15217

ActivityPub: _misskey_contentがない投稿にはHTMLとしての処理だけを行うべき #15217

Comments

WinLinux1028 commented Jan 6, 2025

💡 Summary

🥰 Expected Behavior

🤬 Actual Behavior

📝 Steps to Reproduce

💻 Frontend Environment

🛰 Backend Environment (for server admin)

Do you want to address this bug yourself?

kozakura913 commented Jan 6, 2025

catsmiry commented Jan 6, 2025 • edited Loading

syuilo commented Jan 6, 2025 • edited Loading

samunohito commented Jan 6, 2025

WinLinux1028 commented Jan 6, 2025 • edited Loading

syuilo commented Jan 6, 2025

syobocat commented Jan 6, 2025 • edited Loading

syuilo commented Jan 6, 2025

WinLinux1028 commented Jan 6, 2025

WinLinux1028 commented Jan 6, 2025 • edited Loading

syuilo commented Jan 6, 2025

syobocat commented Jan 6, 2025

syuilo commented Jan 6, 2025

Sayamame-beans commented Jan 6, 2025

syobocat commented Jan 6, 2025 • edited Loading

noellabo commented Jan 6, 2025

samunohito commented Jan 6, 2025

sakuhanight commented Jan 6, 2025

noellabo commented Jan 6, 2025

WinLinux1028 commented Jan 6, 2025

Sayamame-beans commented Jan 6, 2025

sakuhanight commented Jan 6, 2025 • edited Loading

syuilo commented Jan 6, 2025

WinLinux1028 commented Jan 6, 2025

noellabo commented Jan 6, 2025

noellabo commented Jan 6, 2025

rinsuki commented Jan 7, 2025

rinsuki commented Jan 7, 2025 • edited Loading

sakuhanight commented Jan 7, 2025

anatawa12 commented Jan 7, 2025 • edited Loading

samunohito commented Jan 7, 2025

anatawa12 commented Jan 7, 2025

sakuhanight commented Jan 7, 2025

sakuhanight commented Jan 7, 2025

rinsuki commented Jan 7, 2025 • edited Loading

WinLinux1028 commented Jan 7, 2025

noellabo commented Jan 7, 2025 • edited Loading

sakuhanight commented Jan 7, 2025 • edited Loading

rinsuki commented Jan 7, 2025

sakuhanight commented Jan 7, 2025 • edited Loading

sakuhanight commented Jan 7, 2025

noellabo commented Jan 7, 2025

noellabo commented Jan 13, 2025

引用ブロック

提案

HTMLタグ

提案

アンカーになっていないリンク可能な要素（メンション、ハッシュタグ、URL）

提案

数式（ブロック・インライン）

Markdown記法（太字、斜体、打ち消し、リンク記法、インラインコード、コードブロック）

提案

Sayamame-beans commented Jan 13, 2025 • edited Loading

noellabo commented Jan 13, 2025

Sayamame-beans commented Jan 13, 2025

noellabo commented Jan 13, 2025

anatawa12 commented Jan 14, 2025

WinLinux1028 commented Jan 14, 2025

syuilo commented Jan 14, 2025

noellabo commented Jan 14, 2025

catsmiry commented Jan 6, 2025 •

edited

Loading

syuilo commented Jan 6, 2025 •

edited

Loading

WinLinux1028 commented Jan 6, 2025 •

edited

Loading

syobocat commented Jan 6, 2025 •

edited

Loading

WinLinux1028 commented Jan 6, 2025 •

edited

Loading

syobocat commented Jan 6, 2025 •

edited

Loading

sakuhanight commented Jan 6, 2025 •

edited

Loading

rinsuki commented Jan 7, 2025 •

edited

Loading

anatawa12 commented Jan 7, 2025 •

edited

Loading

rinsuki commented Jan 7, 2025 •

edited

Loading

noellabo commented Jan 7, 2025 •

edited

Loading

sakuhanight commented Jan 7, 2025 •

edited

Loading

sakuhanight commented Jan 7, 2025 •

edited

Loading

Sayamame-beans commented Jan 13, 2025 •

edited

Loading