Pre-FEP: Quote posts, quote policies and quote controls

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

1 Like

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!

1 Like

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 :100: 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.

1 Like

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.

1 Like

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

1 Like

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.

2 Likes