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

@trwnh @benpate @evan @julian @rimu
I am focused on what can we do pragmatically and realistically as a community to fix the broken experience to help get more people into the fediverse.

A mix of

1) JavaScript for websites that want to link to the fediverse that trigger ap: and offer http fallback (just like fb: before 2015)

2) adding support for ap: on fedi clients

It’s something we can do now. It works and we don’t have to wait for big tech

Yes. I agree with just moving forward with the tech we have.

What would the JavaScript do, exactly?

What parts of this would require a new ap:// protocol, or could we accomplish this with regular https:// links?

Also: thanks for starting this conversation. I think it’s very helpful and timely!

@ricferrer @trwnh @evan @julian @rimu

@benpate @trwnh @evan @julian @rimu
Maybe I did not explain it well. Fb, twitter, instagram used JavaScript to try to open their uri. If it failed, they opened the http equivalent

The user did not notice much. If they had the app, it jumped. Sometimes if you returned to the browser the http was opened anyways. But that’s wasn’t very annoying

@[email protected] @[email protected] yes, that's correct and what the current state of affairs is.

You can write links pointing to an interstitial page that says something like "opening in app", and use js to fire off the web+ap protocol handler.

If the user is still on the page after some time has passed, the handler failed and you redirect to the https version.

@julian

just some historical context,

 since at least 2010 (16 years ago) registerProtocolHandler is specified and worked for mailto: then for tel: (cause nice for gooles android)

 back in 2015 (11 years ago) we (w3c SocialCG) had talked to all the browser makers about making ActivityPub and webmention trusted protocols.

In 2016 (T-10 years) I demoed the existing practical problems at Jeremy Keiths indiewebcamp in Brighton see the demo https://www.youtube.com/live/W70wd56i0Bg?si=DJgm9WsGpwzaLdGJ&t=2030 (indiewebcamp demos are written in incredible short time …)

Anyway - nothing changed at the browser makers except the browser makers switched their positions from company to company. @jaffathecake :)

[edit; well: Mozilla did BrowserId, renamed it to Persona and directly trashed it cause then gaming and AI [where the parts of the teams went to] was more important …

@ricferrer @benpate

@sl007 @julian @jaffathecake @benpate but you don’t need approval or the blessing from the browsers to implement a uri scheme right? iTunes used it with itms: , zoom does it.

It works of people have the app. You would only need their support if you want the browser to do something with the uri out of the box when there is no app other than showing an error. Right?