Differences in `Group` federation between projects

ActivityPub Server to Server
1

I have recently added support to Lemmy for federating with two other projects which use Activitypub Groups, Peertube and Plume. This was pretty straightforward for the most part, with one exception: the way to specify which group a specific post belongs to, and who created it, is very inconsistent. Here are the implementations I came across, if you know of others, please comment below.

Plume:

"attributedTo": [
    "https://fediverse.blog/@/TheUser",
    "https://fediverse.blog/~/TheGroup"
],

Both user (creator) and group are stored in attributedTo field

Lemmy:

"attributedTo": "https://lemmy.ml/u/TheUser",
"cc": ["http://lemmy.ml/c/TheGroup"],

In case of Lemmy, only the creator (Person) is stored in attributedTo. The group id is stored in to.

Peertube:

"attributedTo": [
    {
        "type": "Person",
        "id": "https://framatube.org/accounts/TheUser"
    },
    {
        "type": "Group",
        "id": "https://framatube.org/video-channels/TheGroup"
    }
],

Like Plume, Peertube stores both user and group in attributedTo field, but also indicates the type of each. While more complex, this makes parsing a bit easier.

Lemmy can currently handle the format used by Peertube in addition to its own. Support for Plume is also implemented, but waiting for some other compatibility changes on their side before merging.

In the interest of compatibility, it would be useful to agree on a common format for this information. Personally I dont like any of the options above very much. My choice would be something like the following, with a new field:

"attributedTo": "https://lemmy.ml/u/TheUser",
"group": "http://lemmy.ml/c/TheGroup",

What are your thoughts?

2

Hi,

As a note, there are some issues about the way PeerTube formats attributedTo field: ActivityPub Video `attributedTo` field malformed · Issue #2704 · Chocobozzz/PeerTube · GitHub

1 Like
3

before adding a bespoke one-off property like group it would be worth considering if there isn’t already an existing property within the activity vocabulary that might work. to do that, we need to know the purpose of group:

  • is it for addressing and targeting? then audience could work
  • is it for specific ownership and authorship information? then attributedTo would be better

given that lemmy uses to/cc for this currently, i would say that audience is most appropriate, and attributedTo should be reserved for who actually wrote the post and owns the post

suggestion for a public post:

"attributedTo": "https://lemmy.ml/u/TheUser",
"audience": [
  "http://lemmy.ml/c/TheGroup",
  "https://www.w3.org/ns/activitystreams#Public"
]

suggestion for a private post:

"attributedTo": "https://lemmy.ml/u/TheUser",
"audience": "http://lemmy.ml/c/TheGroup"
5 Likes
4

It depends a little bit what semantics one means by Group. For something like GNU Social bangtags, using the attributedTo field doesn’t make a lot of sense to me because the Group has no hand in authoring the Note, and you could imagine the same Note being posted to multiple different groups. This is how I would expect Lemmy’s Groups to work too—the group isn’t “writing” the post, it’s just participating in distributing it. But Plume and Peertube groups (I think) have completely different semantics—they seem more like Tumblr group blogs, where each posts are presented as being “authored by” the group, and people who are outside the group may not even know which individual member(s) are responsible for which posts! I think it’s important to recognize that these are very very different usecases, even if both might be called “Groups”, so it’s understandable that they’d federate almost completely differently

1 Like
5

One thing that might be useful would be differentiating between the owner of the post and the author, and passing both variables.

For example, in Hubzilla, a channel designated as a public forum takes ownership of all of the posts within that forum. It does this because of how permissions, privacy, and sharing work in Hubzilla.

Locally Hubzilla knows that the author and the owner of the post are not the same, but since ActivityPub doesn’t differentiate between them, Hubzilla tells ActivityPub that the forum is the author, and puts the author of the post in the body of the post.

Since there are multiple use cases for groups, perhaps we need to have separate fields for the owner of the post and the author of the post in ActivityPub.

6

In the interest of compatibility, it would be useful to agree on a common format

Well, this is what we talked about in the meetings January - May.
The context field was made for grouping things. This is how all people at the meeting agreed to do it.
Also other existing implementations, e.g. immers (3D) are using it and I am using it to put the 350.000 subscribers of a publishing house in groups (e.g. per magazine) and will use it for redaktor.

Spec. - definition:

The intended function is to serve as a means of grouping objects and activities that share a common originating context or purpose. An example could be all activities relating to a common project or event.

See also Audience and context for grouping things

PS: @nutomic Plume said, it is unmaintained …
PPS ping @cpmoser Will you present someithing next meeting?

7

Its true that I didnt look at existing Activitystreams fields for this. Both audience and context look appropriate, based on their relatively vague descriptions.

Its also true that the metadata of post author and group will not work for every project. But at least for Lemmy, Peertube and Plume it is identical, just expressed in slightly different formats. Maybe for Hubzilla this particular discussion is not relevant.

Also, Plume development has been active for the last few months at least

8

i would say context is maybe not appropriate for this use case of “posted within a group” – it would be more appropriate to use context for threading

1 Like
9

Well, misunderstanding.

audience would be of course “posted within a group” which is a "type": ["Group", "Collection"].
But context is super important for defining that a workflow happens within a Group, which is an aspect of, yes, “threading”.

But the initial question was both

the way to specify which group a specific post belongs to, and who created it

I am a bit desperate, the way concensus worked over all the time was to have meetings, we will write an FEP together later and the next meeting would be on Tuesday (every 2nd of a month).
I’ll add it to the W3C calendar soon and here as well.
cc @bengo maybe want to talk about the capabilities thing ?
The current meeting make only sense if we do not fragment things.
See also this Developers Meeting 2 : Groups - #3 by Sebastian -
would like to write on but late for work (where we will do examples how to do it C2S too), will edit later.