No "Member" type in section 3.2

[evanp]

The case hasn't been made for the indirection inherent in a "Member" property.

Many group systems have direct membership, not a stand-in entity that represents membership. (Facebook Groups, for example.)

[bumblefudge]

I think this question presents an implicit decision tree:

• does a "stand-in entity" object need to be specified by this report, to prevent non-interoperable variants?
  • if so, is "passive" support mandatory, i.e. must a member on a different server be shown data from that membership object even if groups on the member's server wouldn't support those objects on its own groups?
    • UX (and user safety) would be horrible if "group-specific alias" were an optional extension, and a member on a non-supporting server doesn't see the aliases everyone is setting for themselves, particularly the people who rename themselves "Anon" and think no one knows their real account handle 😅
  • if so, how does [here-specified, core, non-extension] data from that membership object migrate across servers, per Move a group to a different host #34 ?
    • similarly, if "Anon"-aliased users get reverted to their real handles at migration 😬

[trwnh]

This issue was discussed in today's meeting: #42

• Issue 47 No "Member" type in section 3.2 #47

  • EP: Use case for Member type as distinct from the actor? Make it clear that we need it or see if there are ways to avoid it. Are we going to make it a required indirection.

  • a: it's a very convenient and natural point to hang all "membership concerns" from the same record. subreddits have flairs, discord has custom display names and avatars, etc, can also index in both directions (member has roles, role has members)

    • (in chat) BF: either you model membership "member-side" canonically and "group actor-side" at specific times, or vice versa, non? off the top of my portability-maxi head, actor-side canonical with [maybe non-portable] optional/extensions member-side feels like MVP/simplest

  • Mayel: for performance you don't want to scan the whole collection vs just checking a single id.

  • EP: It is O(n) so there is a real performance issue but it shouldn't keep us from ...

  • EP: I see the point in having it as an option for these situations of adding extra metadata ("i want my reddit flair") but my concern is that i want a mode where there can be a simpler relationship. an option at least to do that.

    • M (in chat): what about having both? a members collection with actors and an optional memberships collection

Echoing my thoughts from there:

• The indirection doesn't seem to be a significant burden to me; even in the case where you don't attach any extra information, it's not any "worse" per se than having a collection of activities instead of a collection of notes or persons.
• The information that we do want to attach is significant information that is important for the social expressivity inherent to a lot of richer group activities:
  • Pending status, expiring membership, etc
  • Roles and permissions, belonging to subgroups
  • Per-group display names and avatars, flairs, etc
  • Whether you used a specific invite
  • Deleting a membership and simultaneously purging all content/messages

Toward @bumblefudge's point re: portability, having all this information stored in a membership record and having the membership record be a part of the group's data (importable/exportable hopefully!) makes it easier to track all of this stuff in one place. It's a necessary primitive building block to have in the model. It's not necessary for every single group implementation to support processing every single metadata field that could be attached here, but at minimum you need to track "who is the member" and "which is the group", and you should track roles/permissions as well.

I guess one "prior art" aspect I can point to is how in LDP (Linked Data Platform), they defined a "BasicContainer" and a "DirectContainer" (and an "IndirectContainer"), so that people could opt into a simpler model if they only had "basic" needs (tracking containership only and not caring for inferring anything about the items in a container, like having a followers collection but not caring to specify that everything in that collection is necessarily following you). https://www.w3.org/TR/ldp/#ldpbc

We could similarly define a "basic group" and a "membership group", but this doesn't feel particularly worthwhile versus only defining a "membership group" (and using a minimal membership record).

[TallTed]

@trwnh — Could you change the ``` code fences in #47 (comment) into > quotes? Non-wrapped lines of code is much harder to read than wrapped lines of quotation.