search

swicg / activitypub-html-discovery

Other
20 stars 0 forks source link

Like a page #9

Closed evanp closed 3 weeks ago

evanp commented 3 months ago

"As a Web user, when reading a web page, I want to know the equivalent ActivityPub object so I can make it the object of a Like activity."

nightpool commented 3 months ago

What's the problem with just using the page's URL? AP uses content-negotiation heavily... shouldn't the AP ID of a page match the URL the user is looking at? (or the rel=canonical of it i guess if the HTML page has multiple URLs)

evanp commented 3 months ago

There are several examples of how to determine the ActivityPub equivalent of an HTML page in other issues in this repo, such as content negotiation and link elements.

AP does not define a discovery mechanism. Cataloging the known ways to do it and maybe exploring others is the point of this task force.

benpate commented 2 months ago

I believe FEP-3b86 is a good solution to this use case. To avoid spamming a huge comment on several issues, I added #15 as its own discussion.

benpate commented 2 months ago

What's the problem with just using the page's URL? AP uses content-negotiation heavily... shouldn't the AP ID of a page match the URL the user is looking at? (or the rel=canonical of it i guess if the HTML page has multiple URLs)

I think the issue is that I want to be able to interact with the AP object directly, and not have to copy/paste the URL back to my home server. Personally, I'm looking for ways to make this cross-server interaction as easy as it is on centralized corporate services.

nightpool commented 2 months ago

AP does not define a discovery mechanism. Cataloging the known ways to do it and maybe exploring others is the point of this task force.

I agree that it's not necessarily specified and also that (as you said in #15, AP doesn't require it), but I do question the wisdom of specifying many different mechanisms to do "html discovery" when the most simple and straightforward mechanism is ... no mechanism at all. Removing the question all together is the best and most compatible approach for a wide variety of use-cases.

benpate commented 2 months ago

I was barking up the wrong tree with #15 -- thinking that something like Web Intents was on the table, when this project is not that.

Since this is just about ActivityStreams-izing existing URLs, then yes, WebFinger seems like overkill and the straight-up URL seems like the best fit.

evanp commented 2 months ago

I agree that it's not necessarily specified and also that (as you said in #15, AP doesn't require it), but I do question the wisdom of specifying many different mechanisms to do "html discovery" when the most simple and straightforward mechanism is ... no mechanism at all. Removing the question all together is the best and most compatible approach for a wide variety of use-cases.

It's not actually compatible; it only works if you can change your server routes to do content negotiation. That's usually OK for social servers that were designed from the bottom up to do AP, but there are many CMSes or other Web publishing tools which will have the AP id on a different server, or in a different area of the server path structure.

There are other mechanisms in use by ActivityPub servers besides content negotiation. Mastodon uses link elements with rel=alternate.

The CG agreed in its last meeting to start a task force to work on describing this issue and making it easier. If you think we should end this task force, maybe bring it up as a proposal at the next meeting, or on the mailing list?