One of the action items that came out was to collate the state of current implementations. Unfortunately, outside of implementations that federate non-textual content (e.g. Pixelfed Stories, Mobilizon Events, etc.), the majority of implementors just use as:Note, which is not surprising given Mastodon's treatment of non-Note objects.
What is less clear is whether there is pent-up demand for use of a different data type for more richly forrmatted content. @mikedev@fediversity.site and @jupiter_rowland@hub.netzgemeinde.eu provided some very illuminating history behind previous attempts to use as:Article, but importantly it seems that Mastodon (via @renchap@oisaur.com) may be open to supporting this in some form as well.
While Mastodon has every reason to display as:Note as it sees fit, I'd like to hopefully address the undue influence towards using it especially in instances where as:Article were more appropriate. Mike (upthread) suggested a compromise:
that as:Note be reserved for content with attachments (images or otherwise), perhaps with a limited subset of html
and as:Article be used for content with a richer set of html (e.g. tables), and including the ability to display inline images
I explicitly did not specify that Note was for shorter content and Article for longer, because there exist plenty of examples of the reverse.
Does anybody see potential complications from such an arrangement?
That’s basically a mixture of the official ActivityPub definition and how it’s implemented. Article-type objects mostly come from dedicated long-form blogging applications anyway.
The main hindrance that keeps devs from implementing as:Article is Mastodon’s refusal to implement full HTML rendering. Once an elaborate post from e.g. Plume or WordPress or Hubzilla can look basically the same on Mastodon and “at home”, once applications that can produce such posts no longer have to convert embedded images into file attachments to at least save four of them from Mastodon’s HTML sanitiser, more devs will be willing to implement Article-type objects.
At that point, the biggest complication, I guess, would be how to implement a switch, if at all. Friendica’s switch is the title field which is kind of nifty and doesn’t inflate the UI, but unfortunately, next to nobody knows about this. Hubzilla 9.0 tried a switch for the entire channel with no way to override it per post which I think is kind of cumbersome. Depending on how which project will implement Article-type objects, you might want to be able to fall back to Note-type objects in certain cases.
And truth be told, I myself might be the only one outside of Mastodon who doesn’t mind Mastodon turning Article-type objects into links. That ensures at least that everyone will see them the way they’re intended to look without being at the mercy of some 3rd-party UI.
I think the distinction that makes sense to me is still “do you intend for this to be formally published or not”. Length and formatting are red herrings. The entire Note vs Article “distinction” is literally just “tweet vs blog post” in how it came about. From the perspective of a service like Twitter or Facebook, the Note indicates it’s a “status update” whereas the Article indicates it should be shown/presented in their article publishing feature (which Twitter ironically called Notes).
Consider this litmus test: if viewing the object at a permalink, does it make sense on its own, or do you need more context? If you need more context, it’s probably a Note. If it makes sense on its own, it’s probably an Article. (Note that this doesn’t prevent Articles from having a context property.)
@trwnh@socialhub.activitypub.rocks even that has it's own exceptions. This very topic's OP was meant to be a reply to the original Article vs. Note vs. Page topic, but I decided to make it a standalone topic for tagging purposes.
That's why I still feel that we can use simpler heuristics based on content to determine whether one ought to use Article or Note...
But a part of me worries that we're heading down this road trying to figure out whether we can heuristically determine an object type, when we should be asking whether we should.
We shouldn’t, in general – the difference is one of formality and intent, as I tried to explain above. The litmus test I described is not a hard-and-fast rule, but it gets at the core of the issue more closely than most other tests. I realize there’s a bit of exception where the object is “top-level”, and you could also write an entire Article in reply to a Note. But a Note is largely intended in context of your profile’s feed of status updates. You’re sharing something informally among other informally-shared things. Only when it rises in formality do you make it an Article. I’m not sure what the threshold or exact definition of formality is, but it ultimately falls to the user and not the software to make that decision. Even if the user’s choice is something like “I will use my blogging software to formally reply to this” vs “I’m just making a social media post,”. The software could be multimodal and support authoring both Notes and Articles, also.
@tallship @silverpill Friendica, Hubzilla and (streams) support inline images in everything. But they don’t use media cache because they themselves embed their images from their built-in managed file space.
Friendica sends posts as:Note when they have a title and as:Article when they don’t, so it supports both. Hubzilla and (streams) could theoretically send both, but they only send Note-type objects out of protest against Mastodon’s refusal to render Article-type objects to their full extent.
I believe @tallship@public.mitra.social was referring to the fact that the software itself supports inline images locally. Well, sure, who doesn't? (Except for Mastodon lol)
The problem lies with everybody federating as:Note out because Mastodon doesn't render content otherwise, and also that all images are stripped out unless included as attachment, and only then, in reverse order with a cap at 4 images.
I'll try to give it a boost from my #Mitra, #Hubzilla, and #Friendica accounts too (if I haven't already) so you can study/compare the various treatment cases :)
Sadly, I have not yet launched streams yet for study. I know, I'm a lame-O. I'll get to it shortly, prolly just spin up a local VM on Proxmox for that here, I really am anxious to give it a go :)
I’m still catching up on the whole discussion, but I’d mention that WriteFreely sends out Articles by default, with a config option to send Notes instead.
I’ve experimented with automatically falling back to Note if a post has only one paragraph, but agreed that’s not a great distinction. (And I don’t think an automatic switch should be needed for a platform like ours.)
Definitely inclined to agree with @trwnh that intent makes the difference. Since WF is meant for blogging / long-form, where each Actor has a unique webpage, Article was the easy choice. The hope was that other platforms would figure out UX on the other end eventually.
Thanks @thebaer@socialhub.activitypub.rocks! That's good feedback and it's really exciting to know that there exist implementors out there whose default is not Note.
I think at this point a real-time discussion at the next ForumWG re: the distinction between Article vs. Note would be beneficial. It'd be a continuation of the discussion we had last month.
It's clear there are varied opinions on it, but as intimated by others, this might not actually be a problem that has technical solution.