The downside of this solution is that sender can insert arbitrary hidden text by creating .quote-inline
elements (unless clients require inner text to match the RE: <URL>
template exactly).
They can, but Iām not sure how much of that is an issue. Itās also already something that senders can do using some class names in multiple implementations. I am uneasy with mandating a exact content format here, especially since implementations may e.g. want to make that part an actual link, which would lead us to have to specify the exact HTML.
One solution I was thinking of since the original Object Links FEP appeared regarding this was to match the a
element by the Linkās href and walking itās parent elements until one has a textContent matching the name of the object link.
This seems like it would match quite a few use cases (crucially, both in cases where Link.name == a
.textContent and in cases where there are surrounding decorations like the RE:
prefix), and the only thing itād require out of producers would be to wrap the text in any HTML element (even a plain span
without any classes would do)
My main concern about this is Iām unsure about how many HTML tooling actually supports computing textContent
.
I think the stamp can apply to other scopes without becoming ambiguous. Essentially, it would specify allowed activities, including actors, objects, and targets. So your example would become something like this
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"toot": "http://joinmastodon.org/ns#",
"Authorization": "toot:Authorization"
}
],
"type": "Authorization",
"id": "https://example.com/users/alice/stamps/1",
"activity": "Quote",
"actor": "https://example.org/users/bob",
"attributedTo": "https://example.com/users/alice",
"object": "https://example.org/users/bob/statuses/1",
"target": "https://example.com/users/alice/statuses/1"
}
But again, please donāt think of this as an objection. It can be tackled as itās own topic. And I see no reason that multiple kinds of authz tokens canāt coexist, so the existence of this specialized one doesnāt preclude a future generic token
So, essentially moving the QuoteAuthorization
to a generic Authorization
with an activity
property. I donāt see a fundamental difference in both approaches, but I can see why youād consider this cleaner. Iām personally fine with this change!
I was thinking more about this and wondered what we really wanted to achieve here. If we donāt require the RE: <URL>
template in the spec, then people can still insert arbitrary hidden text, it would just have to also be in the Link.name
, but in both cases this would be hidden from the user, and in both cases, inspecting the ActivityStreams object would surface it. Using the textContent
would just make it harder to implement for clients which do not have convenient HTML parsing and CSS addressing.
the example seems confusing semantically; right now, it looks like an Authorization activity performed by bob and attributed to both alice and bob.
from a data modeling perspective i donāt particularly have any opposition to a base Authorization
class that can be subclassed as LikeAuthorization
, ShareAuthorization
, ReplyAuthorization
, QuoteAuthorization
, and so on as needed.
i think itās also possible to have a more generic ālink approvalā that can be an attribute of a generic web link? so take the approvedBy
and make it not only a property of as:Link
but also an attribute of Link headers or a/link HTML nodes? RFC 8288 - Web Linking ā although itās unclear when something is a string and when something is a URI
I would personally like some usage such as:
<a href="https://quote.example/url" class="quote">RE: https://quote.example/url</a>
as it uses the same pattern already done for mentions and tags, e.g.
<a href="https://quote.example/@alice" class="mention">@alice@quote.example</a>
<a href="https://quote.example/topic" class="hashtag">#topic</a>
Iām not sure about how rel relations work, see RFC 8288, but one might also consider the rel attribute, i.e.
<a href="https://quote.example/url" rel="quote">RE: https://quote.example/url</a>
<a href="https://quote.example/alice" rel="mention">@alice@quote.examplel</a>
<a href="https://quote.example/topic" rel="tag">#topic</a>
However, harmonizing these things should probably be the topic of a different FEP.
We would like to create one FEP to standardise representing links to ActivityPub objects in content.
A big issue we have right now is that it is up to the receiving server or client to try to guess if a link has an AP representation or not, for example to decide if the link should be opened in-client or as a web URL, or to display them with some special UI (like Discord does when you paste a link to a message). We think that the authoring software should be the one doing this work. Object links are a good candidate for this but have a few missing things (I dont remember the details), so we are planning to try to harmonize and standardize this.
After another round of thinking it would probably be enough to specify that if a link contains the class tag
that one should look in the tag
property of the object to obtain more information. Using a class also has the advantage that one could extend it to a span, e.g. use
<span class="tag">RE: <a href="https://host.example/obj">host.example/obj</a></span>
instead of
<a href="https://host.example/obj" class="tag">RE: host.example/obj</a></span>
Examples
{
"content": "<a href='https://host.example/objId' class='tag'>host.example/objId</a>",
"tag": [{
"type": "Link",
"href": "https://host.example/objId",
"mediaType": "application/activity+json",
"name": "host.example/objId"
}]
}
to link to an ActivityPub object and
{
"content": "<a href='https://host.example/page' class='tag'>host.example/page</a>",
"tag": [{
"type": "Link",
"href": "https://host.example/page",
"mediaType": "text/html",
"name": "host.example/page"
}]
}
to link to a webpage. Similarly, one can use
{
"content": "<a href='https://host.example/alice' class='tag'>@alice</a>",
"tag": [{
"type": "Mention",
"href": "https://host.example/alice",
"name": "@alice"
}]
}
for a mention. Iāll leave adding Hashtag to the reader.
Why not link relation?
The link relation tag is probably inappropriate for this, see HTML Standard
Just wanna add to this convo that weāve been working with interaction policies in GoToSocial for a while now, and the protocol extension described here is extensible to include a canQuote
property on an interaction policy: Interaction Policy - GoToSocial Documentation
Reply, Like, and Announce controls and approvals etc are already running in GoToSocial since v0.17.0 last year. It would be pretty neato if Mastodon could reuse the interaction policy properties and approval flow for quote posts, insofar as thatās possible. Have discussed this in the Mastodon discord with Claire as well, but just putting it here too.