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:
- We start with a wiki post and collect use cases, requirementes and other considerations.
- Once things are a bit structured, we can organize a meetup to discuss the ins and outs.
- 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.