@[email protected] the only implementor I know of who has recently played around with this is @[email protected] 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?

cc @[email protected]

@evan @julian @rimu it’s horrible UX. It opens a browser where I am not logged in instead of opening my default app, like it happens with mailto:

https: is for webpages

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

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

@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 🤷🏻‍♂️

I think the right solution is to use a combination of FedCM (making progress in the W3C) plus Activity Intents (FEP-3b86) to link you back to the web page for your home server.

FedCM will let you “sign in” to your browser, and make that information available (with consent) to the pages you visit online.

Activity Intents publish the operations your home server supports, then give links to complete the intent.

We already have the tools we need.

@ricferrer @trwnh @evan @julian @rimu

@benpate @ricferrer @evan @julian @rimu should be possible even without necessarily those specific tools -- although fedcm can make it "friendlier" ux-wise

- authenticate your id ("i am this person")
- get the linked claims from the id ("this is my proxy url")
- submit the request ("fetch me this thing")

i mean, you could write a web extension right now that does it in a very minimal way, i'm pretty sure? "POST the current URL to this proxyUrl" is not exactly a difficult thing to do...

@trwnh @benpate @evan @julian @rimu share targets opens a new post, which is expected behavior

I think waiting for all browsers to allow extensions and then waiting for extensions to exist and then expecting the user to know which to use is not very realistic or short term.

@ricferrer to repeat: you don't need the extensions. they are just one option to making things simpler. i described at least 2 other options that are all complementary:

- rewrite links to keep you in-app
- content-type handlers to get you in the right app
- extensions to also get you in the right app
- share targets to get you in the right app (on mobile)

you can use one, some, all, or none of these. the first one is the most important; the others should also be easy to do right now.