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.
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.
@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.
This is possible as just answered to Julian but someone needs to fix the consent issues in the browsers (shown in posted demo video) which is nothing we can do …
@benpate @julian @ricferrer @trwnh
PS History continued, two years later, in 2019 I sponsored the first offiial ActivityPub Conf https://conf.tube/c/apconf_channel/videos and in the Prague dox museum we had a short session where we said to talk to the browser people again in some years. The 2020 Conf was fully packed and then I was personally overloaded with the EU DMA/DSA consulting (disclaimer; invited expert but all voluntary) …
But maybe that time would benow - at least in the interest of accessibility …
[Jake Archibald and Jenn Simmons and more browser makers are meanwhile in fedi themselves …]
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.
@benpate what are your thoughts on matrix? I am considering using it in a product I am working on and would love to know why you don’t like it 🧐
I’ve been testing Element X and haven’t found many issues.
While I do have some gripes with notifications and threaded discussions in the Element client…
My loathing of Matrix is less about the technology, and more about having yet another place to follow discussions. I can only follow so many separate places to have discussions, and matrix doesn’t seem to add much value.
I’d much rather try to make discussions work better HERE, instead of moving everything over to Matrix 😇
@benpate
Off course not, this would be even illegal in the EU.
[edit] I am super thankful for the FEP!
It is just that I am (at the same time) super frustrated about the browser makers, acting as gatekeepers in the context of Open Protocols.
As the elected Policy Lead, I advised the EU about „federating systems“ in the DMA/DSA. Nothing of this is covered by the law currently.
The idea is super old and dead simple.
https://developer.mozilla.org/de/docs/Web/API/Navigator/registerProtocolHandler
The "limited available" and the calculated "bugs" in the support makes me sad.
As user: If it is my private computer, I want to be able to store the "me" in the browser, that is primarily my fedi handle ot url … … …
Then it is possible on any webpage to share any ActivityPub item from my account by just a click without revealing my identity directly. This should really be a task of the browser. Mozilla Persona was a nice idea as well until they sent the team to create games which nobody played.
Also, you can see this running right now on bandwagon.fm.
You can remote follow right from a band page, or even from a page of search results.
This works with just about any Fedi server by polyfilling the oStatus remote follow logic
If you’re in an #Emissary server you can also do remote likes, too
Could you try out the workflow I have in place right now? My goal is to expand this, make it all JS (no server-side required) then package it for everyone
@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.
👉🏻👈🏻
@benpate what mastodon and piefed and browser.pub do, basically.
open a link like https://browser.pub/https://mastodon.social/@benpate/116025296487246556 and then click any of the other links. you should remain in browser.pub.
Ricardo Ferrer Rivero🇪🇺
julian
Evan Prodromou
infinite love ⴳ
Ben Pate 🤘🏻
Sebastian Lasse
dansup
