Article vs. Note (redux!) — summary of current implementations

At the last ForumWG meeting, we discussed at length about Article vs. Note, and whether there was a desire to expand usage of as:Article. You can review those minutes here.

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.

You can see the results of the summary here.

What is less clear is whether there is pent-up demand for use of a different data type for more richly forrmatted content. and provided some very illuminating history behind previous attempts to use as:Article, but importantly it seems that Mastodon (via 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?

1 Like

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.

1 Like

I would actually really like to use Article to encapsulate rich multi-page and potentially mixed-media content. For example, think of the 1609 project website.

Or imagine an academic paper where you could bookmark, comment, and share subsections of the document. Like the abstract, diagrams, and conclusions.

Which is not to argue against accepting a larger html subset. Just not to make that the limit of our imagination.

@mikedev @jupiter_rowland @renchap

1 Like

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.)

2 Likes 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.



Article = rich content, embedded images, videos, and other media.

But how embedded images should be treated by implementations that use media cache? Are they expected to rewrite src attributes in images?

@jupiter_rowland @renchap @mikedev

@silverpill @jupiter_rowland @renchap @mikedev @julian

Socialhome supports inline images in posts. Are those as:Noteor as:Article?

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.

@tallship I don't know. Could you provide an example of such post?


Could you provide an example of such post?

I believe 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.


@silverpill @julian

Silverpill wrote:
> Could you provide an example of such post?

Here you go bro: Socialhome post w/inline 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 :)

#tallship #inline_media