Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to work with groups? #328

Open
annando opened this issue Nov 3, 2018 · 15 comments

Comments

@annando
Copy link

commented Nov 3, 2018

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 !group@host.tld 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.

@nightpool

This comment has been minimized.

Copy link

commented Nov 3, 2018

@annando

This comment has been minimized.

Copy link
Author

commented Nov 3, 2018

Since posts for non-public groups are non-public as well, we don't have a way to validate the announced post.

@nightpool

This comment has been minimized.

Copy link

commented Nov 3, 2018

@nightpool

This comment has been minimized.

Copy link

commented Nov 3, 2018

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

@annando

This comment has been minimized.

Copy link
Author

commented Nov 3, 2018

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?

@nightpool

This comment has been minimized.

Copy link

commented Nov 3, 2018

@annando

This comment has been minimized.

Copy link
Author

commented Nov 3, 2018

Just some side note: With the alternate frontend (a copy from the Mastodon frontend), Pleroma does support the creation of private posts as well.

@nightpool

This comment has been minimized.

Copy link

commented Nov 3, 2018

@annando

This comment has been minimized.

Copy link
Author

commented Nov 3, 2018

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.

@cjslep

This comment has been minimized.

Copy link

commented Nov 3, 2018

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)?

@Angular-Angel

This comment has been minimized.

Copy link

commented Apr 4, 2019

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.

@annando

This comment has been minimized.

Copy link
Author

commented Apr 4, 2019

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.

@Angular-Angel

This comment has been minimized.

Copy link

commented Apr 4, 2019

Oooh, that's a good way to do it. Thank you, I'll do it that way too. XD

@gobengo

This comment has been minimized.

Copy link

commented Apr 4, 2019

@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.

@Angular-Angel

This comment has been minimized.

Copy link

commented Apr 16, 2019

Ah, alright, good to know. :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.