thisismissem@hachyderm.io Not to worry, in maybe a decade we'll upgrade to handling square objects and squircle objects too!

@thisismissem I see, thanks. So in theory, "Event" objects as defined in ActivityStreams should be easy to federate if two platforms actually support it?

freddiej@newsmast.social yes (sorry to butt in) — an example would be as:Page and as:Article. Threadiverse softwares like Lemmy, Piefed, and NodeBB handle this fine, showing title and content with the appropriate attachments, but in Mastodon they currently get collapsed into just the title and URL, as that is the current fallback handler for objects that are not notes.

cc thisismissem@hachyderm.io

@julian @thisismissem Hi Julian, no worries, thanks for the clarification. I had thought this was the case from when I attended the early Threadiverse meetups. Looking at the AS spec, they support loads of complex objects it would be great to see supported more widely in the Fediverse (like events) and just wondered what the barrier to adoption might be?

@FreddieJ yes. As long as you agree on what the properties mean, and activities performed on them, then you'd be fine.

kopper@not-brain.d.on-t.work you're not wrong about that, and it's why awhile back I changed my stance on it for that exact reason.

I don't think it's wise to advocate for Mastodon to support other object types because what they're mainly interested in is converting as:Note (and sometimes as:Video and as:Question) into statuses.

What's really of concern is that Mastodon's fallback mechanism should handle non-Notes better, because the experience has degraded to the point that it is incentivising other software to "just send notes". The key is to raise the baseline of the fallback handler so that it is no longer a degraded experience. That's all.

@kopper so I'm not saying everyone should support everything, in fact, it's perfectly fine to have a decentralized ecosystem where one account enabled you to publish multiple different things.

Striving for interoperability with just the dominant software in the protocol doesn't result in good outcomes. It results in a reduction of interoperability.

@kopper right, I think we're saying the same thing overall. But everyone wants ideal compatibility with Mastodon, which then acts as a forcing function on them needing to support more things, which isn't great because obviously limited resources.

The goal seems to tend to be "interoperability with Mastodon" not "optimal federation via ActivityPub"

@kopper @thisismissem in a more sensible world, interoperating with mastodon would use a vocabulary that more closely describes what mastodon is actually doing. like, if mastodon operates on "accounts" and "posts" then why not use a standard vocab that actually call them that? activitystreams was built on "activities" and "actors", which is a semantic mismatch for mastodon's model (activities are unwrapped for their side effects and then discarded, instead of being rendered directly)

@julian @kopper the world if we used sioc:UserAccount and sioc:Post instead of as:Person and as:Note (or heck, toot:Account and toot:Status... or atom:feed and atom:entry...)

or alternatively, if people used activitystreams to actually model social activities...

i've come to the stance that activitystreams trying to spec out vocab for Note and Article and so on was a distraction from what it was actually trying to do. it should have reused existing vocabs for that stuff, or left it unbounded.

@thisismissem https://mastodon.social/@trwnh/110043428576595588