Join/Leave seem semantically clearer to me. Plus, in Mastodon’s case, we do want to break compatibility (with at least current Mastodon versions), as we don’t want to muddy the UX nor have to handle nightmarish migration paths.
In other Mastodon group news, it is likely Mastodon groups will, after all, not be identified identified by a username and won’t require webfinger at all, so that may please the @lemmy team! However, since proper groups will come with a different interaction model and a different database representation, it is unclear how we can handle the migration from existing current-Mastodon-compatible groups to the new model.
Wouldn’t the Followers collection of the Group actor do that?
I mean sending activities to that group, which may be the privilege of a group member. But if the activity shows an attributedTo field that points to people, you can see how authorities may just point their fingers at these “people” and hold them responsible for all group activity.
In the current Fediverse, I can subscribe to the @fedicamp@a.gup.pe group and mention it in a post to address its members. What would you propose the core mean to write in a group to be?
It sounds like a different mindset than (un)subscribe or (un)follow. Isn’t the result the same? You become a group member by joining/following that group. Actually I find it clearer to follow a group, since group mind tends to follow joining a group.
In PSYC, inherited from the MUDs, the (IRC) channel is a room (like in XMPP). Which I would conflate with an ActivityPub Actor. The PSYC room, like in a MUD, holds the functionality. This concept makes it easier to extend room functionality simply by adding to it. People in the room are simply its subscribers. Maybe that example can help you explain more clearly what you have in mind with public groups in Mastodon, their usage, purpose, limits.
From what I understand, the semantics about Join/Leave vs. (un)follow seems to be more of a help for you to avoid messing things up internally, making things change in a clear way by not using the same vocabulary. I’m not sure how this works inside Mastodon, but from outside it seems like a bad idea to implement something that replicates the functionality of existing concepts for the purpose of a clean migration. Surely I missed something about this topic, and would appreciate being enlightened.
Most of my points in this discussion revolve around a singular concept from over two decades implementing groups on various projects and protocols. That concept is simply that public groups are easy and private groups are hard - and quite different. If you want a common interface which you can use for both public groups and private groups, start with private.
Otherwise you’re going to end up with two completely different groups interfaces and a lot of legacy code and migration strategies to ultimately reconcile them. These efforts and the user churn they introduce need to be taken into account.
So far I think everybody joining this discussion has just decided that private groups are hard so they’re going to do public first. They’ve completely missed the point. Anybody can do public groups. And if you’re building a groups-aware application, it makes sense to start with the easiest.
But that’s not what we’re doing here.
If you’re building a “federated standard for groups” which includes the ability to have private groups, you really need to start at the other end of the problem and work backward so that you can ultimately provide a common interface and based on a specification which is consistent for both.
Regarding Mastodon, I have decided to restrict it to public groups (at least for the initial implementation) for the following reasons:
several existing server administrators understandably pointed out they do not want to be hosting hate speech groups are illegal groups and have no way to know. Admittedly, the same issue exists with private posts and direct messages, but I think the scale of the issue would be different with fully-fledged groups. Mainstream media platforms “solve” this issue with automatic content detection in private groups, but that has different issues and is not something we can realistically do anyway.
the Group feature in Mastodon is part of a NLnet grant, and that grant expires real soon. I must have something to show (including federation code) really soon if I want to receive any payment for my work on it, so I need to keep the scope reasonably small to hope to manage that
I do not think private and public groups are that conceptually different, and I do have private groups in mind when developing support for public groups. That’s one of the reasons why I want an unambiguous way to signal that a group’s posts are to be public: to leave the door open for private groups. I do not think implementing public groups first makes implementing private groups any more complicated later on, even though we will have to devise a way to efficiently fetch and/or authenticate the distributed group posts (current proposals include LD-Signing the group posts, or having the group issue limited-time tokens to group members).
I’ve been thinking about it, @Claire, and to me the “public groups” you’re describing are more of a different audience scope. Is it something you have thought about? I can see how the wider notion of “groups” is relevant, especially when it comes to users roles as group moderators (especially with the remote functionality).
Still, with regard to private groups, not only ‘posts’ must be authenticated, but also access to the member list, etc. In any case, I think you’re on the way to wrapping up the NGI0 Discovery grant and you should focus on that. Once this first step is implemented, the discussion can go on with the standardization of “groups” in a wider perspective.
My 2cts about Follow/Join, and an alternative proposal for (private) Groups + Amplifiers
Personally I see no difference between Follow and Join in the case of a public group, and still have doubts about the usefulness of making such distinction in the case of private groups, since there’s no reason why one would have access to a group’s postings if they are not part of it. Having a public actor – an amplifier – relaying private group activity to the public might provide a simpler mean to distribute otherwise private contents to a wider audience. Amplifier might be a sort of as:Service that changes the scope of an audience to as:Public. This way, you would keep the concept of groups as simple as possible, only requiring flags for who can post, whether membership is automatically granted or moderated (and by whom), and who has privileges in this group.
Right, but what about following the group actor? I thought non-members will be able to Follow() the group actor and receive group’s posts in their inboxes.
Without this ability, group would behave like a group chat, which is a nice feature but other protocols (matrix/xmpp) can already do that. In my view, one of the primary use cases for “groups” in social network is aggregation and amplification of signals. Do you plan to support this use case, perhaps at a later stage?
Has anyone implemented private ActivityPub groups before? If so, what implementation would you suggest as a standard?
Yes, I’ve implemented private groups for a number of ActivityPub projects, and that work from any ActivityPub capable service (as well as a couple of other protocols) without modification. I’ve also managed to provide compatibility with (iirc) 10 of the current 12-15 completely different groups implementations.
I don’t suggest anything as a standard. I’d be willing to support all 12-15 implementations like we did with quoteUrl - except some of them conflict with other implementations and a couple aren’t documented.
Sure, posts is just the most important part of it.
I am working on it and focusing on it, with something based on my earlier proposal. I’m just trying to get the conversation going in the hope we come up with something that avoids ambiguity and leaves the door open to other use cases by the time the implementation is merged.
This is not something I’m currently planning to do, but overall that seems fine to me as long as there is no ambiguity that Join and Follow do not mean the same thing (which there currently very much is from the looks of this thread).
This is a bold claim that I’m afraid hides a significant number of hacks and tradeoffs. I might misremember or misunderstand, but last time I checked, private group posts were sent in direct messages to the group, then re-published by the post as its own (with metadata pointing to the intended author but not authenticating them). To be fair, I fail to see how you can do much more in a way “that works from any ActivityPub capable service” but the inability to authenticate messages is an important tradeoff worth mentioning, and the overall UX is a mess (at least from the barely “ActivityPub capable services”).
Supporting 12-15 completely different implementations is not something we are interested in, especially when those implementations have widely different UX expectations and the result ends up being unpredictable and incomprehensible.
On a side note, I’d be interested in knowing where to find documentation on the protocol extensions added or supported by your ActivityPub projects, because I did spend some time searching for how groups (including private ones) worked in them and only found a few incomplete scattered descriptions (I am not blaming you, Mastodon isn’t exactly an example of how to do this either).
Oh and we do authenticate relayed messages using LD-Signatures, but some projects refuse to support those and therefore can’t authenticate authors of relayed posts. I believe Mastodon can and does.
Thanks, it’s one of the documents I was referencing. It’s a bit incomplete and vague, but it’s a start.
I’m not denying that trying to bring new features to fediverse implementations that don’t have explicit support for them is going to involve hacks. But I think at some point we have to stop adding to the pile of hacks and go with something that has clear semantics.
Mastodon does verify LD-Signatures for some purposes, and it does issue them, but only when:
the document being sent is not intended to be public (so it wouldn’t LD-Sign a DM to a group actor), and
@Claire Speaking of LD signatures, is there any chance that Mastodon will support other JSON canonicalization algorithms? LD signatures standard doesn’t exist anymore and has been replaced with Data Integrity spec. It is difficult to find an RDF library, and I think this is one of the reasons why embedded signatures are not widely used in Fediverse, despite the benefits they provide.
I mentioned this in related Mastodon issue, but haven’t got any answer yet.
But I think at some point we have to stop adding to the pile of hacks and go with something that has clear semantics.
That’s why we’re all here. But while we’re trying to come to agreement on something that has clear semantics, the people I support have public and private groups – and they federate across multiple projects and protocols. I don’t like the method any more than you do. But sometimes we have to work around vague and incomplete protocols and hostile/condescending developers on other projects - and just get on with it.
FEP-400e is a step in the right direction. We support it today and can use that for the top-level post and avoid the DM hack once it’s supported by a few more projects - especially the ones with large userbases. Until they do, DMs are compatible with private groups and most every platform supports them. Mentions are not compatible with private groups and FEP-400e is currently only supported by a small handful of projects.
We also have working object-level relay signatures on the Nomad side (using salmon over json), but it will probably be a while before the rest of the fediverse moves towards object level signatures. Then we’ll have 3rd party relayed content that’s verifiable and the signature encapsulated in the object itself rather than an artifact of transmission or restricted only to full activities. That critical infrastructure component remains a real mess and if we started fixing it today, it will still be a mess for at least a year or three before it gets better.
I’ve also seen some preliminary drafts for expressing permissions and rights, so there’s hope that others in the fediverse will one day support rich granular permissions (as we do) because that reduces spam and harassment for everybody in the network. Then we can get rid of a few more hacks.
It’s a work in progress. But we always start by making it work. In case, I’m not building consumer products and I’m not selling anything. So please open a separate forum topic for bashing developers and software you don’t like for some reason.
Sorry, I have missed that. I can’t give you a definitive answer at this time, but if we’re going to continue providing embedded signatures (which we may reconsider, because the way it currently works means you can’t easily revoke them), it would make sense moving away from what appears to be an outdated draft, yes.
I’m not trying to sell anything either (though I do have a monetary incentive in having something done soon, with the NGI0 Discovery Fund), and I do not consider Mastodon users to be consumers, but people who deserve to have a decent a consistent user experience.
Sorry if my earlier messages came across as bashing other developers or software. That was not the intention, and while the current state is a mess, I’m not blaming anyone for that, and Mastodon is certainly no stranger to making the protocol more of a mess in general.
In order to continue going forward, I’d like to sum up my goals and concerns with the Mastodon implementation, as well as how the current proposals support them (or fail to do so):
we want groups as separate places/collections/timelines in which group members can post, and moderated by group moderators (who can reject or delete posts, kick or ban members, and accept/reject new members)
we are interested in compatibility with other Fediverse implementations that support groups
but we are not interested in providing any kind of compatibility with projects that cannot natively support that feature (such as current and past Mastodon versions).
This is because we believe this provides a wildly inconsistent and confusing user experience, which we want to avoid as much as possible.
Another reason is that “ActivityPub capable services” that would operate without specific knowledge of groups would face a massive challenge when switching to native groups with clearer semantics: what do you do of your old “compatibility” view of groups on which you had different assumptions?
we are not currently interested in private groups. Indeed, in addition to the additional technical complexities, private groups come with additional moderation challenges and clashing expectations of privacy and ability to moderate.
Talking fediverse users, server administrators, and fediverse software developers, it is clear that a lot of people are extremely distraught with the idea of potentially hosting private groups they have no way of inspecting, while there is also a lot of people considering that a server administrator looking into private groups they are not a member of would be an unacceptable violation of privacy.
I happen to agree with both these concerns, and so the most logical conclusion seems to not support such private groups.
Of course, a server administrator who considers it acceptable to screen private group posts could make that a clear upfront policy, but in the context of federated groups, the policies of all members’ servers must align.
That being said, while I’m only considering groups with public posts for now, I understand there is a use case for private groups, and I do not want to close the door to them in Mastodon, nor make it any harder for other projects that want to support them to do so.
This means that we need a way to make sure a group we join does not expect any of its messages to be private, so that we don’t risk leaking any of them nor fail to display some that users would expect to see.
This means, at least from my perspective, we need (I may be forgetting something):
a way to join and leave groups : Join and Leave seem fine for that. Follow and Undo Follow may also work but we’ve seen in this thread that these are sometimes given multiple interpretations
a way to submit posts to the group: this is covered by (at least what I understand of) FEP-400e
a way for the group to distribute those posts: the group actor Adds submitted posts to its wall, though private groups do need another mechanism (object signatures, fetch tokens, …)
a way for a group actor to reject posts: covered by FEP-400e
a way for a group actor to delete posts: not explicitly covered, but it would make sense for them to Remove it
a way to signal whether the group posts are expected to be public
this is more specific to our requirements, but a way for even public group posts to not be compatible with group-unaware services such as Mastodon
This is mostly covered by your proposal at Standardizing on ActivityPub Groups - #48 by macgirvin except 6 or 7. In addition, other well-established projects use Group actors to represent a group of people as one entity, not a group that people can join and post into, so that may be a problem. If I remember correctly, that is the case of PeerTube.
You should keep in mind that FEP-400e is nothing more than documentation of how group federation works in one specific project (Smithereen). According to this comment, there was no consensus achieved with any other project when the FEP was finalized, and it seems that no other project has implemented the FEP so far. You can also see for yourself in the socialhub thread that there were many open discussions both before and after finalization was requested, which were never resolved.
On the other hand, Im curious what you think about Lemmys implementation of group federation. Its quite simple, persons send activities with the group in cc, which then announces it to all followers. This means that its already compatible with many other projects (including Mastodon), unlike FEP-400e which would probably require changes in all involved projects to support it. Its also worth noting that Lemmy is the largest Activitypub project with group support, and the implementation is already proven to work in production without problems.
