Mastodon Compatible APIの全面的な廃止

[tamaina]

Summary

コードの保守が大変そうだし、その割に実装時の利益が不明

Environment

[ghost]

ここに書くより https://github.com/syuilo/misskey/issues/1280 か https://github.com/syuilo/misskey/pull/3063 と統合したほうがいい気がする。趣旨には同情的です。

[ghost]

/api/v1/instance/peers は https://github.com/distsn/instances と https://fediverse.network で使われていて有益なので維持してほしい。参照: https://github.com/syuilo/misskey/pull/2913

[ghost]

マストドン互換 API を維持し続けるのは Pleroma が通った道で、わりと辛みがあります。マストドンが新機能を導入してから Pleroma が互換 API を実装するまでどうしてもタイムラグがあり、その期間は SubwayTooter の動作が中途半端になるなどの悩みがある。参照: https://mastodon.juggler.jp/users/tateisu/statuses/101109574416447278 https://mastodon.juggler.jp/users/tateisu/statuses/101109705809793330

[tateisu]

Pleromaに関してはM互換API自体は良い決断だったと思います。
・1.6.0互換を詐称したのにpin投稿を取得しようとしたら普通のトゥートを返してきた
・2.5.0互換を詐称したのにプッシュ購読APIがおかしな挙動をした
バージョン表記を1.0.0のままにしていたなら何も問題はなかったんや…。

インスタンス情報APIは外部サイトから参照されていてこれも有為だったと思います。廃止せずに残すべき。

ただ、次の段階としてエンティティをマストドン互換で表現するには大きな壁があると思います。
M互換APIでは各種エンティティのIDは64ビット(8byte)整数で表現されます。またトゥートのIDについてはそれはsnowflakeです。MisskeyではエンティティのIDはMongoDBのObjectID(12byte)で表現されます。
マストドンの方がIDのバイト数が少ないため、IDを単純に相互変換することは不可能です。よってマストドン互換API用にIDカラムを追加してインデクスを持つことになります。

また、ノート用のIDに関してはsnowflakeがないと「日時を意識してTLを取得する」ことができなくなります。

たとえば「ログインなしで公開TLを読む」だけでも

• ユーザにマストドン用の数値IDカラムを追加
• ノートにマストドン用の数値IDカラムを追加。Snowflake。
• ドライブのファイルにマストドン用の数値IDカラムを追加。

…という感じのDBスキーマ変更が入ります。

私はMisskeyのコントリビュータではないので廃止に関しては意見を持ちませんが、「大変だろうなあ…」という感想です。

[tamaina]

というか

仮に互換APIを実装したとしてもそれ以降常にMastodonに追従していかないといけなくなり保守が困難になりそうなので見送る

https://github.com/syuilo/misskey/issues/1280#issuecomment-405102844

としゅいろも言っているし、これがすべてを表現していると思う。「チャンネル」機能が保守が行き届かないために廃止された経緯もあるし。

さらに、既存の(Misskey非対応の)MastodonクライアントでMisskeyが利用できたところでリアクション、投票、引用RN、トークが利用できるわけではないので意味がない

/v1/instance以下ぐらいは残してもいいんじゃないかという意見もあるけれど、Misskeyにも似たような/metaや/instancesがあるので廃止しても問題はなさそう

[incognico]

But features like the custom emojis should be kept in my opinion.

[tamaina]

確かに、カスタム絵文字APIのような、Misskeyが直接的に利用しているAPIは残したいですね。Mastodon"由来の"APIと言うべきでしょうか。

[tateisu]

互換APIでMisskeyのフル機能を実現するのはそりゃ不可能だと思いますが、たとえば外部のトゥート検索サービスや記録サービスがMisskeyタンスの投稿もインデックスしてくれるとかあれば、個人的にはすごく良いと思います。「ログインなしで公開TLをマストドンのストリームAPIで読む」が出来るなら、対応してくれる検索サービスさんもあるのではないか…？

[tamaina]

投稿のストリームに関する機能はActivityPubを利用できるし、そのほうが後発のActivityPub実装に対しても有益そう

ローカルTLをActivityPubとして送出する機能は今のところないけれど…(リレーサーバーがあるのでできることにはできるのかしら？)

[tateisu]

現存するトゥート検索サービスは古いのばっかりなのです

[incognico]

I'm feeling ambiguous about this topic. Maybe there should be a basic compatibility layer to the mastodon api to what's possible without having to do complicated things between misskey and mastodon. only do the basic layer and cherry pick good features like the custom emoticons.

[tateisu]

@incognico

We are NOT discussing about datas exchanged via ActivityPub.

We are discussing about adding "Mastodon-compatible CLIENT API" that can be used from full-stack client or some external toot search / archive service.

for example:
Custom emoji was "imported" from Mastodon to Misskey.

• it has its own data schema and Misskey client API. (this is NOT compatible with Mastodon)
• it has common data representation on ActivityPub. (this is compatible with Mastodon)

[incognico]

Ah, thank you, I get it now. I'm new to this 😅

[tateisu]

ActivityPub「だけ」を利用してクライアントを書ける時代はまだまだ先だと思います。「サービスを問わずにActivityPub「だけ」を利用して得た投稿内容を適切に表示できる」は現状まだ厳しい感じです。

なのでMastodonにだけ対応してる外部サービスに公開TLを読ませることができれば便利にはなるでしょう。Mastodonの最新仕様を追いかける必要も特にありません。なぜなら外部サービス自体がそれに対応してないから…。

というわけで意義はそれなりに感じてるのですが、やっぱりハードルは高い印象があります。

[tamaina]

レガシーなものをバンバン切り捨てるMisskeyなのでまあそこらへんはサポートしなくてもいいかなと思う次第

ローカルTLをActivityPubとして送出する機能はまんま mei23#45 ですね

[tateisu]

mei23#45 は「捨てアカウントを作って特定アカウントをフォローするだけで大量の投稿を押し付け始める」という奴なのでAP的にはs2s枠であり、c2s枠ではありません。pushする先は外部タンスであって、クライアントとして動作する外部サービスではない。
・ローカルTLを「クライアントが」読める(pullまたは能動的なストリーミング開始)
・ローカルTLを「別タンスに」送出する（push)
は全然異なるものだと思います。

[tamaina]

mei23#45 は(APで実装している)トゥート検索サービス向けに有益ではないかという話ですね

MisskeyのローカルTLをMastodonのクライアントで読めたところでユーザーにどんな利益があるんだろう…？

[tateisu]

APでトゥート検索サービスを実装するとして、そのサービス自身はインスタンスではないのだからActivityPubのサーバではなくクライアントであるほうが自然です。そのクライアントがどうやって「フォロー」を行うのでしょう？

MisskeyのローカルTLをMastodonのクライアントで読めたところでユーザーにどんな利益があるんだろう…？

たとえばtootsearchやマストドン検索ポータルなどの「マストドンのクライアントAPIを使う外部サービス」では複数のタンスの公開TLを読んでインデクスすることで「複数タンスをまたいだ検索機能」を提供しています。

そしてマストドンは(Misskeyもですが)ActivityPubのクライアント向けAPIのサポートはほとんど行われていないため、ActivityPubのクライアントとして動作する外部検索サービスが登場することはしばらくないでしょう。

現在のActivityPubのクライアント向けAPIで書くサービスで実装されていると期待できるのは、大雑把に言ってユーザのアカウントTLの公開部分を読むこととフォロー・フォロワーを読むこと程度だと思います。タンスの公開TLを読めるActivityPubオブジェクトはありません。

まだ存在していないサービスの可能性を理由に既存サービスとの連携を切り捨てるという論旨には同意できる部分がありません。

[mei23]

compatibleじゃないのにcompatible名乗るのやめたい
https://github.com/syuilo/misskey/blob/6f1e47f0b339c80112af881a85e196fee04a1166/src/server/api/mastodon/index.ts#L52

[mei23]

compatibleじゃないのにcompatible名乗るのやめたい

実装するんじゃなくてcompatibleを消すことを意図してます