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.
-
@wakest there's an RFC for `acct:`
RFC 7565: The 'acct' URI Scheme
The 'acct' URI Scheme (RFC 7565, )
IETF Datatracker (datatracker.ietf.org)
@evan @wakest rfc 7565 describes how acct: is not resolvable, although web+acct: doesn't have this problem if you define it to use webfinger.
also i'm not sure about the browser UX but instead of a new uri scheme the typical solution here is actually content-type handlers (see firefox screenshot for example)
an http resolver SHOULD dispatch the content to the appropriate handler according to its content-type
"i'm not logged into my browser" is the issue, not "open a browser in a browser".
-
@evan @wakest rfc 7565 describes how acct: is not resolvable, although web+acct: doesn't have this problem if you define it to use webfinger.
also i'm not sure about the browser UX but instead of a new uri scheme the typical solution here is actually content-type handlers (see firefox screenshot for example)
an http resolver SHOULD dispatch the content to the appropriate handler according to its content-type
"i'm not logged into my browser" is the issue, not "open a browser in a browser".
@evan @wakest see also https://browser.pub/ and so on
- html content goes to an html viewer
- pdf content goes to a pdf vieweractivity+json content could go to an activity viewer
-
@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 vieweractivity+json could be opened in an activity viewer. see firefox for example in pic 1:
-
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)
I understand the need to link back to an app. It’s important, but I’m voting for the open web.
All the search and discovery interactions *should* start out on a website somewhere, then link back to your home website (or possibly an app) to share and like.
But, using a new URL scheme will lock out everyone who doesn’t have an app installed, and that’s a bad UX.
Plus, I think we can solve this “back to my server” issue in other ways WITHOUT needing a URL scheme, like: #FEP3b86
-
@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 vieweractivity+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.
-
@rimu@mastodon.nzoss.nz @ricferrer @julian @rimu@piefed.social @evan this is the way for web frontends, which are effectively "browsers in browsers".
if you are starting with a link in your "level 1" web browser, you need to copy it into your "level 2" web browser. https://www.devever.net/~hl/webappcoupling
-
@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 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
️ -
@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
@ricferrer @evan @julian @rimu if we say that every resource needs *two* identifiers, one to open in a "https" browser and one to open in a "fedi" browser, then why? what happens if someone copies the "fedi" uri outside of the "fedi" context, and the other person doesn't have a "fedi" uri handler on their system? that link becomes useless. not everyone is going to know to copy the "correct" link, or that the "incorrect" link can be rewritten.
-
@ricferrer @evan @julian @rimu if we say that every resource needs *two* identifiers, one to open in a "https" browser and one to open in a "fedi" browser, then why? what happens if someone copies the "fedi" uri outside of the "fedi" context, and the other person doesn't have a "fedi" uri handler on their system? that link becomes useless. not everyone is going to know to copy the "correct" link, or that the "incorrect" link can be rewritten.
@ricferrer @evan @julian @rimu which is more realistic: that literally every application in the world need to start recognizing "fedi" links, or that existing fedi applications start opening https: links locally ("in-app") where possible?
-
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!) -
@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
-
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.
-
@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
@ricferrer @evan @julian @rimu fb twitter instagram etc are also centralized single entities, so there's no contention on who gets to open the link.
-
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...
-
@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...
@benpate @ricferrer @evan @julian @rimu there's a shortcoming where mobile browsers don't let you install web extensions as easily but that can also be overcome i think.
-
@benpate @ricferrer @evan @julian @rimu there's a shortcoming where mobile browsers don't let you install web extensions as easily but that can also be overcome i think.
@benpate @ricferrer @evan @julian @rimu native apps can also expose share targets so you can "share" the current web URL to those apps and it opens in those apps.
-
@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...
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.
-
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.
@benpate @ricferrer @evan @julian @rimu i'm not entirely sure why it's POST proxyUrl instead of GET proxyUrl but i think it has to do with leaking metadata iirc
-
@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 of course. There are several nerdy and probably cleaner ways of doing it. But requiring the user to install an extension is the first mistake on the path to wide adoption. I think sometimes a more pragmatic approach can bring the best results, if the goal is to get most people to the fediverse and not have the most elegant solution from the the start or nothing
