The model right now in most implementations that use Group is to treat the outbox as a “wall” similar to Facebook. Followers of the Group are its members, and when the Group actor receives a message from one of its members, it publishes an Announce to its outbox. Of course it is possible at an application level to authorize as the Group itself and publish a status attributedTo the Group actor directly, rather than one of its members.
The Collection should be dereferenced to find each member Actor, since it is a collection of actors and not an actor itself. Do also note that the type field does not have to be Actor or one of its subtypes; the real definition of an actor is that it must have both inbox and outbox. Types within ActivityPub are merely a suggestion on how to process data (as defined by the @context schema).
I think that automatically wrapping each Activity into Announce looks ugly.
The group (i.e. a Server hosting the group) should act nearly transparently. My experience (dealing with activity recipients…) shows that having a group in the explicit list of recipients is enough for a client app to understand, why any activity arrived AND enough to properly address recipients in a reply to such an activity.
Naturally, if you reply to a post, which was sent to “GroupA”, it’s natural to add that group to the list of reply’s recipients thus keeping the same audience in the loop of discussion.
Yes, but the type of a Group (type of an Actor) shouldn’t be “OrderedCollection”.
The question is: what Group’s “endpoint” should point to a list of its members (to that "OrderedCollection of Actors)? That endpoint is not inbox or outbox…
It works, though. The other way it can be done is inbox forwarding technically… But I’m only talking about other actors posting on the wall of the Group, which would be Announced into the outbox.
Yes, that would be the ideal case.
It would be followers which SHOULD be included (although membership in a group does not have to be public information, so the endpoint may require authorization or may not be present). It should not be necessary to know the members of the group, as addressing should be done to the Group, and the Group should handle any incoming posts addressed to the group.