[Feature] Redirect remote user to internal ID #2188

Closed
hakabahitoyo wants to merge 16 commits from gitlab-mr-iid-921 into develop
Member

Resolve remote user's host name and user name into internal ID, and redirect to that.

  • /remote-users/:username@:hostname -> /users/:id
  • /remote-users/@:username@:hostname -> /users/:id
  • /remote-users/:hostname/:username -> /users/:id

Usecase

Some implementations of decentralized social network, such as Misskey, have no explicit remote follow feature on their standard web UI. In case of following from Pleroma (e. g. pleroma.example.com) to Misskey (e. g. exampleuser@misskey.io), first we can open the URL https://pleroma.example.com/remote-user/@exampleuser@misskey.io, redirected into https://pleroma.example.com/users/INTERNAL_ID, and we can push the follow button.

Resolve remote user's host name and user name into internal ID, and redirect to that. * `/remote-users/:username@:hostname` -> `/users/:id` * `/remote-users/@:username@:hostname` -> `/users/:id` * `/remote-users/:hostname/:username` -> `/users/:id` ### Usecase Some implementations of decentralized social network, such as Misskey, have no explicit remote follow feature on their standard web UI. In case of following from Pleroma (e. g. `pleroma.example.com`) to Misskey (e. g. `exampleuser@misskey.io`), first we can open the URL `https://pleroma.example.com/remote-user/@exampleuser@misskey.io`, redirected into `https://pleroma.example.com/users/INTERNAL_ID`, and we can push the *follow* button.
Author
Member

I believe that this MR is ready to merge.

I believe that this MR is ready to merge.
Member

Not sure why, you can just use user search to find remote user.

On top of that we shouldn't redirect internal users, and whole thing is buggy enough already, this will need intense testing before merge.

Not sure why, you can just use user search to find remote user. On top of that we shouldn't redirect internal users, and whole thing is buggy enough already, this will need intense testing before merge.
Member

I think this is a good idea, search can be fiddly sometimes. This doesn't seem to change how internal users work either.

I think this is a good idea, search can be fiddly sometimes. This doesn't seem to change how internal users work either.
Member

plz don't depend on qvitterapi for new features

plz don't depend on qvitterapi for new features
Member

????

????
Member

I guess this.$store.state.api.backendInteractor.externalProfile(acct) is qvitterApi?

can we have something similar of our own if qvitterapi is not ok?

I guess `this.$store.state.api.backendInteractor.externalProfile(acct)` is qvitterApi? can we have something similar of our own if qvitterapi is not ok?
Member

I guess this.$store.state.api.backendInteractor.externalProfile(acct) is qvitterApi?

Yes

can we have something similar of our own if qvitterapi is not ok?

Yes, filed pleroma#1222

> I guess `this.$store.state.api.backendInteractor.externalProfile(acct)` is qvitterApi? Yes > can we have something similar of our own if qvitterapi is not ok? Yes, filed pleroma#1222
Member

oh yeah, that unmaintained bit of code. I thought there's already mastoapi analogue for it?

oh yeah, that unmaintained bit of code. I thought there's already mastoapi analogue for it?
Member

We extended /api/v1/accounts/:id to support nicknames, but remote nicknames don't work because of a bug

We extended `/api/v1/accounts/:id` to support nicknames, but remote nicknames don't work because of a bug
Member
              params: { id }
```suggestion:-0+0 params: { id } ```
Member

errors aren't handled at all, at least showing a bar with error would be nice

errors aren't handled at all, at least showing a bar with error would be nice
Member

"Searching for @user@instance" would be nicer

"Searching for @user@instance" would be nicer
Member

maybe call it RemoteUserResolver or RemoteUserSearch, since there's no actual profile in it and it might be confusing since we have UserProfile which is used for both remote and local profiles.

maybe call it `RemoteUserResolver` or `RemoteUserSearch`, since there's no actual profile in it and it might be confusing since we have `UserProfile` which is used for both remote and local profiles.
Author
Member

OK.

OK.
Author
Member

Done. Thanks.

Done. Thanks.
Author
Member

Done. Thanks.

Done. Thanks.
Member

@rinpatch is the MastoAPI issue for this fixed?

@rinpatch is the MastoAPI issue for this fixed?
Member

Yes, pleroma#1222

Yes, pleroma#1222
Member

i'll test it once again today and merge

i'll test it once again today and merge
Member

it worked last time, at least

it worked last time, at least
Member

on of the routes doesn't work properly with dev server but it's fine i guess.

on of the routes doesn't work properly with dev server but it's fine i guess.

Pull request closed

Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
pleroma/pleroma-fe!2188
No description provided.