Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

API を packages/frontend 用とサードパーティー用に分離する #10693

Open
acid-chicken opened this issue Apr 23, 2023 · 19 comments
Open

API を packages/frontend 用とサードパーティー用に分離する #10693

acid-chicken opened this issue Apr 23, 2023 · 19 comments
Labels
✨Feature This adds/improves/enhances a feature

Comments

@acid-chicken
Copy link
Member

acid-chicken commented Apr 23, 2023 •
edited
Loading

Summary
@acid-chicken acid-chicken added the ✨Feature This adds/improves/enhances a feature label Apr 23, 2023
@rinsuki
Copy link
Contributor

rinsuki commented Apr 23, 2023

そういうことやると往年のTwitterみたいに公式でしか使えない機能がどんどん増えそうでアレ (現状でもそもそもそんなサードパーティ気にしてないだろというのはまあ…)

@rinsuki
Copy link
Contributor

rinsuki commented Apr 23, 2023

というかmsgpack in/out やるならサードパーティでも使えた方が嬉しそう

@EbiseLutica
Copy link
Contributor

まあ現状既に何が第三者向けで、どれがフロントエンド向けか明らかじゃないまま、整備しているのかしていないのかわからない状態でなあなあにしているので、はっきり分けてしまうのはありだと思ってる

メンテナンスコストは増えるので、負担を減らす形で実装できたら良いのだけれど

@acid-chicken
Copy link
Member Author

acid-chicken commented Apr 23, 2023 •
edited
Loading

というかmsgpack in/out やるならサードパーティでも使えた方が嬉しそう

msgpack ならそうかもだけどモチベ的にはスキームベースのを採用したいのでこうなった
今求められているのは安定性というか普遍性だから要望があったらまた考えれば良いかなという気持ち

@fruitriin
Copy link
Contributor

サードパーティアプリ開発者として、サードパーティ向けのAPIのサポートが手薄になりそうなのでそのあたりのスタンスによっては反対
今までのAPIも引き続き使えるけどv2 APIを追加みたいな形ならいいけど

@acid-chicken
Copy link
Member Author

モチベは述べたとおり普遍性なので既存の API はどの道当面の間残す以外考えていない

@EbiseLutica
Copy link
Contributor

開発者の中にはサードパーティAPIをヘビーに使っている私のような人もいるので、そこのサポートはしっかりしていきたい

@acid-chicken
Copy link
Member Author

Twitter API のケースと重ねられるけどあちらは OSS じゃない（すなわち誰かが改善したい意思があっても変更が容易ではない）という大きな違いがあることも念頭に置いて欲しい

@fruitriin
Copy link
Contributor

1st用APIと3rd用APIを分離という表現がたぶんあんまりよくなくて、GraphQLベースでアクセスできるAPIの追加とかなら受け入れられやすいと思う

@acid-chicken
Copy link
Member Author

既存のエンドポイントをすぐに撤去しないとはいえ、将来的に拡張を続けるとも限らないので（つまり保守モード）誤解を生ませる表現よりは適切と考える

@acid-chicken
Copy link
Member Author

（実際の所は #4635 を試してみて手触りが良くなかったら方針転換するかもしれない）

@pantasystem
Copy link

仮にサードパーティのことをターゲットに入れるのなら
Mastodon APIの互換性をもたせるほうが嬉しいのかなーって思っています
Mastodon API互換であれば既存のサービスも追従しやすいのと
すでにMastodon API互換を持たせたフォークはいくつがあるので実現の可能性は高いなと思っています

@acid-chicken
Copy link
Member Author

acid-chicken commented Apr 24, 2023 •
edited
Loading

Mastodon API に詳しい人によってメンテナンスされる必要があるのでメンバーに該当する人がいないと厳しい
でないと

そういうことやると往年のTwitterみたいに公式でしか使えない機能がどんどん増えそうでアレ

になる

@rinsuki
Copy link
Contributor

rinsuki commented Apr 24, 2023

Mastodon API と互換性が持てない機能がいくつかあるので完全な Mastodon API 互換は厳しい (e.g. 複数回Renote)、まあ機能限定でも選択肢の1つとして持っておくのはありだとは思う

@acid-chicken
Copy link
Member Author

このままいくと

  • 今のやつ
  • 1st
  • 3rd
  • Mastodon
  • Micropub

の五種類を取り扱うことになってしまいそう

@syuilo
Copy link
Member

syuilo commented Apr 24, 2023

Mastodon API持ったところでというのがあるしメンテナンスできないので要らないと思われる

@EbiseLutica
Copy link
Contributor

MisskeyはMastodonではないし、Mastodon APIはFediverseのデファクトスタンダードなAPIではないので、それに実装コストをかけるくらいならMicropubやActivityPubC2Sに費やすべきだと私も考えます

@rinsuki
Copy link
Contributor

rinsuki commented Apr 25, 2023

  • 正直言って Mastodon API は事実上 Fediverse の準デファクトくらいにはなっている気はする…
  • Micropub も今更 application/x-www-form-urlencoded ねえ感はちょっとある
  • ActivityPub C2S はアプリ側がつらすぎる (投稿するだけならいいかもしれない)

@acid-chicken
Copy link
Member Author

というか主題の 1st, 3rd の実装如何と互換 API の実装如何は相関しないので続きは #1280 #9523 #9457 か新規 Issue で

@acid-chicken acid-chicken mentioned this issue Jun 23, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
✨Feature This adds/improves/enhances a feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@syuilo @rinsuki @EbiseLutica @fruitriin @acid-chicken @pantasystem