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)
@[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?
@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.
@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 imho this is unrealistic and wishful thinking. I donāt think all major browsers will agree to do it this way anytime soon. Specially on mobile where most people get their content.
if that doesnāt happen the fediverse will continue to be difficult for ppl accustomed to one app that offers a unified social experience
Before 2015 universal/app links didnāt exist, a URI scheme was the best solution FB, Twitter, Instagram found
@trwnh @evan @julian @rimu it already works well for mailto: the average user doesnāt have 10 mail clients. For the advanced and technical savvy users that want a bunch of fedi clients they can find other solutions on how deal with it.
Btw Android lets you choose your the app.
Before 2015 you would uninstall twitter and install tweetbot which responded to twitter:
Fallbacks to http/html for people without apps was handled through JavaScript
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
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!)
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.
@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 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.
@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!
@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
I think I follow. Instead of ālook before you leapā itās more like ājust jump anyway, then recover errors gracefully.ā
On my iPhone, websites themselves can declare a preferred app to use instead of the site. Thatās another way around this problem, yes? But I donāt know if thatās available in desktops or not.
I care mostly that we donāt break things for regular people who havenāt installed an app, and havenāt installed a browser plugin.
@benpate @trwnh @evan @julian @rimu that was the beauty of the approach. At the time desktop only said āapp not availableā but still had the destination open below the alert. I donāt know if macOS and other desktop handles it the same way now. I tried this in 2009 the last time š but it might be worth a try
On you iPhone it uses the newer approach of registering the domain for universal links (released in 2015). Which wonāt work in the fediverse
@[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.
@[email protected] and yes it will work fine with users without an app or extension installed. Agreed that this is a no-go for wide adoption. It has to be done with stuff everybody already has.
@julian yup
you could in theory do web+activity to mean "http get with accept header for activity+json" but what mastodon does is i think just intercept the click with js
This is unfortunately true. But I believe good content (plus those little like and share buttons) would give people a reason to join.
I yammered about this for 30 minutes at FOSDEM. I can link the presentation video once itās posted.
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 ā¦
@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?
@[email protected] yes and no. I think standalone apps can listen for their own protocol handlers (like julian:// what a great protocol)
But PWAs must use the web+ prefix. The OS (or maybe just the browser) won't allow registration otherwise
Thatās really helpful. Thanks, Julian://
One follow up question? Is it possible for regular apps to use the web+ prefix, too? Otherwise weād have to pick one over the other, which might be problematic.
well, the difference is what I demoed at IWC:
Apple itself (itms) or zoom https://www.visualcapitalist.com/zoom-boom-biggest-airlines/ can do anything.
You will not be asked for consent.
Same with mailto ā¦
But as shown the consent mechanism is not standardized and when I see the nearly white icon in the white browser bar I wanted to hit the person who made it cause at least 30% will not even realize it ā¦
Youāre correct.
FedCM is a bonus, but not required.
And Activity Intents just normalize the mess of āremote followsā and āshare intentsā that many apps already support. I currently āpolyfillā intents for servers (like Mastodon) that donāt publish explicitly.
It should, however, start with a GET to my home server (not a POST) so I can see what Iām about to do. Thereās so much variation between servers; weāre asking for bugs if we skip this step.
In the end, we need real āshareā and ālikeā buttons for the Fediverse - with as few clicks as possible - wrapped up as easily installable widgets that go next to Twitter and Facebook on every site online.
(Thatās step 1)
Once we do this, step 2 is to lobby sites to JUST use Fediverse buttons, and drop the ones for hateful platforms.
This is AMAZING, Dan, and it would be a huge win. #ThankYouThankYouThankYou!!!
Yes. I'm in.
I've built similar buttons for Emissary, but they require too much server-side logic. I've been wanting to migrate the whole thing to client-side JS for some time, and make an easy widget that "webmasters" can drop on their pages.
If you're interested, you're more than welcome to take the lead on this (I'm sooo full rn) and I'll do whatever you need to help out.
And if you want to chat, let's jump on a video call :)
@benpate @trwnh @ricferrer @evan @julian @rimu @webintents
Yes, for sure! I've already built a proof of concept, that I will get setup and ready to test on a video call.
I even got the project website up: https://webintents.net
Hereās a question: do browsers let JavaScript introspect what custom protocol handlers are available/installed?
Iām planning a Franken-widget that works with whatever tools are available.
Activity Intents? Sure
Custom protocol? Okay, weāll use that too.
None of the above? Sniff the server and polyfill.
We could certainly try an āANDā approach, if JavaScript will let us.
@[email protected] yep! I was responding to using a matrix chat room.
I'm all for a task force on this.
Ricardo Ferrer RiverošŖšŗ
julian
Evan Prodromou
infinite love ā“³
Ben Pate š¤š»
Sebastian Lasse
dansup