A problem that link aggregator style platforms run into is how to represent posting a link. The current de facto standard seems to be a Page object with the url field set to the link target. However, this doesn’t seem to be compatible with ActivityStreams definition of that field, since the url doesn’t point to a “representation of the object” but rather the object is often some sort of commentary on the link.
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Article",
"name": "What a Crazy Day I Had",
"content": "<div>... you will never believe ...</div>",
"attributedTo": "http://sally.example.org"
}
The url isn’t mandatory for an Article (but is for a Page). It is widely used for the visual represantation of a Note or Article, but needn’t to be used at all.
The ‘url’ element can and should be be an array of different representations of (and different relations to) the selected object. There’s no reason this array couldn’t contain both a text/html representation and an application/activity+json representation with corresponding relations of ‘self’ (for instance). For media elements you might distinguish further based on dimensions.
Consuming applications only need to choose the flavours and relations and dimensions they are capable of consuming.
Page could make sense as a representation of the link itself, though that’s distinct from the “link post” which seems to me more like a Note that may be connected to that Page
You would need a link to the HTML representation of the post. This could be self. But which rel would be suitable for the external link that is described with the Page element?
I still don’t understand. For me that post appears to me to have exactly the same structure like the Page posts we talked about. I’m extremely bad in interpreting other people’s content.
@heluecht: I think the definition of url is quite clear: “Identifies one or more links to representations of the object”. Thats not at all what we use it for in Lemmy now, we use the field for links to other websites (or images) which are discussed in the Page. I also dont see any indication that the link field has a different meaning in Article and Page, beside that example. And its just that, an example, not a definition.
So for me using attachment field makes the most sense. I can certainly migrate Lemmy towards using that, although we will have to keep using link field for some months for backwards compatibility. In the future it will then look like this:
attachment can be an array, I guess a system that only supports one attachment would just grab the first one? But yeah ideally it would do something more useful with the rest
Should we also add random links in the page/note/article content to the attachment array, or only the links explicitly specified by the author? If only the specified, a GNU social Page will look like this:
{
"type": "Page",
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"gs": "https://www.gnu.org/software/social/ns#"
},
{
"inConversation": {
"@id": "gs:inConversation",
"@type": "@id"
}
}
],
"id": "https://instance.gnusocial.test/object/note/1339",
"published": "2022-03-17T23:30:26+00:00",
"attributedTo": "https://instance.gnusocial.test/actor/42",
"name": "hello, world. This is my first bookmark!",
"summary": "<p>This is the summary of a GNU social bookmark.</p>",
"content": "<p>This is the description. And it references <a href=\"https://duck.com\">DuckDuckGo></a> too.</p>",
"mediaType": "text/html",
"source": {
"content": "This is the description. And it references [DuckDuckGo](https://duck.com) too.",
"mediaType": "text/markdown"
},
"attachment": [
{
"href": "https://gnu.org",
"type": "Link"
}
],
"tag": [],
"inConversation": "https://instance.gnusocial.test/conversation/1339",
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"cc": [
"https://instance.gnusocial.test/actor/21"
]
}
and this is rendered as:
<h1>hello, world. This is my first bookmark!</h1>
<a href="https://gnu.org" rel="noopener noreferrer">https://gnu.org</a>
<details>
<summary><p>This is the summary of a GNU social bookmark.</p></summary>
<p>This is the description. And it references <a href="https://duck.com">DuckDuckGo></a> too.</p>
</details>
For Lemmy it will only contain a single link which is specified explicitly by the author. I also didnt implement it as an array but a single value, though if all other implementations use an array, thats probably the better choice.
Edit: Changed to array for attachment field now. For now Lemmy will always use the first item. In the future we could implement some smarter logic to select a link. Presenting multiple attached links to the user would be much more complicated, as it would require changes to database, api and frontend.