Mastodawn

julian Feb 5

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

ActivityPub Discovery

Ricardo Ferrer Rivero🇪🇺Feb 5

@julian @rimu @evan isn’t an URI scheme the way that would offer fastest compatibility? after all it’s been around forever, most browsers just let the OS handle it and even apps like zoom and iTunes have successfully implemented it for their service 🤔

Evan Prodromou Feb 5

@ricferrer @julian @rimu We already have an URI scheme for ActivityPub objects; it's https: .

Ricardo Ferrer Rivero🇪🇺Feb 5

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

Ricardo Ferrer Rivero🇪🇺

@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

@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?

@ricferrer @benpate @evan @julian @rimu in any case the thing all fedi apps can do "right now" (without any ecosystem changes otherwise) is to try to load all https: links locally before kicking users out. this is at least half of the problem solved right away.

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.

https://pixelfed.social/p/dansup/857331714672549664 · BrowserPub · A browser for exploring ActivityPub and the fediverse

Explore the open social web through the lens of ActivityPub and the fediverse.

@trwnh Thank you. I understand what you’re saying. They’re rewriting links in the post to keep you on that site. I’ll need to keep this idea in my toolbox.. it will be useful.

@benpate @trwnh it’s basically using browser.pub as a webclient or activity viewer, right?

If I understand correctly it doesn’t solve the problem that I am logged in in my app and not in the browser

@trwnh @benpate @evan @julian @rimu totally agree. That’s the “easy” part

Then there is the other way around… going from the browser to a fedi client instead of a website if I have an app installed

And I thing this “other way around” — going from a remote server to your home server — is the most important use case.

Let’s lock this down and get “share” buttons everywhere.

@ricferrer @trwnh @evan @julian @rimu

@benpate @ricferrer @evan @julian @rimu if you never leave the app then the "other way around" basically never presents itself at all

but really, how hard is sharing a link? doesn't seem hard!

content handler is best in the long term but in immediate term there are still many ways to do this...

You’re right.. ONCE YOURE IN the ecosystem, it would be easy to just stay there. But how do you get into it in the first place?

Most interactions will START out there in the open web. We need to make a smooth on-ramp for newbies to find us first.

That’s why web -> fedi matters so much.

@benpate @ricferrer @evan @julian @rimu right, so...

- here's a link that you won't know how to open
- go sign up at one of 100,000 servers before you can open it
- do all that and end up with basically just a share button

is a really bad ux, isn't it? i mean, it annoys me so much when people share matrix.to links for this reason...

@benpate @ricferrer @evan @julian @rimu if i'm already in my browser i don't want another browser. the "open web" IS the platform. that's where the interactions SHOULD be happening... and could be with a bit of work.

I agree with this 100% and I think this is what I’m pushing for :)

@trwnh @benpate I agree. It should always be web first. But for those that made the leap, choose from the 100,000 servers and have an app, we shouldn’t make them relive the trauma 😁 by asking them to log in on every instance where they just want to either follow someone or like something

Imagine i send you the link below through signal. It opens in the browser or webview. If i want to follow them all, i have to log in x times https://joinfediverse.wiki/Notable_Fediverse_accounts

Notable Fediverse accounts - Join the Fediverse

@ricferrer @benpate right now, if you link me x accounts and i find n interesting, i copy-paste n links (n <= x) into my fedi address bar (search bar) to access them in my "layer 2" browser-in-a-browser

i am not entirely convinced it would be better for every page to have to publish 2x links as opposed to publishing x links and you copying n links. 2x > x + n

what could be improved is opening n links in a different app (pwa included) but you can't avoid that unless you make your browser auth'd

Yes, that would suck. But it’s not what I’m suggesting. More like:

1. On a web page with cool content
2. Click “like” or “share” button
3a. Already identified? Jump to your home server, confirm the action, return to page
3b. Else, click “join now” to sign up on a recommended server for this content. Bonus pts for keeping the intent context around and completing the “like” once you have your new account.

This would help more people explore the Fediverse.

@benpate i think 3b is where my issue is -- the solution for me looks a lot more like

1. on a web page
2. click share (in js or in browser)
3. your browser or os sends some stuff to an app of your choice you already have (including registered pwa targets)

bonus: filter share targets by content-type

@trwnh That would be ideal, once you have the app. But if you don’t already have an app installed for this, how do we onboard new users? That’s the most important part, for me.

I’m starting to think there’s some hybrid approach that will just do everything. Hopefully it can all be “containerized” in a JS widget that lets website designers KitKat drop a widget in their page and then it’ll just magically work 😇

@benpate how do we get people to use fedi without an account? ;)

@trwnh sorry. What I mean is: the “share” and “like” workflows are gateways to the signup process.

If someone already has an account, use that.

Otherwise, give them a big orange button that goes directly to a signup page — no awful “instance chooser”, but that’s another conversation.

With Activity Intents, all the real work happens on your home server so we don’t need you to “sign in” on the remote server; just declare where you’re going to go when you want to interact.

@trwnh @benpate
The issue with PWA targets afaik is that they are like universal/app links -> bound to a domain

Apps from different vendors can pick it up (it’s only a problem if you have more than one on iOS, Android lets you choose)

For 3b to work you would need to tell the page with the content which one is your home server every time for every content

Do you use a browser for the fediverse mostly or an app? I am 100% app 😎

@ricferrer @benpate the app is a browser too but i mainly use either firefox or subway tooter

@ricferrer @benpate the "end goal" for me is to have them discriminate by content type so i can open pdfs in my pdf viewer and activities in my activity viewer :)

“For 3b to work you would need to tell the page with the content which one is your home server every time”

Not quite. FedCM solves this. And in the interim, we can put this in localStorage so you only need to enter your handle once per domain. And even that can be reduced if all the JS widgets are served by a shared location.

I’m 70/30 app/browser. I used the browser, for instance, when traveling internationally so I don’t have an app signed in to my identity.

But I’m not the target audience. I’m already sold. The main reason to put open web first is to give an on-ramp to newbies who would join us if we made it easy enough 😇