Federated image from Lemmy

[kromonos]

Expected behaviour

Mastodon shows the link to the post on lemmy instead of the direct link to the image

Actual behaviour

Mastodon shows the direct link to the image on lemmy

Steps to reproduce the problem

1. Create a post on lemmy with an image instead of link
2. Take a look, what Mastodon receives

Specifications

Lemmy 0.14.1
Mastodon v3.4.3 and v3.4.2
Browser: Latest version of Firefox, Chrome, and Chromium

[mstdn]

I think this would be an "issue" with Lemmy rather than with Mastodon 😉

[kromonos]

I think this would be an "issue" with Lemmy rather than with Mastodon wink

And the Lemmy devs say, it's an issue with Mastodon ;)

[ClearlyClaire]

For some reason, trying to get the ActivityStreams representation of https://fapsi.be/post/2989 leads to NotFound, so I cannot investigate further…

[kromonos]

Strange. I can open the Link without any problems:

Even in a private window:

[ClearlyClaire]

Same, but that's the HTML representation. I can not fetch it in Mastodon nor manually inspect the ActivityStreams representation as querying https://fapsi.be/post/2989 with Accept: application/activity+json or Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams" returns a 404.

In any case, the behavior you're describing suggests the object had a url value pointing to the image, which I'm not sure is a proper use of the property since it's not really a representation of the same activity.

[kromonos]

hmm 🤔 Maybe @dessalines could help out a bit?
Also @Nutomic made a hint at LemmyNet/lemmy#1910 (comment)

[kromonos]

Ok, that's kinda funny. I took another post with an image upload, but that did it.

🤔 where the heck is the difference? Never mind. It's the same with the URL in the Mastodon post:

[ClearlyClaire]

Alright, this one I can fetch and inspect. What happens is the activity type (Page) is not one “native” to Mastodon, so Mastodon only shows a summary, in this case comprised of:

• the name of the activity (“Drow”)
• a link to the url field of the activity, which in this case is the a link to the image and not the activity itself. As I said earlier, I believe it's a misuse of the url field as it's supposed to represent the activity itself. But at the same time, lemmy is centered around link sharing so it kinds of make sense.

In any case you can still see the article itself by clicking the permalink (where the timestamp is displayed).

Maybe a possible improvement to Mastodon would be to make it clear that it is not a native activity and thus that some information may have been dropped.

EDIT: uh, it seems the permalink thing also makes use of the url field, so from the Mastodon UI you can't actually go to the article. I'm not sure whether the blame lies on lemmy or Mastodon for this one

[Nutomic]

@ClearlyClaire The docs say "Identifies one or more links to representations of the object". So maybe we are using it wrong. But not sure what the correct alternative would be, maybe like this?

{
    "type": "Page",
    "object": {
        "type": "Link",
        "href": "http://example.org/abc",
    },
    ...
}

[ClearlyClaire]

@Nutomic that's a good question. To be honest, that use of url seem consistent with the Page type, but that would imply that Page describes the page itself and would not have any additional content. Maybe Article would be more fit for this purpose. object is supposed to be used within Relationship and Activity objects, which neither Page nor Article are. Maybe attachment…

[dessalines]

If we ever want to switch to a multiple link model ( which would be necessary if we want to support things like multiple pictures ), maybe attachment would be better.

[Nutomic]

FYI we are using attachment field for page links now. url field is still present for backwards compatibility, but will be removed in the next version.

https://join-lemmy.org/docs/en/federation/lemmy_protocol.html#post

[ClearlyClaire]

@Nutomic good to hear! While it might still be useful for Mastodon to expose the uri to the end-user, dropping url should fix the issue altogether.

[paulo-roger]

@trwnh any reason for not implementing this?