the suggestion was to multi-type as both Group/Application/whatever and also as OrderedCollection, so that you could make use of orderedItems following the general recommendations to treat context as a collection. but this is not necessary; you could disregard that part and still follow the part about delivering only to context.attributedTo.
i suppose we could consider language saying that if the context is not a Collection (i.e. doesn’t have orderedItems or items), then you should check outbox if present (i.e. if the context is an actor)? this is a bit weird though, so i’m inclined not to do that.
the reason i didn’t suggest context = outbox is because you aren’t really creating the object in context of the outbox; the outbox instead contains the actor’s Add/etc activities. also in many cases where the user desires privacy, the outbox should not be public. it might make sense to (re)use smithereen’s wall property to signal this as a special collection on the actor, but i don’t think this should be necessary. you could just have the collection be the actor. activitypub is very clear about this:
ActivityPub actors are generally one of the ActivityStreams Actor Types, but they don’t have to be. For example, a Profile object might be used as an actor, or a type from an ActivityStreams extension.
tangentially, i think it is a big mistake to treat actor types as having additional meaning and expectation that isn’t defined by anything. the standard as2 actor types are more like vcard kinds than they are separate classes. declaring your actor is a Group doesn’t actually imply anything technically different than declaring yourself a Person or Organization or Application. you still receive activities in your inbox and send out activities to your followers. these types are basically only useful for display differentiation, along the lines of saying “this is a personal account” or “this is a brand account” or “this is an automated account” or “this is a collective account”. we might reasonably declare an actor to be a [Group, Application, OrderedCollection] which semantically means “this actor represents a collective and is automated. it also contains items that are sorted reverse-chronologically.”
the ability to Follow threads and conversations is discussed further in Unresolved issues surrounding Follow activities
yeah, i brought up FEP-1b12 as something related to this, not as a recommended change, as it prescribes different behavior. i think it is roughly incompatible with some of what FEP-1b12 defines. things like the Follow flow are standard to activitypub, things like saying that a Group is automated are less so. things like specifying that audience must be a singular value or that Announce MUST be used are especially unfortunate, as audience is an array of who can see an object, and Announce is specifically a reshare or crosspost that gets added to the shares collection. i think this also precludes private sharing in the future? not entirely sure, but it seems that way.
FEP-1b12 might be finalized but that doesn’t mean we have to use it forever. the aim of this FEP-7888 is to provide a framework that isn’t specific to any one interpretation of “what is a group” vs “what is a chat” vs “what is a conversation” vs “what is a topic” vs “what is a forum” vs “what is a thread”. the presentation is irrelevant to the underlying data structure: objects in collections. they all operate the same way. that’s what “context” is: a logical grouping of these related objects. it would be great if fediverse implementations end up converging on this structure that can be presented in multiple different ways. it’s probably going to take some time, though…