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. @[email protected] and @[email protected] provided some very illuminating history behind previous attempts to use
as:Article
, but importantly it seems that Mastodon (via @[email protected]) 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 whereas: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
-
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 implementingas: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. -
@julian
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. https://www.nytimes.com/interactive/2019/08/14/magazine/1619-america-slavery.htmlOr 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.
-
julian: 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? 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.)
-
@[email protected] 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.
-
+1
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? -
Mike Macgirvin 🖥️replied to silverpill on last edited by
"But how embedded images should be treated by implementations that use media cache? Are they expected to rewrite src attributes in images?"
That's what we do today. Would be interested in alternative approaches. We don't even try and cache audio/video. -
@[email protected] @[email protected] I'd recommend we discuss the merits and complexities of media caching separately, if only because I'm certain we could bikeshed that one for days!
-
tallshipreplied to silverpill on last edited by [email protected]
@silverpill @jupiter_rowland @renchap @mikedev @julian
Socialhome supports inline images in posts. Are those
as:Note
oras:Article
? -
Mike Macgirvin 🖥️replied to tallship on last edited byI think they're as:Note just like streams. Hopefully we can soon move them all to as:Article like I proposed 7-8 years ago and everything will look as the authors intended and everybody will be happy.
-
julian: 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 postsas:Note
when they have a title andas: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. -
-
Could you provide an example of such post?
I believe @[email protected] 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 rendercontent
otherwise, and also that all images are stripped out unless included asattachment
, and only then, in reverse order with a cap at 4 images. -
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
.
-
-
I'm still catching up on the whole discussion, but I'd mention that WriteFreely sends out
Article
s by default, with a config option to sendNote
s 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 @[email protected]! 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.
-
J julian referenced this topic