Wow, love your feedback once again, Mike. Encouraging indeed to see how much of this is already worked out, and we now have opportunity to standardize more of this across the board. I’ll try to give a structured follow-up, but first…
Do you really think that? I agree that groups on traditional social media are nothing new, but have the feeling that what we have on the fediverse goes a bit beyond that. First of all we are federated which comes with its challenges, but most importantly we want to achieve as much interoperability as possible for a wide range of different application types and ‘business domains’. The UX’es for each of these will also very much depend on the use case they implement.
I quoted 3 snippets together. I understand that fedizens might hate it, but their confusion stems from how the UX/UI exposes the underlying model. Bringing more flexibility to the model, while retaining as much backwards-compatibility with what’s already out there means that no renewed confusion or dislike will occur, as the UX in current apps can remain unchanged.
Wrt the last part of the quote I am curious. Looking at my diagram above is “A Group has a Collection of Relationships to other Actors” already implemented in some way, or commonly done a different way? For instance the Valueflo.ws model (not AS/AP, but Linked Data) is “Actor has Relationships to other Actors”, i.e. much more generic. But maybe too generic was my thinking, hence I added a relationships collection to Group.
I don’t mind if the model we adopt is very different than what I imagined, but to me most important is to be able to deal with rich semantic relationships in some way or other. In a Communities subdomain I see these relationships as core to providing the “magic space between communities”.
Follow and/or Join?
You are right to say that currently one or the other can be chosen, and for current use cases Join seems to me to be the better choice too. But from a functional perspective I see merit in supporting both Join and Follow, as they have a meaningful semantic difference.
- Follow would be exactly similar to how stuff works when a person follows another person, no changes in behavior for groups.
- Join would indicate the person wants to have a deeper level of involvement, and its app-specific what that means.
I am a would-be federated app dev, and have a use case where this difference is used. The project Outreach (not yet started) allows people / orgs in the commons to target campaigns at traditional social media via their own channels. In Outreach there may be “Climate change” and “Privacy” communities, and then for a fedizen that’s passionate for privacy:
- If you Follow the “Privacy” community you may receive this on your timeline: “Privacy International has started the campaign ‘Easy privacy practices to adopt’. Join the community to participate.”
- If you Join the community you’d get way more messages, e.g. like “Starting preparation of campaign ‘Easy privacy practices to adopt’ by Privacy International. Participate in the Outreach app to enlist your help.”
In my conceptual model it would be easy to distinguish between followers and members, as they are tracked in different collection, with the latter in relationships. (Note that it need not contain just Relationship objects, it might also contain Actor objects directly which corresponds to a member_of relationship, a default).
Privileges, permission model → out of scope
I agree with your notion that this is orthogonal, was my feeling as well, and same for granular permissions. (Note that my Discourse example probably boils down to granular permissions + circles/aspects).
An important topic to separately address, but can be out of scope wrt basic groups support.
Group topology → circles / aspects?
I think it is very interesting to this discussion to delve deeper into the mechanism you are using, and consider it for standardization.
Instances, site actor, community actor?
Propose: Make this a separate topic, for the definition of an additional FEP.
Delighted to hear about your work in this regard. Another case where Zap et al is probably ahead in exploring stuff. Though this topic goes a bit beyond the scope of basic groups support, it is important for discovery and interop. We may address it in a new topic, and eventually address a separate FEP for this?
I don’t know about your impl and ideas, but will provide some thoughts of my own. I compare actor model a bit to how Akka works. The instance / server can be considered as providing the actor system, and it has a root actor which corresponds to the ‘site actor’.
I don’t know what site actors are currently all being used for, but in my mind it deals only with technical concerns & responsibilities. E.g. involved with server health, admin/moderation and availability for federation (if I actually used Akka in the codebase I’d probably have a child actor ‘federation’ to delegate to). The details of this are beyond scope wrt this discussion.
The ‘Community’ actor (name doesn’t matter much, but it is a group) I referred to would be a child actor to the site actor. It doesn’t have a technical but a functional role. It provides insights into the member base that is available on the instance, and information about topics, rules, CoC, ToS. And the top-level access point to drilldown into group topology, if the instance provides more than a single group. A site actor would have 0…N community actors.
Groups decoupled from instances → out of scope?
Groups that are not tied to the single instance where they are created is an ‘advanced feature’ that may be out of scope for now. Unless its implementation later on - e.g. based on Nomadic Identity - would lead to breaking changes to the basic model we define now.