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.

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

Do not fetch link cards for mentioned users #6934

Merged
merged 1 commit into from
Oct 25, 2018

Conversation

ClearlyClaire
Copy link
Contributor

No description provided.

@ClearlyClaire ClearlyClaire force-pushed the features/pleroma-compat branch 2 times, most recently from 8cc5022 to 35effb1 Compare March 27, 2018 17:38
@Gargron
Copy link
Member

Gargron commented Mar 28, 2018

I don't like the idea of making a hacky solution even more hacky but also forcing all app developers to make this subtle adjustment. How about we process the HTML server-side and replace the URI with URL when applicable?

To be honest if we start doing server-side processing of that HTML, we're only a few steps away from parsing the HTML into plaintext with demarkated entities...

@ClearlyClaire
Copy link
Contributor Author

ClearlyClaire commented Mar 28, 2018

@Gargron I don't like the idea of rewriting HTML links because you're really rewriting links, as opposed to just adding handlers dynamically in the WebUI. If the URL and URI are different for a reason, this breaks the original status' meaning in some way.

@Gargron
Copy link
Member

Gargron commented Mar 28, 2018

Well... There is a reason the URL property exists in the first place, it's what should be linked to. Imagine an AP implementation that returns only JSON-LD from the id URI. What would be the point of linking to it in HTML that end-users are supposed to see? And if the HTML is not meant for end-users, then post-processing it server-side on our end is exactly in line with that, because we intend the HTML to be for end-users...

@ClearlyClaire
Copy link
Contributor Author

Yes I know, but hear me out: admittedly, that is an edge case, but what if I purposefully link to that JSON-LD-only URL in my toot, for instance to talk about some ActivityPub software? I wouldn't want that link to be rewritten in my back, that would be extremely confusing.

@MightyPork
Copy link
Contributor

is this the reason some foreign statuses show the user profile as an embed?

@ClearlyClaire
Copy link
Contributor Author

@MightyPork that's probably addressed by the last commit, yeah

@Gargron
Copy link
Member

Gargron commented Mar 29, 2018

@MightyPork Mastodon uses microformats rel="mention" to demarkate mention links and conversely skip them when fetching link previews. Other platforms don't do that so their mention links look just like any other links.

@nightpool
Copy link
Member

nightpool commented Mar 29, 2018 via email

@ClearlyClaire
Copy link
Contributor Author

@Gargron actually, Mastodon uses CSS classes “u-url” and “mention”, and skips prefetching for links with a class of “u-url”.

@nightpool why not, but that's yet another thing to specify and push to other implementors of the fediverse…

@nightpool
Copy link
Member

Why would it have anything to do with other implementors in the fediverse? I'm just talking about for mastodon's API retrieval.

@nightpool
Copy link
Member

nightpool commented Mar 29, 2018

I'm not necessarily against this PR, it just seems like if we want a more stable solution, explicitly specifying the account id server-side before sending it to the client is the most robust and easy to implement one.

so something like <a href="whatever" data-mention-acct="899">@nightpool</a>

@ClearlyClaire
Copy link
Contributor Author

Ah ok, I thought you were talking about specifying the markup of the toot itself, and not something returned from the API.
I'm not sure how much I like it, but it makes sense. It's more work on the Mastodon backend side of things, and you still have to modify the clients to take advantage of it, but once it's done, if we ever do more elaborate guesswork, that could be kept to the backend.

@lambadalambda
Copy link

FYI: https://git.pleroma.social/pleroma/pleroma/commit/806550c921d1137e47ec662ea83ee0a542fb55d5

@lambadalambda
Copy link

btw, about that rel=mention, i didn't find it in the html the mastodon api returns, just class=mention. Where exactly are you using it?

@Gargron
Copy link
Member

Gargron commented Apr 3, 2018

btw, about that rel=mention

I got confused in my memory. It's rel=tag for hashtags, and class=u-url for mentions. rel=mention would have been consistent with rel=tag, but from a cursory google search, that does not seem to be a thing anywhere. rel=tag is indeed microformats.

@lambadalambda
Copy link

would it make sense for me to add that? where does the u-url come from?

@Gargron
Copy link
Member

Gargron commented Apr 8, 2018

@lambadalambda The u-url comes from hcard (microformats), see full markup: https://github.com/tootsuite/mastodon/blob/master/app/lib/formatter.rb#L226

I like @nightpool's suggestion with data-mention-account. I think the sanitizer strips out such attributes from remote HTML so it should be fine for clients to expect it to be valid & local.

@Gargron
Copy link
Member

Gargron commented Sep 27, 2018

Did this get adjusted on Pleroma's side? I would prefer to avoid these changes if possible.

@ClearlyClaire
Copy link
Contributor Author

Yeah, pleroma has been changed to play nice with Mastodon afaict. However, the preview card fetching code will still try to fetch mentioned users.

@ClearlyClaire
Copy link
Contributor Author

Updated to simply stop Mastodon from fetching cards for mentioned users

@Gargron Gargron changed the title Parse Pleroma-authored mentions properly Do not fetch link cards for mentioned users Oct 25, 2018
@Gargron Gargron merged commit 7fee968 into mastodon:master Oct 25, 2018
@ClearlyClaire ClearlyClaire deleted the features/pleroma-compat branch March 14, 2019 15:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants