Remove obsolete profile.dfrn_request field #87

Merged
heluecht merged 8 commits from MrPetovan/friendica-directory:task/86-remove-dfrn_request into stable 11 months ago
Owner

Closes #86

This PR replaces the zrl query parameter with the srl parameter which is supposed to contain the subscribe URL as described in the requesting Friendica node XRD output.

@heluecht Should I keep the zrl parameter around for backward compatibility or is the subscribe URL old enough to skip this?

Closes #86 This PR replaces the zrl query parameter with the srl parameter which is supposed to contain the subscribe URL as described in the requesting Friendica node XRD output. @heluecht Should I keep the zrl parameter around for backward compatibility or is the subscribe URL old enough to skip this?
heluecht was assigned by MrPetovan 11 months ago
MrPetovan added the enhancement label 11 months ago
MrPetovan requested review from heluecht 11 months ago
heluecht was unassigned by MrPetovan 11 months ago
Owner

Friendica is providing this "subscribe" functionality for many, many years.

But I have got a question: Why don't we perform a webfinger request via /.well-known/webfinger?resource={uri} with {uri} set to the value of zrl and fetch the value for http://ostatus.org/schema/1.0/subscribe from there? This would provide support for most of the Friendica servers.

Friendica is providing this "subscribe" functionality for many, many years. But I have got a question: Why don't we perform a webfinger request via `/.well-known/webfinger?resource={uri}` with `{uri}` set to the value of `zrl` and fetch the value for ` http://ostatus.org/schema/1.0/subscribe` from there? This would provide support for most of the Friendica servers.
Poster
Owner

I see what you mean, but with your idea this would also deteriorate the frontend experience that would depend on a remote node lookup.

Instead I think we can store the subscribe URL for each server, and replace the zrl parameter with the srl parameter by matching the profile URL with the server base. This way the remote lookup will be done in the background as part of the server polling.

I see what you mean, but with your idea this would also deteriorate the frontend experience that would depend on a remote node lookup. Instead I think we can store the subscribe URL for each server, and replace the zrl parameter with the srl parameter by matching the profile URL with the server base. This way the remote lookup will be done in the background as part of the server polling.
MrPetovan removed review request for heluecht 11 months ago
Owner

Couldn't it be a security issue when we pass that value without processing?

Couldn't it be a security issue when we pass that value without processing?
Poster
Owner

Unfortunately, you are right, I guess we have to use the XRD fetch then, which will prevent accounts coming from nodes the directory doesn't know about to have a direct follow link.

Unfortunately, you are right, I guess we have to use the XRD fetch then, which will prevent accounts coming from nodes the directory doesn't know about to have a direct follow link.
MrPetovan changed title from Remove obsolete profile.dfrn_request field to WIP: Remove obsolete profile.dfrn_request field 11 months ago
Owner

When someone is calling the directory directly, we could do it like Mastodon does: https://social.network.europa.eu/explore

When you click on "follow", some window opens where you enter your handle. Then the system performs this XRD request and the follow action is executed.

When someone is calling the directory directly, we could do it like Mastodon does: https://social.network.europa.eu/explore When you click on "follow", some window opens where you enter your handle. Then the system performs this XRD request and the follow action is executed.
Poster
Owner

It looks like we could open the target server's /remote_follow page to do this instead of having to create a directory page for it, it's been available since February 2020.

It looks like we could open the target server's `/remote_follow` page to do this instead of having to create a directory page for it, it's been available since February 2020.
Poster
Owner

And /dfrn_request has been available until July 2021, so I could check the version tag to show either.

And `/dfrn_request` has been available until July 2021, so I could check the version tag to show either.
MrPetovan force-pushed task/86-remove-dfrn_request from 69f08e68d1 to 46083b2a49 11 months ago
MrPetovan force-pushed task/86-remove-dfrn_request from 46083b2a49 to 9e1984e3d6 11 months ago
MrPetovan force-pushed task/86-remove-dfrn_request from 9e1984e3d6 to bd6c9e20b0 11 months ago
MrPetovan changed title from WIP: Remove obsolete profile.dfrn_request field to Remove obsolete profile.dfrn_request field 11 months ago
MrPetovan force-pushed task/86-remove-dfrn_request from bd6c9e20b0 to e65bb660ce 11 months ago
MrPetovan requested review from heluecht 11 months ago
Poster
Owner

I feel better about this new version. No more SRL parameter, we just use the ZRL as before, from which we try to get the relevant subscribe URL from the data the directory has. If we don't have it, we show the /remote_follow URL if the target node's version allows it.

No changes required in the base Friendica repository for maximum backward compatibility.

I feel better about this new version. No more SRL parameter, we just use the ZRL as before, from which we try to get the relevant subscribe URL from the data the directory has. If we don't have it, we show the `/remote_follow` URL if the target node's version allows it. No changes required in the base Friendica repository for maximum backward compatibility.
heluecht merged commit 3f38b3adea into stable 11 months ago
MrPetovan deleted branch task/86-remove-dfrn_request 11 months ago

Reviewers

heluecht was requested for review 11 months ago
The pull request has been merged as 3f38b3adea.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: friendica/friendica-directory#87
Loading…
There is no content yet.