Making the case for richer HTML in ActivityPub
-
Also summarised as "federation happens in the client"
-
@laurenshof @julian @johnonolan @mike I really hope that by "rich content", you mean "structured content" (headings, images, lists) not "formatted content" (font size, font colors, alignments). While I would accept the firsts, we should reject the seconds in both the standards and the apps: i don't want to live with people poor choice about fonts and colors (theming and accessibility will be issues).
-
@jupiter_rowland For the record my perception of the fediverse is that it is the open web of all people, content, apps, services and websites that have federated or bridged with ActivityPub.
-
@julian @johnonolan Iād love to learn more about this!
-
@mikedev @silverpill yeah JavaScript in your stream would be problematic.
It would be interesting to figure out a safe and standard way to provide limited interactivity on the level of things like polls. Farcaster seems to be experimenting with ideas like this though i have not looked at it closely.
-
@mikedev @silverpill it might be time to dust off the OpenSocial spec and consider how this could work in stream. I don't think arbitrary JS is a good idea, but it might be interesting to have user-installable widgets in a sandbox.
-
@[email protected] I think even @[email protected] could agree that Mastodon has done the bare minimum of support. They used to only support straight text (and even now, composing in Mastodon is plaintext only), but have since allowed a heavily locked-down subset of HTML.
Allowing arbitrary JavaScript execution is a bad idea, but relaxing html sanitisation to the minimum would allow for much more expressive content. Inline images and tabular data are two tags I'd like to see allowed, but herein lies the problem... What subset of HTML do you feel comfortable with? I wager that different implementers would answer differently, and Mastodon eschewing certain tags in order to prioritize the textual microblogging style is their choice, too!
The fact of the matter is Mastodon needn't support all the tags under the sun, but they do need to acknowledge that received content is not faithfully represented in all cases, and so a prompt to view the content on the original site would be a good intermediate step.
There already exists an ActivityStreams object type for this kind of content:
as:Article
. It gives other implementers a chance to explicitly say "hey, this might be better viewed natively if you don't elect to show everything we send you". I'd love to make this a reality. -
@mike @mikedev @silverpill the design we built into AP is to make external apps that use OAuth 2.0 and the ActivityPub API to interact with your account.
https://evanp.me/2024/04/22/cross-server-interactions-in-activitypub/
-
@evan @mikedev @silverpill Federated start pages? Getting Netvibes vibes here
-
@julian @johnonolan @mike the origins of ActivityPub is Atom, which had the name/summary/content split, and we preserved that through the various Activity Streams iterations, from Atom to JSON to the current JSON plus LD.
Mastodon undermines this by ignoring post names and treating summary as a Content Warning.