Those two rooms will act as a container for events of different
Those two rooms will act as a container for events of different
types, which will be displayed only on a specific client.
types, which will be displayed only on a specific client. The type is used to set the general purpose of the room.
The type is used to set the general purpose of the room.
#### Social media : The user profile
#### Social media : 'Regular' or 'feed'
```
```
m.social.feed
m.social.profile
```
```
**Usage:**
**Usage:**
Used by a user to share content with his friends or the world.
Used by a user to share content with his friends or the world.
* Owned by a single user
* Owned by a single user.
* Writing in this room could be owner only or any member. Up to the user.
* The user can choose who can write on his profile.
* Room visibility : public / private. Up to the user.
* Room visibility : public / private. Up to the user.
* A user could have multiple of them
* The user can have multiple profile (private / public ...)
Small note about encryption:
This MSC remains voluntarily open as user may want to configure the room as he wishes.
Clients should notify the user that encryption shouldn't be enabled on 'big room'. (1)
*Small note about encryption:*
On a side note, end-to-end encrypted rooms with a very large number of 'followers'
don't make a lot of change.
TODO (1) : Define what large room means and what is the recommended maximum number of
Clients should notify the user that encryption shouldn't be enabled
participants in a E2EE room.
on 'big / public room'. On a side note, enabling end-to-end encrypted
rooms with a very large number of participants don't have a lot of sence.
**UI considerations :**
**UI considerations :**
* Should make clear that this room is owned by a specific user.
* Should make clear that this room is owned by a specific user.
* UI type is up to the client (feed, pictures waterfall ...)
* UI type is up to the client (feed (list view), pictures waterfall (grid) ...)
##### Room visibility
Most users will want to have a private profile. However, the question
is now how can other user follow our profile ? It is always possible to
invite them in the room but in the world of social media, this is kind
of weird. This will be like sending a follow proposal.
This could be solved with knocking. The question being how do we discover the room ?
* room alias could be an answer (TODO: is it possible to get the room type ?)
* An other way could be to use a kind of profile as space. i.e. a place where a user can publicly advertise room that are related to him. This idea could be the topic of a following MSC.
#### Social media : Groups
#### Social media : Groups
@ -93,7 +106,7 @@ We propose two events type to categorize the content of the event.
**Why ?**
**Why ?**
As the room is displayed alongside the user' regular chats rooms we need
As the room is displayed alongside the user's regular chats rooms we need
to make it clear to the user that it's a specific room.
to make it clear to the user that it's a specific room.
Thus, we need to avoid that a user end up "spamming" his room thinking
Thus, we need to avoid that a user end up "spamming" his room thinking
the room is a regular chat room.
the room is a regular chat room.
@ -107,24 +120,9 @@ be displayed on the user wall / in the group.
**Types:**
**Types:**
* m.social.post
* `m.social.post`
* m.social.pictures
* `m.social.pictures`
**Why defining a specific m.social.pictures event ?**
When sending events, we want to be sure that the other users will
be able to see our posts. Thus, it might be problematic with image
only social media if we send a post with only text and then want to
display it in a image only social media or is not able to render
a fraction of the post (like a post with text, video, image).
This becomes problematic when the user start making reference
to previously sent post.
> We define separate types to make sure the app displaying them
is able to support all the content of this specific event type and
make sure image only and regular feeds don't mix.
See the later point for regular room message fallback.
#### Base event
#### Base event
@ -199,6 +197,22 @@ social media.
UI could be a grid or a list view of pictures.
UI could be a grid or a list view of pictures.
**Why defining a specific m.social.pictures event ?**
When sending events, we want to be sure that the other users will
be able to see our posts. Thus, it might be problematic with image
only social media if we send a post with only text and then want to
display it in a image only social media or is not able to render
a fraction of the post (like a post with text, video, image).
This becomes problematic when the user start making reference
to previously sent post.
> We define separate types to make sure the app displaying them
is able to support all the content of this specific event type and
make sure image only and regular feeds don't mix.
See the later point for regular room message fallback.
**Required content:**
**Required content:**
The list of arguments that should be part of event["content"]
The list of arguments that should be part of event["content"]
@ -414,10 +428,10 @@ m.room.power_levels
The following mapping will be used for identifiers in this MSC during development:
The following mapping will be used for identifiers in this MSC during development:
Proposed final identifier | Purpose | Development identifier
| Proposed final identifier | Purpose | Development identifier |
henri2h
4 years ago