未ログインユーザーの場合、その人のサーバーに移動してから動作を行う導線を作る

[k0range]

Summary

現在のMisskeyでは、未ログイン状態でログインが必要な動作（リアクション・Playなどのノート共有・フォローなど）を行おうとするとログイン画面に移動されます。

ですが、その人は別のサーバーにすでに登録しているかもしれないので、その人が登録しているサーバーでノートの共有やリアクションなどを行えるようにするためにそのサーバーに移動してから動作を行うような機能を作ることを提案します。

例:

• ノートにリアクションする → サーバーのドメイン名の入力を求めてから別サーバーでそのノートを開く
• Playのノート共有 → サーバーのドメイン名の入力を求めてから別サーバーで/shareを開く
• フォロー → サーバーのドメイン名の入力を求めてから別サーバーでそのユーザーを開く

例えば、Mastodonで未ログイン状態で他人のノートをお気に入り登録しようとするとこうなります：

Purpose

未ログインユーザーが別サーバーですでにアカウントを持っている場合があるため。

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request

[kakkokari-gtyih]

それぞれの動作を行うためのrouteを用意する必要がありそう

[samunohito]

「未ログインで見ているのサーバ」と「その人が登録しているサーバー」が連合しているか、連合していても該当ノートのコピーが届いているかも加味する必要がありそう？

[k0range]

単に同じパスのノートを開けばいいと思っていましたが、結構難しそうですね...（URL内のドメイン名を変えるだけじゃ同じノートは表示されなかった）

[k0range]

連合していても該当ノートのコピーが届いているかも加味する必要がありそう

（別サーバー側で）ノートのURLを照会したときと同じ動作になるようにできれば解決できそう？

[kakkokari-gtyih]

相手がMisskeyではない場合とても面倒くさそう

[samunohito]

「未ログインで見ているのサーバ」→これはMisskey前提で良いと思います
「その人が登録しているサーバー」→連合経由で相手がMisskeyの対応バージョン or それ以外が分かれば懸念はないと思います。未対応or分からなかったのであれば未対応である旨のメッセージ＆今まで通りのフローでいいんじゃないかなと

[tamaina]

Mastodonの仕組みを真似すればいいと思う（しそういうIssueはすごい昔に立ってる気がする

[tamaina]

それぞれの動作を行うためのrouteを用意する必要がありそう

ボタンの動作を未ログインかどうかで分ければいいんじゃね

[kakkokari-gtyih]

それぞれの動作を行うためのrouteを用意する必要がありそう

ボタンの動作を未ログインかどうかで分ければいいんじゃね

移動先のMisskeyでの動作を制御するための何かしらを用意する必要があるよね、ということ（移動元はログイン状態での出しわけでいいと思う）

[k0range]

移動先のMisskeyでの動作を制御するための何かしらを用意する必要があるよね、ということ

フロントエンド側に照会を行うページ(/lookup?)を用意すればほとんどは解決しそうな気がします

例えば

• ノートにリアクション → (移動先サーバーのドメイン)/lookup?q=(移動元サーバーのノートのURL)に移動
• フォロー → (移動先サーバーのドメイン)/lookup?q=(移動元サーバーのユーザーのID)に移動、など

[k0range]

「未ログイン状態でアカウント登録が必要な動作」をまとめたほうがいいかも

[okinjp]

Mastodonだと移動先サーバーのauthorize_interactionというパスにuriというクエリを渡すことでユーザーや投稿のページに誘導してます。
これに合わせて貰えるとMastodonサーバーともリモートフォローなどがうまく行くのでいいと思います。

うちのサーバーではNginxでauthorize_interactionのパスにPHP製のアプリを置いてこの挙動に対応しているので、そこのロジック部をgistに上げました。参考までにどうぞ。
Mastodon本来の挙動とは違い連合からPlayを含む照会できないリンクを/shareに飛ばすので概ねIssueのSummary通りの挙動になると思います。

https://gist.github.com/okinjp/886a219b83945043a233b8900ef2f344

動作例
https://mi.okin-jp.net/notes/9oil8al4ke

[LeviSnoot]

Adding to the voices here, I'd be very stoked to see something like this for Misskey! I'm not sure if it was mentioned in this thread, but I think it would also be good if we added a cookie so the remote user doesn't have to fill in their username and instance on every interaction.

As for implementation, there is a project called AP Follow which could be helpful to implementing this feature.

(Apologies for the english, but I won't be machine translating my comments per the contribution guidelines)

[k0range]

I think it would also be good if we added a cookie so the remote user doesn't have to fill in their username and instance on every interaction.（リモート ユーザーがインタラクションのたびにユーザー名とインスタンスを入力する必要がないように、Cookieを追加することも良いと思います。）

I see, I think it's good. Instead of Cookie, LocalStorage may be fine.
なるほど、良いと思います。CookieではなくLocalStorageでも良いかもしれません。

[syuilo]

Misskey Hubに中継させるので良いんじゃないかしら

[kakkokari-gtyih]

Misskey Hubに中継させるので良いんじゃないかしら

（Misskey Hubなら、https://misskey-hub.net/mi-web/?path=/foo とやれば /foo に飛べるディープリンクを作れる）

[k0range]

Misskey Hubに中継リンク機能があるのは知りませんでした。
たしかにMisskey Hubの機能で済むならそれが一番良い気がします。

[futchitwo]

out of scope? かもしれないけど、ログイン状態でも他のサーバーでユーザーやノートを開きたい場合はあると思うので、ログイン時のノートメニューとかにも動線はあるといいと思います

[KisaragiEffective]

確かにプレイを他のサーバーでノートできると少し便利

off-topic: 将来の拡張

インスタンスの絵文字を引っ張ってくるタイプのPlayを他のサーバーでノートできるようにしてもありがたみが薄いのでPlay側に対して他のサーバーでノートできないようなオプションを作るべきかもしれない