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

@ricferrer @benpate @evan @julian @rimu you don't have to install an extension though -- that's just one way to make things easier.

consider the example of sharing something via a messaging app though. do you trust people to copy the "right" link? or do people have to load an https: then load a fedi: link twice in a row? how is that supposed to work vs just having your existing https resolver handle it for you, *like it already does* to some extent with other content-types?

Can you expand on this idea? I know toots are short, but this is interesting and I want to better understand what you’re proposing here.

👉🏻👈🏻

@trwnh @ricferrer @evan @julian @rimu