Another distinction is that Articles have a different role in conversations. It is typically a long form blog post or journalistic article that people may or may not be able to comment on. It is something people talk about. There is a clear distinction between the blog post and the comments.

Note just seems like a short version of Article. Someone posted something and you may or may not be able to reply to it. (That is probably why there is confusion over what a note versus article is.)

Note makes sense for Twitter-style platforms since it is primarily a broadcast style platform. You say something and it gets broadcast to your followers. It does not support threaded conversations, so every reply in considered a new top-level post.

But this does not make sense for conversational platforms like forums and discussion groups, which are threaded conversations, not broadcast-style social media.

We currently have no type for conversations. I do not consider a forum post or comment a Note or an Article. The fact that some platforms use Article for forum posts seems odd, since they do not resemble articles in any way, shape, or form. The only thing that have in common with an Article is that there is a top level post and comments. And Note does not seem appropriate either for similar reasons.

If we are not going to create clear distinctions between types, or just misuse them, then we might as well just have one type, call it Stuff, and be done with it.

At first I was opposed to how Mastodon handles Articles, but if you define an article the traditional way (journalist article, blog post, etc.) then it makes perfect sense. If a platform cannot display the HTML in the article properly, it SHOULD link to it instead of try to display it.

And the current trend to mark things that are clearly not Articles as Articles, and then stuffing the Summary with the body of the post so it shows up on Mastodon is... a workaround that should not have happened. A Summary should not contain HTML and should remain short. After all, it is a summary, not the body of a post. (And some platforms strip all of your fancy HTML in the summary field anyway.)

All of this because there is no type for Conversation, and even if there was, some platforms would not recognize it.

I think the only solution is to use the same model email has. They send a text version and an HTML version, and the client picks what it wants to display. But in our case, we send:

1. A Link to the resource.
2. A Summary of the resource (short, no formatting, may contain content warnings).
3. A Note: A Simplified View (a version of the content with limited formatting).
4. An Article: A Fully Formatted View (a version that contains HTML, which will be sanitized upon display).

If a platform does not support articles, or wishes to link to articles instead of display them, then it can use the content of the Summary or Note plus the Link to display something meaningful. Platforms that support articles can use the Summary or Note content on some displays (like the inbox or recent posts view) and the Article content on the single post page with its comments, if any.

Feel free to rename Note and Article in the example above in future specifications. I am just using terms people are familiar with.

But we need to somehow get away from everything being a note, and the misuse of article for things that are clearly not articles.

silverpill@mitra.social missed your reply.

I'm not here to decide what's right or wrong, just going with consensus. In any case, a dedicated preview would allow implementors to opt in to an alternative representation that better respects the constraints supplied by Mastodon and other microblog-focused software. Things like lack of support for inline images, and the use of attachment.

summary gets you part of the way there, but Mastodon would still strip out the inline images, and I don't want to add image assets to Article in attachment because I want to promote the support for inline images for non-Notes.

silverpill@mitra.social specifically, though, the idea of providing a rel="alternate" would be more appropriate than using preview. (cc trwnh@mastodon.social)

What that ends up looking like is to be determined, but I am optimistic.

wistex@socialhub.activitypub.rocks why a link when you can set url?

@julian

summary gets you part of the way there, but Mastodon would still strip out the inline images, and I don't want to add image assets to Article in attachment because I want to promote the support for inline images for non-Notes.

If Mastodon can display summary, why inline images are a concern? Summary with a link should be enough for previewing.

silverpill@mitra.social for me, summary is a stop-gap until a proper alternative representation is agreed-upon. content in Article is unusable at the moment due to aforementioned restrictions (even more so than content in Note).

Don't worry scott@authorship.studio, stuffing the whole post body into summary isn't a "trend" you should be worried about.

One of the problems with using summary for a preview is that some platforms, like Hubzilla, strip out all of the HTML. And by doing that, is it really a preview anymore?

@julian By the way, I was not criticizing you personally. The entire ActivityPub situation is messed up where we have to do things that make no sense so they are compatible with certain systems.

And if putting the whole post in summary was not intended, then there is a bug, because we are receiving the body of the post as both the summary and the body fields.

A URL would be better, but in the case of a blog post, most people would expect it to deliver them to the original blog post. What WordPress would call a permalink.

Depends on what is being stripped. Does it completely remove all HTML content, including text paragraphs, or just sanitizes it?

ActivityStreams vocabulary defines summary as "A natural language summarization of the object encoded as HTML":

Activity Vocabulary

(www.w3.org)

I think that means images and other media shouldn't appear in summary, because they are not natural language.

There is a subtle distinction between using a URL that serves as a unique identifier and a URL that directs you to the source rendered as a web page.

When I said link, I was referring to something that resolves to a web page, typically showing the blog post or forum thread or social media post. Something you can put in the UI that users click on.

As far as I can tell as a user, Hubzilla currently treats summary as plain text.

And I don't think Hubzilla expected HTML, since we currently have this weird situation where it converts all incoming text to BBCode, but then does not parse the BBCode for the summary field. HTML in the summary appears to be an unexpected use case for Hubzilla.

I am not sure what Mario Vati (the head developer) plans to do about the situation. I saw a post where he was trying to get clarification of why we are receiving HTML in the summary from some platforms.

This is what we receive in the summary field and how it is displayed. You have to click on "View Article" to see the formatted version.

Can you point me to where Mario is asking for feedback?