Hello everyone!
We are adding federated Group support to Pixelfed! Going to be reaching out to a few projects to see if we can make our implementations compatible.
Advice and feedback is greatly appreciated!
6 Likes
Some input scraped from this forumā¦
@Sebastian in the past has created a āgroup topicā 
that groups prior group discussions: How to use Groups
The ongoing groups implementation discussion was recently picked up by @macgirvin for implementation in #software:zap based on @grishkaās FEP draft. See Groups implementation - #70 by macgirvin
Unburdened by lotsa AP expertise I am broaching the subject of Standardizing on a common Community domain as AP extension? Community is something I need in the future, also based on groups, and imho valuable for fedi as a whole. I havenāt deep-dived the subject yet, nor analysed all existing group implementations.
In my - most possibly naive - view I consider a community network to consist of āGroups that maintain a Collection of Relationships to other Actorsā.
- A Group (the Community) maintains a collection of Relationships to other Actors.
- The
relationshipproperty describes the nature of the relationship to the Community. - There can be multiple relationships to the same actor. Some types can be standardized, others custom / app-specific. An example of a standardized relationship vocabulary is PURLās https://vocab.org/relationship, but there are more.
4 Likes
In my review of issue trackers in the fedi groups comee up pretty often so I think users will be pleased to see it in any form.
It would be pretty interesting to see some kind of multisignature scheme used to delegate or share group administration, but even having instance-local groups (where that wouldnāt be necessary) would provide a ton of value.
2 Likes
If you need more details about how Friendica is doing it, just reach out to me. In Friendica the group account just is performing an announce to the group members for all content that is directed to the group.
3 Likes
Well, this is then a relay like in
while the Conf session and these posts are more about group based communication
[as in Arnolds graph too, the Group would probably have some more collections like an Inbox (for public group posts)]
and
1 Like
And btw, relays come with pitfalls, for example if a group can follow other groups, extra care is needed:
If a relay follows a poorly-written relay and is announcing a message, the poorly-written relay announces it back to its members including the other relay which is doing it again and vice-versa and again and ā¦
Although which reminds me of a fellow student at HGB Leipzig who did his diploma in Medienkunst by demonstrating live how to take the Uni Leipzigs mailserver down by infinite bouncing.
He got the best grade you can get 
The huge UX problem with relays, whether built into AP servers or just Mastodon bots like this one, is that you still have to post to your followers first. You canāt post straight to the group without polluting your followersā feeds. Thatās what my FEP aims to solve first and foremost.
2 Likes
In Friendica we solve this with addressing the group via ! instead of @. This means that only the group is targetted but the post is still public.
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.
2 Likes
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 
Yeah what I said yesterday:
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.