It’s really surprising to me that the #fediverse hasn’t agreed on a standardized way to open cross-instance #activitypub objects and instead relies on links that open in the browser.
-
It’s really surprising to me that the #fediverse hasn’t agreed on a standardized way to open cross-instance #activitypub objects and instead relies on links that open in the browser. #urischeme
I found this proposal and what’s thinking… https://codeberg.org/fediverse/fep/src/branch/main/fep/07d7/fep-07d7.md Which one would be your favorite?
(If anyone has updates on the progress, feel free to point me in the right direction)
@ricferrer@mastodon.social the only implementor I know of who has recently played around with this is @rimu@piefed.social of Piefed. They use web intents I think, but the UX leaves much to be desired (many clicks and popups just to register the web intent)
I don't recall whether there was a SWICG task force about this topic... perhaps the HTML Discovery Task Force might be related?
-
It’s really surprising to me that the #fediverse hasn’t agreed on a standardized way to open cross-instance #activitypub objects and instead relies on links that open in the browser. #urischeme
I found this proposal and what’s thinking… https://codeberg.org/fediverse/fep/src/branch/main/fep/07d7/fep-07d7.md Which one would be your favorite?
(If anyone has updates on the progress, feel free to point me in the right direction)
Btw: matrix and xmpp seem to have well defined and well supported URIs
-
@ricferrer @julian @rimu We already have an URI scheme for ActivityPub objects; it's https: .
-
@ricferrer @julian @rimu We already have an URI scheme for ActivityPub objects; it's https: .
-
@ricferrer @julian @rimu We already have an URI scheme for ActivityPub objects; it's https: .
this is a serious issue Evan and dismissing it with replies like this really doesn't help anything. Its fine to not like the solution of using a custom uri scheme but currently there is not an easy way to interact with a remote object from your home server, and this is one solution to that issue that some people are already familiar with.
-
Btw: matrix and xmpp seem to have well defined and well supported URIs
@ricferrer I think it'd be neat to be able to share an ActivityPub URI in a matrix chat, have the client detect that it's an AP object and then render it as a card. I imagine the first step would be having an easy way to determine from the URI scheme that it's referencing an AP object and not just a generic URL
-
@ricferrer@mastodon.social well, there are a couple of ways to approach this issue.
the protocol-native answer is that content-negotiation is baked in-- any website that wants to publish AP content does so only when that content-type is requested; what the website shows when the same URL is requested without specifying content type is... dealer's choice!
a good explorer/example to display an unopinionated version of the AP content itself is browser.pub, which makes this more intelligible/intuitive. See, for example:
https://activitypub.space/post/https%3A%2F%2Fmastodon.social%2Fusers%2Fricferrer%2Fstatuses%2F116020078304208223 -
this is a serious issue Evan and dismissing it with replies like this really doesn't help anything. Its fine to not like the solution of using a custom uri scheme but currently there is not an easy way to interact with a remote object from your home server, and this is one solution to that issue that some people are already familiar with.
@wakest For good or ill, ActivityPub objects are supposed to use HTTPS URIs. It's in the spec: "Publicly facing content SHOULD use HTTPS URIs."
The discovery document shows a few good ways to discover if an HTML page, like a page loaded in a browser, represents an ActivityPub object.
One of the reasons I'm working on ActivityPub API adoption is to make this use case easier. You can see an explanation here:
Cross-server Interactions in ActivityPub
So, Richard McManus asked me about how ActivityPub supports cross-server usage. As an example use case, let's say a user with the account eric@social.example wants to comment on a photo by dionne@photos.example. In this scenario, Eric would go to the page https://photos.example/users/dionne/photos/1 and enter a comment. How would that work? I can talk about how…
Evan Prodromou's Blog (evanp.me)
-
@ricferrer I think it'd be neat to be able to share an ActivityPub URI in a matrix chat, have the client detect that it's an AP object and then render it as a card. I imagine the first step would be having an easy way to determine from the URI scheme that it's referencing an AP object and not just a generic URL
-
@wakest For good or ill, ActivityPub objects are supposed to use HTTPS URIs. It's in the spec: "Publicly facing content SHOULD use HTTPS URIs."
The discovery document shows a few good ways to discover if an HTML page, like a page loaded in a browser, represents an ActivityPub object.
One of the reasons I'm working on ActivityPub API adoption is to make this use case easier. You can see an explanation here:
Cross-server Interactions in ActivityPub
So, Richard McManus asked me about how ActivityPub supports cross-server usage. As an example use case, let's say a user with the account eric@social.example wants to comment on a photo by dionne@photos.example. In this scenario, Eric would go to the page https://photos.example/users/dionne/photos/1 and enter a comment. How would that work? I can talk about how…
Evan Prodromou's Blog (evanp.me)
@wakest Using a custom URI scheme is also going to give absolutely terrible UI for most users, who won't have an app installed.
-
@wakest Using a custom URI scheme is also going to give absolutely terrible UI for most users, who won't have an app installed.
@wakest That said, I think using the `acct:` URI scheme for Webfinger is pretty great. I've implemented a protocol handler for it here:
Unfortunately, `acct:` isn't one of the protocols allowlisted by HTML5 for linking in HTML pages, so it uses `web+acct` instead. At some point, I'll ask the HTML5 WG to add acct: to the allowlist. It's on my todo list!
-
@wakest That said, I think using the `acct:` URI scheme for Webfinger is pretty great. I've implemented a protocol handler for it here:
Unfortunately, `acct:` isn't one of the protocols allowlisted by HTML5 for linking in HTML pages, so it uses `web+acct` instead. At some point, I'll ask the HTML5 WG to add acct: to the allowlist. It's on my todo list!
@wakest there's an RFC for `acct:`
RFC 7565: The 'acct' URI Scheme
The 'acct' URI Scheme (RFC 7565, )
IETF Datatracker (datatracker.ietf.org)
-
@ricferrer @julian @rimu@piefed.social @evan Here's a video of web+ap url handling in PieFed
Demo: using web+ap links in PieFed
A PeerTube provider for general use, hosted in northern Europe.
PeerTube.wtf (peertube.wtf)
I'm not claiming it's the **best** solution but thought it was worth trying out.
-
@ricferrer @julian @rimu@piefed.social @evan Here's a video of web+ap url handling in PieFed
Demo: using web+ap links in PieFed
A PeerTube provider for general use, hosted in northern Europe.
PeerTube.wtf (peertube.wtf)
I'm not claiming it's the **best** solution but thought it was worth trying out.
@ricferrer @julian @rimu@piefed.social @evan Instead of putting web+ap links everywhere, PieFed just silently rewrites urls in post bodies so they go to the local copy of each post, if we have it.
In the threadiverse every instance has every post so this works pretty well.
-
@ricferrer @julian @rimu@piefed.social @evan Instead of putting web+ap links everywhere, PieFed just silently rewrites urls in post bodies so they go to the local copy of each post, if we have it.
In the threadiverse every instance has every post so this works pretty well.
I had a quick back and forth with Gemini about the state of protocol handlers, and there are some options for getting it working without the terrible UI flow in Rimu's video (no shade to you Rimu, it was entirely out of your control!!)
Since NodeBB is installable as a PWA, it is possible to pre-register the web+ap protocol handler, in which case it should "just work" to open those types of URLs.
The other half is having a graceful fallback to opening the HTTPS URL if there is no handler... and to do that you need an interstitial page.
... aaaaand now I completely understand why those stupid "open in app/open in browser" pages exist!!!
It's to trigger the protocol handler. -
@ricferrer @julian @rimu@piefed.social @evan Instead of putting web+ap links everywhere, PieFed just silently rewrites urls in post bodies so they go to the local copy of each post, if we have it.
In the threadiverse every instance has every post so this works pretty well.
@rimu@mastodon.nzoss.nz @julian @rimu@piefed.social @evan it’s a clever workaround, but what I would like to have is a possibility of reference content from the #fediverse #activitypub from any app or browser without the need to them needing to exploit support it. Also it should work independently of the client app that I am using. Just like ftp: open the right app and goes to the content.
-
@wakest there's an RFC for `acct:`
RFC 7565: The 'acct' URI Scheme
The 'acct' URI Scheme (RFC 7565, )
IETF Datatracker (datatracker.ietf.org)
@evan @wakest rfc 7565 describes how acct: is not resolvable, although web+acct: doesn't have this problem if you define it to use webfinger.
also i'm not sure about the browser UX but instead of a new uri scheme the typical solution here is actually content-type handlers (see firefox screenshot for example)
an http resolver SHOULD dispatch the content to the appropriate handler according to its content-type
"i'm not logged into my browser" is the issue, not "open a browser in a browser".
-
@evan @wakest rfc 7565 describes how acct: is not resolvable, although web+acct: doesn't have this problem if you define it to use webfinger.
also i'm not sure about the browser UX but instead of a new uri scheme the typical solution here is actually content-type handlers (see firefox screenshot for example)
an http resolver SHOULD dispatch the content to the appropriate handler according to its content-type
"i'm not logged into my browser" is the issue, not "open a browser in a browser".
@evan @wakest see also https://browser.pub/ and so on
- html content goes to an html viewer
- pdf content goes to a pdf vieweractivity+json content could go to an activity viewer
-
@ricferrer @evan @julian @rimu
https: is not for web pages. it's for http resources, which can be any content type. the content should be dispatched to the appropriate content handler; for example:
- html opens in an html viewer
- pdf opens in a pdf viewer
- png opens in a png viewer
- mp4 opens in an mp4 vieweractivity+json could be opened in an activity viewer. see firefox for example in pic 1:
