For those of you using the Roadhouse fediverse app, be advised that we will once again be changing the way groups confederate.
TL;DR
If your site provides groups, please don't use Roadhouse at this time. As this project is not widely known or used this shouldn't have a major impact; and other Zap-based projects may be used as a drop-in replacement with no functional difference (the current differences are very subtle and un-noticeable unless you're a protocol developer).
Discussion:
If you provide groups on your Roadhouse server, you may wish to move to a different "Zap based" platform if there are group members using other fediverse software (Mastodon, Pleroma, whatever). Groups do not work under the #
ActivityPub protocol if permissions and privacy are involved, so we've provided some workarounds in all our projects. You will see these group posts as embedded shares sent by the group rather than attached "Announce" activities.
This is radically different from groups on other platforms which do not support granular privacy/permissions; and who aren't yet aware that native ActivityPub methods do not work correctly when you add security to the equation.
We will be trialing some extensions to ActivityPub which allow groups and permissions/privacy to actually work correctly over that protocol using its native mechanisms. This effort will be confined to the Roadhouse project at this time to reduce the probability of breaking existing groups.
Until and "if" these extensions (or similar mechanisms) are standardised and picked up by other projects, Roadhouse groups which utilise privacy and default channel permissions will only work correctly on Roadhouse or other Zap-based projects. People using other ActivityPub projects may be unable to post or comment to such groups.
Background:
Under ActivityPub, most projects support groups as "Announce" activities. This is the only existing method in the protocol for sending a message which you didn't initially create to somebody else. The design of ActivityPub is that replies are sent to the 'actor' or author of the original post, who
may only accept comments from their own connections and will reject comments sent by group members they aren't connected with personally.
The extension proposed is to add a 'replyTo' field to relayed activities. This indicates that replies are to be sent to the group, and not the original author. This software pattern is critical to corporate messaging and we are merely copying something that has worked well in email for more than half a century. If 'replyTo' exists, all replies to that activity MUST be sent to the 'replyTo' address which in this case will be the group and
not the original author.
We also plan to send these as [ "Announce", "Relay" ] instead of "Announce" to indicate that this is a relayed post by an organisation of some kind and not just somebody sharing something they saw in their stream.
In order to more closely align with email, we may or may not also provide a "sender" field which arguably is redundant to "replyTo" in the case of groups but can be applied anywhere that the person sending the message is not the original author and this can then be reflected in the UI.
With these relatively minor additions, we can then use "Announce" as a general purpose relay without any of the associated permission/privacy issues and stop using embedded shares. But (and this is important), this work is meaningless if this is the only project to support these mechanisms.
