@tallship @julian

>Here you go bro: Socialhome post w/inline images.

It is a Note. I think this is a good example of a post which is best viewed on the original site.

@Julian yeah that's a good point - I think tag would work but I always got the impression that they were more of a micro-level part of a specific piece of content vs. macro-level (being the place they're being discussed in). context would be set at the forum level (whatever the forum's owner specified) whereas tags might be decided by the user. So in that sense, context would more about origination of a post.

Example might be something like this -

{ id: "https://yuforium.com/forums/cars", type: "Service", name: "Example Forum About Cars", context: "https://another-instance.org/topic/cars" }

Where a POST to that forum's outbox with a Note would result in that note's context defaulting to the one set to the forum. Posting with another context would result in an error. This makes things a little different than a tag which is what would be user specified. In that sense, context is more about where the post was created, vs. what it was created about. In a federated system, where could be an authoritative entity that encompasses multiple instances and is dereferenceable, or where could be defined as a UUID and be completely unauthoritative and ephemeral.

Given that it's more about the origination of the post, I would agree that the term "Community" is better in this case to define what context relates (instead of "Topic") so in the example, context could be switched to https://another-instance.org/community/cars.

It's been a while since I wrote that up, and at the time I was considering using "Community" as the terminology for a context so I might update that soon (especially with "Topic" being a frequently used convention in forums meaning something totally different).

In the Activity Streams docs, the one part about context that got my attention was this - "An example could be all activities relating to a common project or event", meaning that context exists outside of the scope of what a thread would be, and is more indicative of a forum level or federation setting vs. the contents (objects, activities, etc.) of a single thread.

As of today, the NodeBB-ActivityPub implementation now supplies both context and audience properties with every post.

N.B. When I say context and audience, these are also terms used by the ForumWG that refer to "topic" and "category", in NodeBB parlance.

Early indications from the last ForumWG meeting indicate movement towards the inclusion of context in a low-level as:Note object (a federated NodeBB post), resolvable as an as:Collection or as:OrderedCollection. The latter is what NodeBB will send, ordered by post time.

Discussions with @[email protected] also suggest that Discourse has the ability to parse an as:OrderedCollection context if provided, but currently does not if encountered as a property in a Note.

A minor change today also updates the audience property, which used to erroneously point to the context/topic, but now points to the audience/category. This change aligns usage of this property with FEP-1b12's expectations.

This change should allow other implementors to:

automatically group objects together given a the provided context, and more thoroughly backfill a given object's context, without relying on inReplyTo traversal

Thats how FEP-1b12 works, its necessary if you want to federate activities such as voting, deletions or mod actions and not only post creations. But Lemmy doesnt support arbitrarily wrapped activities, only specific hardcoded ones like Announce/Create/Note, Announce/Like or Announce/Delete.

trwnh: Topics can be split In addition to splitting topics, topics or their posts can also be merged into another topic. The UX for this is quite variable; sometimes entire topics can be merged into another, sometimes a certain range of posts within a topic (post 5 .. 10 from 15 posts), and sometimes a selection (post 5 and 10 from 15 posts or just a singular item post 5 from 15 posts). trwnh: Topics exist in a category For #Flarum topics can also not exist in a Category (we call them tags and that extension is optional, like all of our extensions). Even when using a Category, once the Category is deleted, we do not hard delete any topics contained within but unlink them, making them less visible but still existing within the Forum. Regardless, to us, Topics CAN exist in a category, it's not required. trwnh: Users can be followed for posts and topics Users can be messaged directly This sounds as if this is a given, I don't think it's guaranteed in every Forum software. But if can implies optional, then