activitypub
activitypub copied to clipboard
w3c
How to work with groups?
While working on implementing AP in Friendica the next step are now groups. In our current implementation, groups are profiles with some special behaviour. When you create a post with addressing the group with [email protected] then the post is forwarded to the group profile which then forwards this post to all followers of the group. When replying to such a post, the comment is send to the group profile that distributes the comment to the followers again.
In the specs I only found chapter "5.8.5 Group Management" which doesn't tell much. Question for me is how the messages should be formatted.
It would be possible that the original post could be delivered solely to the group profile which then does an "announce" to distribute it. But this doesn't work for non public groups (which Friendica does have as well). So possibly this could be done via the audience value?
To make the message flow clear: Person A is writing a note that is solely transmitted to group B, not to the followers of A. B is then transmitting it to their followers. The following message flow (including the comments) is like B had created the note by itself.
I've always seen people propose Announce for this use-case. why doesn't that work for non-public groups?
On Sat, Nov 3, 2018, 7:16 AM Michael Vogel [email protected] wrote:
While working on implementing AP in Friendica the next step are now groups. In our current implementation, groups are profiles with some special behaviour. When you create a post with addressing the group with [email protected] then the post is forwarded to the group profile which then forwards this post to all followers of the group. When replying to such a post, the comment is send to the group profile that distributes the comment to the followers again.
In the specs I only found chapter "5.8.5 Group Management" which doesn't tell much. Question for me is how the messages should be formatted.
It would be possible that the original post could be delivered solely to the group profile which then does an "announce" to distribute it. But this doesn't work for non public groups (which Friendica does have as well). So possibly this could be done via the audience value?
To make the message flow clear: Person A is writing a note that is solely transmitted to group B, not to the followers of A. B is then transmitting it to their followers. The following message flow (including the comments) is like B had created the note by itself.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/328, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORVxtkJqZn9_1mKApxvUAZ_KTYspYCks5urXsbgaJpZM4YMwO1 .
Since posts for non-public groups are non-public as well, we don't have a way to validate the announced post.
use http sig to authenticate the GET request
On Sat, Nov 3, 2018, 9:37 AM Michael Vogel [email protected] wrote:
Since posts for non-public groups are non-public as well, we don't have a way to validate the announced post.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/328#issuecomment-435588628, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV-XHylImxMOQ2iIu3JGUhXeIgg93ks5urZwggaJpZM4YMwO1 .
To be more concrete:
-
In order to implement groups that distribute activities to some number of users, you either a) need to be able to fetch a list of that users and distribute to all of them (doesn't scale well) or b) allow the group to "forward" your message (either transparently or with an Announce wrapper)
- All current activitypub systems use B for targeting the remote audiences (they rely on the remote server to handle forwarding, because the audience may not be publicly visible, like the list of a user's followers)
-
To implement message forwarding, you need some way of authenticating the message (in fact, this is true of any message delivery whatsoever). The two broad ways of doing authenticating forwarded messages are 1) signing the message in a way that can be forwarded and 2) looking up the origin of the message when you receive it.
- Some current activitypub systems use 1, some use 2. the downside of 1 is that it's complex, and may not fit your security goals if you care about deniability. the downside of 2 is that it doesn't scale well, and inherently adds a DOS vector to the system (very easy to take down smaller sites by sending fake objects, or real objects referencing fake ones, to other servers)
-
The current consensus way to implement 2 for non-public messages is to make a HTTP-signed request using the key of an actor that has permission to read the message. This is very easy for implementations that already support HTTP sig for delivery. There are probably other ways to implement the same goal, like anonymous bearer tokens, but HTTP sigs is the one people currently use
Is there any installation where I could test signed (GET)-requests?
And what about the object/activity format? Would it be a post to the followers collection of the group or do groups have a special collection or field?
Mastodon supports http signed get requests for private posts. Pleroma knows how to make HTTP signed requests for private posts but as it does not have private posts itself (EDIT: incorrect) i don't believe it handles receiving those requests (EDIT: still correct). There are other implementations that support this as well but i can't think of any that would be useful for testing off the top of my head.
I don't see any reason why groups would have a special collection or field, nothing in activitypub changes based on the type of the actor.
On Sat, Nov 3, 2018 at 11:11 AM Michael Vogel [email protected] wrote:
Is there any installation where I could test signed (GET)-requests?
And what about the object/activity format? Would it be a post to the followers collection of the group or do groups have a special collection or field?
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/328#issuecomment-435595163, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORVxVGPGH07U-JT2ljP3AmsxgF9-Qoks5urbIegaJpZM4YMwO1 .
Just some side note: With the alternate frontend (a copy from the Mastodon frontend), Pleroma does support the creation of private posts as well.
Ah, right, thanks. If i'm reading this code right, Pleroma does not currently allow dereferencing non-public statuses: https://git.pleroma.social/pleroma/pleroma/blob/develop/lib/pleroma/web/activity_pub/activity_pub_controller.ex#L47-48
On Sat, Nov 3, 2018 at 11:31 AM Michael Vogel [email protected] wrote:
Just some side note: With the alternate frontend (a copy from the Mastodon frontend), Pleroma does support the creation of private posts as well.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/328#issuecomment-435596611, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV3j201_6fUIVgWrK_REwA3--qgr1ks5urbbXgaJpZM4YMwO1 .
I just realized that signed HTTP GET requests aren't the solution. See this example:
Actor A is creating some group post and sends it to group B. Now it is send to user C. C now wants to fetch the content from A, using the own key. But A cannot know that C is authorized, since only B does know the group members.
Sounds like the root problem is that B is at a host server that C is not at, and A doesn't know that C is authorized by B.
Isn't this authorization problem one that OAuth solves (B gives C authorization token that A can check)?
Hello, I would like to note my support for this feature. I'm working on an ActivityPub implementation with Agora, and while I'm not yet ready to implement groups, forums, listings, or any other such functionality, I would very much like to and am looking forward to when I can, and hope the protocol will be developed enough to support them.
At Friendica we implemented groups now this way:
Person A sends a public post that is directed (via "to" and via tagging) to the group account B. The group account then looks if it was mentioned. If yes and if person A is a group member (follower of this group), then the message is announced to all followers of group B. This should work out of the box with every AP system.
Additionally we implemented tagging via ! instead of @. This is an indicator that although the post is public, it is sent only to this tagged account. This enables us to create group only posts.
Oooh, that's a good way to do it. Thank you, I'll do it that way too. XD
@Angular-Angel
and hope the protocol will be developed enough to support them.
Just to set expectations for future things: the spec is effectively frozen or at least glacial. Anything more than errata should probably be developed as extensions or initial writeups in another repository (and linked to from here so collaborators can find it). We have to hope/vote with our feet.
I think the process in this discussion has at least indirectly resulted in FEP 1B12, which provides announcement-based groups.
I think there's continued work on groups; I'd definitely recommend the Forums task force for tracking this kind of communications.
I don't think there's much else to do with this issue, so I'm going to close for now. Please let me know if we need to reopen.
