flesh out how flair could work

proposals/1772-groups-as-rooms.md

@@ -73,7 +73,7 @@ groups and doesn't have to be edited atomically.
 
 Name, Topic, Membership etc share the same events as a normal room.
 
-The flair for a group is given by the room avatar.
+The flair image for a group is given by the room avatar.
 
 Long description requires a new event: `m.room.description`.  This can also be
 used for rooms as well as groups.
@@ -125,11 +125,34 @@ useful for normal rooms.
 
 ## Flair
 
-TODO: We need to establish how users should safely advertise their flair.
-Perhaps they can claim whatever flair they like on their profile
-([MSC1769](https://github.com/matrix-org/matrix-doc/issues/1769)) and clients
-need to then doublecheck whether the assertion is true by peeking in the room in
-question to check it's true?
+A proposal for how to safely determine user flair is:
+
+ * User publishes the groups they wish to announce on their profile
+   ([MSC1769](https://github.com/matrix-org/matrix-doc/issues/1769)
+   as a m.flair state event: it lists the groups which they are advertising.
+   
+ * When a client wants to know the current flair for a set of users (i.e.
+   those which it is currently displaying in the timeline), it peeks the
+   profile rooms of those users.  However, we can't trust the flair which the
+   users advertise on the profile - it has to be cross-referenced from the
+   memberships of the groups in question.
+   
+To do this cross-referencing, options are:
+
+ 1. The client checks the group membership (very inefficient, given the server
+    could/should do it for them), or...
+ 2. The server checks the group membership by peeking the group and somehow
+    decorates the `m.flair` event as validated before sending it to the client.
+    This is also inefficient, as it forces the server to peek a potentially large
+    group (unless we extend federation to allow peeking specific state events)
+ 3. The origin `m.flair` event includes the event_id of the user's
+    `m.room.membership` event in the group.  The server performing the check can
+    then query this specific event from one of the servers hosting the group-room,
+    and we perhaps extend the S2S API to say whether a given state event is current
+    considered current_state or not.  If the `m.room.membership` event is confirmed
+    as current, then the `m.flair` is decorated as being confirmed.
+
+Of these, option 3 feels best?
 
 ## Dependencies
 
@@ -171,4 +194,4 @@ How does this work with
 ## History
 
  * This replaces MSC1215: https://docs.google.com/document/d/1ZnAuA_zti-K2-RnheXII1F1-oyVziT4tJffdw1-SHrE
- * Other thoughts that led into this are at: https://docs.google.com/document/d/1hljmD-ytdCRL37t-D_LvGDA3a0_2MwowSPIiZRxcabs
+ * Other thoughts that led into this are at: https://docs.google.com/document/d/1hljmD-ytdCRL37t-D_LvGDA3a0_2MwowSPIiZRxcabs