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.

@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.

https://swicg.github.io/activitypub-html-discovery/

One of the reasons I'm working on ActivityPub API adoption is to make this use case easier. You can see an explanation here:

https://evanp.me/2024/04/22/cross-server-interactions-in-activitypub/

@tom or referencing for example an image-post on a website and clicking on it from the browser so that it promps me to open it on #mastodon or #pixelfed where I am already logged in and from there being able to repost, favorite, etc

@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:

https://acct.swf.pub/

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:`

https://datatracker.ietf.org/doc/html/rfc7565

@ricferrer @julian @rimu@piefed.social @evan Here's a video of web+ap url handling in PieFed

https://peertube.wtf/w/7VwgZJ9UkH3REbcngaKn4Z

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.

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!!! <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/2639.png?v=528dceee8b2" title="" /> It's to trigger the protocol handler.

@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.

@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 viewer

activity+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 viewer

activity+json could be opened in an activity viewer. see firefox for example in pic 1:

I understand the need to link back to an app. It’s important, but I’m voting for the open web.

All the search and discovery interactions *should* start out on a website somewhere, then link back to your home website (or possibly an app) to share and like.

But, using a new URL scheme will lock out everyone who doesn’t have an app installed, and that’s a bad UX.

Plus, I think we can solve this “back to my server” issue in other ways WITHOUT needing a URL scheme, like: #FEP3b86

@ricferrer

@trwnh @evan @julian @rimu while this is true now, it was an evolution. As you probably know, the ht in html and http stands for HyperText, the fundamental concept that enabled websites in the early 90s

The question is what is more realistic for wide adoption… that all browsers start recognizing activities and decide if rendering in a viewer inside the browser or redirecting outside to an app makes sense.

@rimu@mastodon.nzoss.nz @ricferrer @julian @rimu@piefed.social @evan this is the way for web frontends, which are effectively "browsers in browsers".

if you are starting with a link in your "level 1" web browser, you need to copy it into your "level 2" web browser. https://www.devever.net/~hl/webappcoupling

@ricferrer @evan @julian @rimu any browser right now can recognize, or should be able to recognize, that the http response it got is "content-type: application/activity+json" and then open it in your system's configured activity+json processor, like a PDF or PNG or anything else.

i think it's not realistic to fork the entire namespace of http resources based on content-type. it was bad enough that https: was different from http: and we are still dealing with the repercussions of that move today

@trwnh @evan @julian @rimu

I think the biggest difference with pdfs, mp4 in your example and an activity is that I most likely want to interact with an activitypub object: either follow, repost/announce, etc for this to work I need to be logged in. So is the solution to include an activitypub client in the browser? Use an external viewer that intercepts through browser extensions?

Now even the experience inside mastodon sometimes opens a webview ‍️

@ricferrer @evan @julian @rimu if we say that every resource needs *two* identifiers, one to open in a "https" browser and one to open in a "fedi" browser, then why? what happens if someone copies the "fedi" uri outside of the "fedi" context, and the other person doesn't have a "fedi" uri handler on their system? that link becomes useless. not everyone is going to know to copy the "correct" link, or that the "incorrect" link can be rewritten.

@ricferrer @evan @julian @rimu which is more realistic: that literally every application in the world need to start recognizing "fedi" links, or that existing fedi applications start opening https: links locally ("in-app") where possible?

@ricferrer @evan @julian @rimu

acceptable solutions imo:

- a browser extension that lets you POST to your outbox (to publish activities) or proxyUrl (to view activity streams 2.0 resources)
- in-app rewriting like https://browser.pub/ that keeps all links as "internal links" with the ability to open an "external link" that takes you out of the app
- a system app that handles activity streams 2.0 resources which your default browser can dispatch to (and this may be a PWA!)