Conversations and Articles

One of the ambiguities in the ActivityPub spec is the distinction between a “note” and an “article”. No developer seems to be clear about how the two should behave, or how you can tell the difference between them. Candidate criteria include:

  • Articles are longer, like 3 paragraphs
  • Articles have titles
  • Articles have more formatting
  • Notes are expected to last a short time

None of these are really definitive or actionable though. So, I suggest this distinction as being the most important:

Articles are intended to be read on their own. Notes are part of a conversation.

I think this is neat, because so much of what people propose falls naturally out of this definition. In particular, the way “article” sounds like a blog post, whereas “note” sounds like Twitter, is very well captured. What’s more, the UI requirements also become more clear.


There is one critical aspect of a conversation that distinguishes it from most writing: in a conversation, you have to give the other person a chance to speak. If you jump into a conversation and rattle off six paragraphs of soliloquy, people will think you are an asshole. It is important to express yourself succintly so that you don’t take up too much time before the other person takes their turn.

This also means you don’t repeat things that have already been said. You start right off by saying “the problem with that argument is…” and then get to the point. Everyone was there when it was said the first time. Everyone remembers.


An article is designed to be read whenever the reader has time. It may be part of a wider back-and-forth between participants, but you can’t expect that the reader has the previous text entirely in their head when they start reading.

So you need to get them up to speed. You summarise previous arguments. You might quote entire passages. You give explicit references, so they can dig out the previous article and refresh their memory. You take the time to build up an argument that stands on its own.


With that in mind, we can see what makes Twitter distinctive. We all know Twitter is that weird service that limits you to 140 characters (or used to). But the true distinguishing characteristic is that Twitter is about public conversations.

There are many systems that lend themselves to conversations – we call them instant messenger apps. But these are designed for conversations in private, not for the whole world to see. They don’t limit the number of characters in a message, because they don’t need to. The context enforces the conversational style. Because your audience is limited, it is natural to type something short and simple, without polishing. Because it is instant, anyone reading that message is reading it in real time, and has the context in their head.

Twitter puts everything you type out there in public for all to see, including much later when the context has disappeared. So the natural tendency is to polish and refine what you write, to qualify it and buttress your argument with sources. Normally that would mean more text, and the end result is an article. A blog post. Any service that makes your messages public will therefore eventually evolve a bloggish culture, with an alienating and formal tone. And that’s been true since Usenet.

But Twitter forces you to compress your thoughts into 140 characters. By doing so, you implicitly invite other people to add their response. And a conversation is born. A conversation is always far more engaging than an article, because as a reader you are invited to actively participate. So Twitter is addictive in a way that other platforms haven’t been able to replicate, even though Facebook and Instagram are far more popular.

The reason Twitter limits tweets to 140 characters is pure accident. Twitter grew out of services to broadcast important SMS notifications to activists at protests. SMS was limited to 140 characters. Unintentially, this led not to a broadcast system, but to a highly engaging and addictive public conversation platform.

Of course people still want to start conversations with more complete thoughts. That’s how we ended up with the awkward Twitter thread convention. But despite this resistance against the constraints of the platform, even interminable rants are still broken up into individual tweets. Each of those acts as an invitation to start a separate conversation.

Quote Tweets

The argument over quote tweets also reinforces the point about conversations. Mastodon developers refuse to implement quote tweets because it has been such a vector of abusive behaviour on Twitter.

Quote tweets are such a problem because they take individual statements out of an ongoing conversation and present them stripped of context. Without that context, no tweet can possibly be fully understood. And so people jump to the worst possible interpretation.

But quotes have always been a staple of articles. They are often abused, but the use of quotes as a technique is never considered problematic. More usually they are considered essential, and a mark of respect. In an article the context is usually missing in the first place. It is up to the author to fill in the context for the reader.

That is why more bloggish ActivityPub implementations such as Friendica have uncontroversially had explicit quote support since forever.


So here is a list of the differences between articles and notes, and how they flow from the above definition:


Articles must re-establish context for the reader, and this takes space. So articles have to be long.

Notes must be short to provide a chance for the other participants to respond.


Reading an article is an investment. Readers need metadata to decide if they want to read the article at all. Titles are crucial for this, as are other affordances like abstracts. You can also prominently see the author, perhaps even a short bio, and the publication date, since these also help you decide if the article is worth reading.

In a conversation, all the participants know what they’re talking about already. They don’t need a title specifying the topic. They also know who’s speaking and when (“now”). They’re already part of the conversation, so these affordances only get in the way.


The length of articles requires paragraphs and often headings, to structure the text and give the reader a chance to pause. They include quotes, which should be distinctively presented in order to separate the author’s voice from other voices. The complexity of the argument often requires several visual illustrations.

To keep a conversational style to notes, they must imitate speech. Speech has few cues analogous to headings or quotes. Speech does, however, have emphasis, and formatting to indicate emphasis is useful.


Articles are too long to be read immediately on publication. Frequently they go into a queue to be read when the reader has time. If they are a response to another article, the time to compose the reply separates the two. Furthermore, having gone to the trouble to write such a long piece of text, it is frequently worth referring readers back to old articles long after the original publication.

Notes are parts of conversations and rely on context being actively provided by the other participants. When the conversation stops, the context usually disappears too. The conversation will likely make no sense months after it took place, and could well be actively harmful. If a note is archived, it should always be archived together with the rest of the conversation.


An article is written so that it can be read in isolation. It should therefore be presented on its own, without surrounding distractions.

The reader might well have thoughts of their own that are worth writing down as a reply. But this will happen later, after they have read and digested the whole article. So the UI for composing a reply should be out of the way.

A note makes no sense unless it is presented in context. It must be shown in a linear sequence with the notes it is responding to.

Every note is implicitly an invitation to reply, and to reply immediately as part of the conversation. The UI to compose a reply should be instantly available.


Both notes and articles may be replies to earlier works. A note may be a reply to an article, and an article may be a reply to a note. Both notes and articles may be written without being a reply to anything.

However, a note is usually a reply to something, and is intended to be read by the previous author. An article may or may not be inspired by a previous work, even a tweet, but it is not necessarily intended to be read by the previous author. It is likely to be a tangent or a reframing of the entire topic.

In particular, an article in reply to a tweet is like the bore at the bar who takes over a conversation without regard to the other participants. This should be discouraged. Where it happens, the conversational display should prefer showing just the metadata, rather than the full content.

Therefore, a note can by default be a reply, including notifications to the other participants. An article should not automatically be a reply, but only if the author explicitly chooses it to be so.


Notes should avoid quoting previous text. Instead they should be marked as replies to previous notes. Participants in the conversation all remember what was previously said. Saying it again wastes everyone’s time.

Articles often should include quotes of selected portions of previous articles. This allows readers to focus on the important parts. Articles should also include unambiguous references to previous articles, allowing readers to check that quotes have not been taken out of context.


The main reason people start discussing the difference between an article and a note, is that they can’t figure out how their own software should behave. In these discussions various heuristics get proposed. For example, longer than three paragraphs means it’s an article. Or, replies are always notes. In Friendica, anything with a title is an article, without a title is a note.

By and large, these heuristics are not bad. But none of them are entirely accurate either. A complete, standalone article can be short. (And don’t we all wish more were?) A reply, even relying on surrounding context, might still not be complete in three paragraphs. And heuristics are just “made up”, they don’t come with a chain of reasoning explaining why exactly they are good for users.

In general, the choice between article and note can and should be delegated to authors. Give them a checkbox or drop-down or something. I think the reason this tends to be avoided, is simply the difficulty of meaningfully conveying the difference. A choice of “article” or “note” doesn’t give the author any cues as to which they should choose.

Instead, the option could be something like “this is: ✓ a standalone article ✓ part of a conversation”. The selection could be automatically suggested as the user types. But it would still give the user the freedom to override the heuristic.

For display, I think the distinction is clear. Articles should be presented in their own window, by default without surrounding comments. Notes should always be presented embedded inside the wider conversation. And regardless of the purpose of the platform, it should support both.


I think the reason the ActivityPub spec is so unclear on the distinction between note and activity, is that it was never necessary for the distinction to be clear. The idea of the spec was to support federated social media, following the contours of how social media is used in real life instead of trying to dictate a new model. This was very wise.

The confusion arises from ActivityPub’s success: as platforms with different models flow together into a single network, distinctions that previously were obvious become very confusing. I think now we do need a more clear definition of these types, both their intended purpose and the consequences for implementers. The explanation should be detailed, but also intuitively available as part of a UI.

So this article is presented as an example of how a coherent distinction could look.

Leave a Reply

Your email address will not be published. Required fields are marked *