– DRAFT –
Browser experience of ActivityPub social networking

<bumblefudge> blarg forgot to write down the zoom ps

<bumblefudge> pw

<eprodrom> https://www.w3.org/events/meetings/3c15ca06-8876-442e-a385-8eab2b64a55c/

<bumblefudge> at _least_ one wg! hehe

eprodrom: (going through the slides, going over what ActivityPub is, and a few of the browser experience challenges)
… main challenges: following (or interacting with an Actor profile), interacting with a post (like, etc) on a different server pops up complicated UI of "let's get you logged in on your home server"
… what are some ways to improve this? Outlined in: swicg/activitypub-html-discovery
… `url` property, Link Header, Content Negotiations
… sets up two-way linking between an HTML page and the JSON-LD data object
… step 3: ActivityPub API client in the browser
… Why? 1) gets credentials from home server, 2) Uses them throughout the web, 3) Does not lose context moving from server to server, 4) Re-centers the social web on the person at the keyboard
… How? 1) Browser extensions (SocialWebFoundation working with Vivaldi). (Focus on Vivaldi first - they have their own Mastodon server). Many other browsers use the same architecture for extensions
… UX challenge: a browser extension would add their own Follow button, but the HTML page still has the original Follow button too
… possible fix: Declarative format for some activity types
… "This button is for following the person referred to by this page"
… (this way, extension can recognize that element, capture the click, etc)
… Another option: Provide a JS API for the browser. "navigator.social.follow("evan@..."))"
… yet another: better support for the 'acct:' URL format (used by Webfinger)

<bumblefudge> doesn't better support for webfinger URIs mean a protocol handler that browser extensions and/or external apps could register?

<bumblefudge> by analogy to mailto: links?

<bumblefudge> ah ok, one less hand to raise, haha

bumblefudge: what are the most desired kinds of feedback (from the group on this call)?

eprodrom: to start with, "did those slides / this conversation make sense in general?"
… as in, have you run into this UX friction. Other suggestions for alternate solutions, etc
… is there other work happening in this area?

aarongray: I'm looking at an Electron solution (a node running behind a browser)
… I know it's an install solution...
… I haven't looked at the AP HTML Discovery doc yet -- will it work on a domain/subdomain etc, via regex?
… (path based)

eprodrom: yes, it should

<eprodrom> https://docs.google.com/presentation/d/1qr_rDgdWPR9yZjg_PyjTNJqs3x6-nKXzIYtwtUkip1Q/edit?usp=sharing

<pfefferle> but sadly custom-protocols are not really widely used/supported

dmitriz: I like this work, going in the direction. we may want to create a JS polyfill for the API
… I know the main friction is the acct: protocol handlers in browsers. I wonder if we can start with 'web+acct:'?

eprodrom: yes, in fact this demo here does exactly that!

<pfefferle> it is not supported by every browser and mastodon removed it because of the "bad user experience"

eprodrom: so we can start web+acct:, and also work on improving support for the RFC's acct:

bumblefudge: this reminds me of the declarative payment link approach that the cryptocurrency community experimented with over the years
… Ethereum did the Browser API route (vs declarative).
… you can sort of think of the acct: extension as an identity wallet. a separate agent, a trusted extension
… in the Crypto space, what happened with the window.ethereum polyfill -- it was designed (a little too) trustfully -- a bunch of extensions have a race condition to capture the polyfill's invocation
… extensions try to impersonate each other.
… basically, in the end, Metamask abandoned it as irrecoverable.
… instead, they're using to Manifest v3, basically being able to reference each extension (like Metamask) by a hash or signature
… It won't be as bad in the ActivityPub space, but it's just one data point
… the browser and page needs to be able to know exactly which polyfill / extension they're talking to

eprodrom: yes. challenge here is - there's a tension between the website and the extension, as to who can control the experience
… we know the Web is the wild wild west etc
… so of course we'll need to build in the necessary confirmations / guard rails
… other questions?

<bumblefudge> (here the analogy to crypto wallets is good, because the webpage needs confirmation/error handling from the agent BUT WITHOUT DEANONYMIZING IT)

aarongray: I'm not familiar with the 'web+' notation

eprodrom: yes, that gets into the world of registering custom protocol handlers

bumblefudge: out of curiosity -- I know WebFinger predates ActivityPub. what sort of use case did they intend, for the acct: handler?

eprodrom: I think a general account URL type

<eprodrom> https://datatracker.ietf.org/doc/html/rfc7565 for acct: URI scheme

eprodrom: if there are no more questions, we can wrap up!
… So, we have a task force focusing on discovery,
… but we don't have a TF for in-browser experience in general
… so that might be an area to explore
… things like the declarative markup, JS apis and polyfills, etc

dmitriz: I think that's a great idea. We can also widen the remit of the Discovery task force to be 'Discovery + Browser Experience'

eprodrom: yeah, it's the source of much tears in implementers.
… there's some good prior art and patterns we can follow already, such as those used for RSS Feeds
… that we can incorporate into this work

<marie> thank you evan and dmitri