Standardizing on ActivityPub Groups

Okay, I looked at how it’s done in Friendica (here). It’s basically the same as what I do in terms of not addressing to followers, except Announce instead of Add and it’s not possible to reliably tell that this post is to the group wall when you only have the post.

(also, you can easily see when something is written in PHP because you get \/ instead of / in JSON lol)

doesn’t simply not including the followers collection (and explicitly targeting the group’s followers, I assume?) indicate that this is a group post?

No. I tried this approach myself some time ago. Didn’t like this whole idea of guessing where the post belongs by its addressing, hence the FEP and the target field to specify it explicitly.

Besides, when you start taking into account more complex interactions like adding photos to albums in a group, or adding posts to topics, this gets insanely more confusing than just specifying the exact collection (together with its owner so it’s easier to look up on the receiving side).

An interesting little tidbit came up yesterday in a conversation with a Pleroma dev who is considering using ‘audience’ specifically for group targeting, as this was in fact an example shown in the ActivityStreams vocabulary document; albeit one that preceded ActivityPub and some if its unique requirements.

As an unpopular person here who was previously driven away from this forum because of my posts on this very issue: I will stay out of any decision making on this subject. I will only mention that if the solution doesn’t support post authors that restrict comments to their own followers, as well as private groups, and allows distributed moderation, and works across both conversational as well as microblog platforms; I’ll probably provide support for your mechanism but I’m still going to keep what we have now because it works today and meets all of those requirements.

I would highly encourage folks to consider supporting ‘replyTo’ (which works exactly like reply-to in email) to solve a number of “conversation vs. microblog” issues which came up during development of this feature over ActivityPub; and mention that the details of our current implementation are provided in the zap (dev) FEDERATION.md document. The copy in the release branch is a month or two out of date and we’ve made significant progress on cross-platform compatibility during that time.

I have nothing more to say on the subject.

1 Like

Since there are a number of people interested now in aligning on Group impls, maybe this is the time to collectively start work on a design doc, before we have yet another 50+ comment inconclusive thread. And then - later on - possibly turn it into a FEP. There’s already a bunch of Requirements to be listed, and some design choices already made.

This may start with a wiki post here, or a HedgeDoc in public.cat, or directly with a FEP markdown + open issues.

1 Like

Full ack.
I am proposing to start with a meeting, preferably in 2 days SAT or next FRI to kick it off.

About a collaborative doc: I organised a nextcloud running directly at https://cloud.w3c.social/ -
maybe we should eat our own food and use it for collaboration which can federate …

Since the waiting list of topics for Social CG is so huge now, it would be nice if we also write a
“Best practice for Client to Server” and talk about the supernice guides

I don’t see a signup button :thinking:

Yeah what I said yesterday:
image
Except we can’t really make a group until we’ve agreed upon and implemented at least a minimally compatible federation protocol… So meta, much wow.

The problem here is that this leaves us with two issues:

  • How does a group exercise its authority? How does it reject a post from a user that’s blocked in it? How does moderation work?
  • How does a group disseminate new posts to followers? Announce{Note} is a Mastodon-compatible way many use, there’s also Add{Note} which I’m pushing for as a universal “I hereby accept this object into my collection” activity. Replying to a group (or a photo album, or a collection) doesn’t provide an obvious, semantically sensible solution for this. Forwarding of LD-signed activities is nice but it’s best-effort kind of thing because of how hard LD-signatures are to implement correctly.

From a cryptographic standpoint, it should be possible to store membership in an accumulator, a fixed-length value that can track membership of any number of public keys (an implementation). To verify that you’re not dealing with an old state, there could be a revocation mechanism where admins of a group build a key revocation as they sign a new membership state.

How do you test this currently?

No, let’s not involve any additional cryptography here. It’s merely a problem of state synchronization, where the instance that the group is on contains the authoritative state. Remember: treat ActivityPub like an API, this makes reasoning about it a whole lot easier. Your Create{Note} is an API call where you ask the group to add a post to its wall, group’s Add{Note} is its API call to its followers to update their cached states.

Well, there’s a spec… And I have some test cases from Mastodon. Here’s a topic of mine where I discuss LD-signatures in detail:

Fact check: Unless something changed recently Pleroma does not use LD-Signatures. This was the whole reason for the litepub ActivityPub fork. LD signatures are tedious to implement but not necessarily difficult. The real problem with LD signatures is they rely on availability and consistency of centralised external resources in order to validate; and also apply to the entire activity, making it impossible to encapsulate signed objects within other signed objects.

2 Likes

Concerning the “centralised external resources”: To not depend on this we store the basic ones locally: https://github.com/friendica/friendica/tree/develop/static

Ditto. I’m mentioning it because then you need to stay on top of updates that you will have forgotten were a dependency five years from now. We’'re currently caching them with a TTL of a week and falling back if the fetch failed. Then the only thing we need to concern ourselves with is malicious edits or unintentional deletions upstream. There was an attempt to provide versioning of the main AS schema to solve the problem for that particular resource but I couldn’t get the versioned schema to validate at all. I think it was an upstream server configuration; which only underscores the problem instead of solving it.

I solved it by simply not doing any networking whatsoever in my JSON-LD processor. Either the corresponding schema for a URL is stored locally and I use it, or it doesn’t exist. There’s no third option.

Me too. I’d be interested to join a discussion on standards process. RFCs, FEPs, re-implementable specs I’m all about.

FEPs go here and you can sign up there.

Can I strongly suggest that any Fediverse-wide group format take a cue from Twitter’s new group format - which they all Communities.
To
It requires users to join a group to interact or engage with the content, and if you aren’t a group member no group posts show up on anyone’s main feed… BUT no Twitter groups are private…there is no such thing as an unsearchable or invisible group or post in a group.

To my view, this transparency would make Fediverse groups far better than the cesspools of disinformation or worse that Facebook groups have become from day one of their existence.

1 Like

So those of us that actually desire privacy and private spaces will have to leave the fediverse or create a parallel fediverse where these things are permitted?

Way ahead of you mate.

1 Like

As I’m following VK with my groups UX, there will be two kinds of groups in Smithereen:

  • Open. Searchable and joining is optional. All content is visible to everyone. You can interact regardless of membership status.
  • Closed. Without joining you only see metadata and the member list. You can send a request to join that must be approved by group admins. Once you’re a member, you can see and interact with everything.

VK also has third group type, “private”, which mostly pretends to not exist unless you’re a member, but that isn’t very possible to implement with ActivityPub.

What you want is basically closed groups. Maybe with automatic approval, but that would defeat the purpose of them being closed.

Hi Tim, thanks for following-up to the discussion. As all the posts in this thread indicate: everyone has their own requirements when it comes to implementing Groups. In the examples you gave you weigh how 2 applications implemented them (TW and FB), and prefer one to the other. As Mike says, reformulated: “my requirements are different, and Privacy is important in my use case”, and Gregory also has different use cases implemented.

As Fediverse is the ‘social fabric’ or interoperability infrastructure for any kind of application the challenge is:

Requirement: Find the simplest model that covers the broadest set of use cases.

I suggested above that we should start to document these in another manner than an ever growing discussion thread. I propose:

  1. We start with a wiki post and collect use cases, requirementes and other considerations.
  2. Once things are a bit structured, we can organize a meetup to discuss the ins and outs.
  3. Based on 1) and 2) we then begin the process to come to a good FEP document.

Unless there are objections I will create and pin the wiki post.


I would also like to ask your feedback on the conceptual model I outlined above, as I think it is very flexible in the way it allows arbitrary (and some standardized) relationship types to other actors. Is it too naive? Or is it too much of an extension with the additional relationships collection (so that following gets its original intention back)? Too complex to implement? I added some more background in the Community discussion here.

Re:Smithereen, just as an example… implemented are a very interesting set of Group features. But they are still very application-specific, and universal requirements and use cases should be further distilled. Consider:

  • Open / closed / (private) does not cut it. In my app I may define Open as read-only, or e.g. define a new state Public for that.
  • There’s the notion of ‘membership status’ or roles with currently I believe admin / mod / member privilege levels.
2 Likes

For what it’s worth we identify both the different group types and member roles as an extensible list of permissions. So your relationship with a group can take on any of over 65000 unique dimensions (currently). While it’s convenient to try and fit these into 7 or 8 named types+roles, permission discovery might prove to be more useful; as it most concisely encompasses both concepts. It’s easy enough to mock up in any case.

1 Like