Discussion: Web Intents

[benpate]

This comment applies to many issues posted to this repo. I'm putting it here and will reference it in those other places. I hope this is the right place to contribute. If not, please let me know and I'll make corrections.

If I'm understanding the issues in this repo correctly, the fundamental issue is that a user visits a web page and wants to interact with it from their home server in some way -- such as a share, quote, like, reply, block, etc -- without copy/pasting the URL. This seems like an expanded/normalized version of older initiatives, like: the abandoned Web Intents standard, the also abandoned oStatus Remote Follow, or Twitter's Intents API (skipping the link to X for reasons).

So, we already have the tools and established patterns for building out these use cases. What we need is a workable standard that apps can implement confidently - one that clearly defines the data that can be passed, that allows for custom routes and parameter names, and that cuts through the huge variations between platforms. In April, I published a solution for this that accomplishes these goals (plus a bit more).

Here's How I See This Working

1. Select Intent Somewhere on the open web (we'll call this the remote server) the user clicks on the action they want to perform (share, like, etc) on a specific web page or object. JSON-LD metadata on this page doesn't help us because we need some way to link back to the user's home server. It needs to be a link in the HTML (or possibly provided by the browser's chrome)

2. Identify Home Server The remote server prompts the user to enter their account handle on the server they want to interact from (call this their "home server"). For example, my home server account name is @benpate@mastodon.social. This username should be saved for future use.

3. Intent Lookup The remote server determines what capabilities the user's home server provides. For instance, Mastodon and others publish a hard coded /share?text=XXX but does not support other intents (like, block) endpoint that supports one of these options. I don't know of any other servers that implement other types of intents, though. I've proposed FEP-3b86: Activity Intents that uses WebFinger to publish users' capabilities for this exact purpose.

4. Forward to Home Server Activity Intents include simple template strings that align with the ActivityStreams Vocabulary. The remote server replaces values in the template with relevant data from the current web page and forwards the user to the published location on their home server where they complete the interaction.

I've skipped a few more details from the FEP, but these are the essentials. I'm currently finishing up a server-side implementation of this protocol that cross-cuts Activity Intents, oStatus Remote Follows, and hardcoded links like Mastodon's /share endpoint. It's actually the foundation of my FediForum presentation next month (if they'll have me).

** NOTE: In the future, some of this functionality might be provided directly by the browser via Federated Credential Management or plugins that add "share" and "like" buttons to their browser chrome. The fundamentals are still pretty much the same, so I'll bump that discussion for later.

[evanp]

If I'm understanding the issues in this repo correctly, the fundamental issue is that a user visits a web page and wants to interact with it from their home server in some way -- such as a share, quote, like, reply, block, etc -- without copy/pasting the URL.

You are not understanding the issue correctly. The issue is that if I'm going to create a Like activity for an HTML page like https://example.org/article1.html, I need to find the ActivityPub ID for the page, like https://social.example.org/api/pages/article1.

It may have content like this:

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "id": "https://social.example.org/api/pages/article1",
   "type": "Article",
   "attributedTo": "https://social.example.org/api/people/evanp",
   "to": ["as:Public"],
   "url": {
       "type": "Link",       
       "mediaType": "text/html",
       "href": "https://example.org/article1.html"
   }
}

That way you can make an activity like this:

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "type": "Like",
   "to": "https://social.example.org/api/people/evanp",
   "object": "https://social.example.org/api/pages/article1"
}

...and send it off to the author.

Once you have the AP ID, there are lots of ways to execute the like: with Mastodon API, with ActivityPub API, etc. It doesnt have to happen in a browser, and there doesn't need to be a finite set of activities that can be done to the object.

Pages don't have to represent "Article", "Page" or "Note" types. They could represent an image (like a Flickr page), a person, or even an activity.

There are a lot of ways to find out the AP id from the page URL:

• content negotiation. the html page url is identical to the ap id. this is common for profiles and notes on mastodon, so a lot of people think it's required for ap. it's not.
• link element. useful when thew urls differ.
• webfinger. useful for binary data types.

anyway, i think this is a complex enough topic that introducing web intents is too much, and i think it should be out of scope.

[benpate]

Understood. And thanks for the clarification. Sorry to add noise to the conversation.

I do love the ability to add an “ActivityPub ID” to any object. Looking forward to seeing this progress!