Untitled attachment

Notices where this attachment appears

1. Embed this notice
   arcanicanis (arcanicanis@were.social)'s status on Sunday, 04-Dec-2022 08:15:11 JST arcanicanis

   in reply to
   One difference is that Twitter doesn't have to educate it's users about federation since it's centralized, so there will always be that requirement out of a fedi user to at least cognitively handle that concept; if they can't handle that, then you're just trying to appeal to the most fickle person who will likely never be won over.
   
   It shouldn't need a tutorial or extensive guide, the only requirement anyone should be expected to know (or all that should be explained) is just: anyone can be on any server and still interact between each other. If you want to interact with some post or user on another server's website, just copy/paste the URL of that webpage into the search of your instance's website (or mobile client), and it'll be able to decode it and give you options to reply/follow/whatever through your account.
   
   The thing I think needs to be improved amongst instances is of providing a redirect for any ActivityPub requests to a post that's actually from a remote server (e.g. https://example.com/@user@someotherhost.com/posts/abc123). There should be a simple conformance test for server admins, and a 'how to' for each server software to iron that out, as well as any backend fixes necessary. THAT is the bigger thing of UX issues, because it feels unnecessary to train users what URLs are 'bad URL' and which ones are 'good URL' (to click through the post, and find the URL of the origin server, and then copy THAT into your search instead). That is the biggest thing to fix over any frontend issues.
   
   As for interactions starting from a remote server, some of that can add unnecessary complexities and slower experience (e.g. the 'remote follow' workflow of typing in your WebFinger ID, authenticating, action confirmation, etc). There's not a lot available to simplify it without expecting browser extensions or similar.
   
   The only thing that could be done is designating a protocol handler URI scheme, such as 'web+activitypub:' for remote actions, whereas if a protocol handler is detected as registered, it'd provide a URL to invoke that handler instead. E.g. you could have a Soapbox install (or pleroma-fe, or whatever) register as a handler for 'web+activitypub:' URIs, thus when someone's on a remote website and wants to follow someone from the remote website, they could click a link that points to say 'web+activitypub:action=follow;resource=https://example.com/users/bob' (or whatever formatting) which would kick them over to their instance, and give them the option to just click 'confirm', versus typing in a WebFinger ID and a longer follow. The only thing is that it'd only be useful if you only use a single account, since it'd be bound to handling any of those custom URIs at one instance.
   
   (Although I'm sure it'd be possible to create an interaction flow to 'register' a list of alternate accounts to choose from, to hop to from the instance that handles a 'web+activitypub:' URI, for multi-account use-cases).
   https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler/Web-based_protocol_handlers