Automatic room picture generation

Nobody has claimed this yet.

Hello everyone,

**Description:**

I'm thinking of a feature that would generate a default picture for rooms that do not currently have---like some social media site do---, from the profile picture. I think having profile pictures is important, as identifing rooms based on distinct pictures is easier than based on some 2 letter id (with various colors). With multiple rooms it becomes an even bigger problem. My idea is something like this:

```
if( room has picture)
use picture
else
memberlist = every_room_member_who_has_a_set_profile_picture
pics = random_select ( memberlist, min(4, memberlist.size))
new_profile = generate_new_profile_from ( pics )
```
I think it needs to be done early and shouldn't be updated as it just makes it harder to find the room if it regularly changes profile picture. However it shouldn't be done at the beginning as one may start out with a room with no members, so it is not enough to generate it once during creation. My idea is that the profile picture should be regenerated once a member is added or removed from the room, EXCEPT:
- 4 images have already been used,
- until one of the user whose image is used in the room image has left the room,
- regeneration is somehow manually triggered.
It should be an option that can be turned on/off, and I think it would be great because it would solve this issue on bridge side as well (there is one social media platform I use, that generates picture for multi-user rooms, so no one takes the effort to set one up, which is also not a trivial task (maybe not even possible?) from the web based client). I was thinking of opening this issue with the bridge implementation, but I think this needs to be done on the homeserver side, as it happens also with matrix rooms, and also on a lot of other social media rooms.

The issue names no files, tests, or entry points. Start by reviewing the Matrix specification's existing room and profile-picture behavior, then determine where the proposed generation lifecycle and opt-in setting would belong. Done would require an agreed protocol-level definition before implementation can begin.

Written by the indexing model from the issue text.