Merge 77bb8b049a into e9f0f31d27
henri2h
1 week ago
committed by
GitHub
commit
a86980d023
@ -0,0 +1,293 @@
|
||||
# MSC3639: Matrix for the social media use case
|
||||
|
||||
Matrix is currently mainly used for chats, however, recent projects
|
||||
have shown that it is possible to use it for social media.
|
||||
|
||||
This proposal is to formally specify this usage and ensure
|
||||
a compatibility between the different social media projects.
|
||||
|
||||
## The idea
|
||||
|
||||
This MSC tries to cover those following social media cases:
|
||||
|
||||
* **'Regular'** social media like Circles or MinesTRIX
|
||||
* **'Art'** social media like Matrix Art
|
||||
|
||||
## The proposal
|
||||
|
||||
To cover those use case, we will separate our proposal in two part.
|
||||
|
||||
* **Room types**: the container which will store the events.
|
||||
* **Special events types**: to differentiate post and comment from room messages.
|
||||
|
||||
|
||||
### Room
|
||||
|
||||
Social media generally allow the user to have a profile where he can
|
||||
post content visible to all his followers. Others allow also creating
|
||||
groups which allow the same things without being owned by a specific
|
||||
user. This is the two functions that we want to add.
|
||||
|
||||
Therefore, we propose two room types. Types are defined according to
|
||||
[MSC1772 - Matrix spaces](https://github.com/matrix-org/matrix-doc/pull/1772).
|
||||
|
||||
* `m.social.profile`
|
||||
* `m.social.group`
|
||||
|
||||
Those two rooms will act as a container for events of different types, which
|
||||
will be displayed only on a specific client. The type is used to set the
|
||||
general purpose of the room.
|
||||
|
||||
#### Social media : The user profile
|
||||
|
||||
```
|
||||
m.social.profile
|
||||
```
|
||||
|
||||
**Usage:**
|
||||
|
||||
Used by a user to share content with his friends or the world.
|
||||
|
||||
* Owned by a single user.
|
||||
* The user can choose who can write on his profile.
|
||||
* Room visibility : public / private. Up to the user.
|
||||
* The user can have multiple profile (private / public ...)
|
||||
|
||||
This MSC remains voluntarily open as user may want to configure the room as he wishes.
|
||||
|
||||
*Small note about encryption:*
|
||||
|
||||
Clients should notify the user that encryption shouldn't be enabled
|
||||
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 sense.
|
||||
|
||||
**UI considerations :**
|
||||
|
||||
* Should make clear that this room is owned by a specific user.
|
||||
* 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
|
||||
|
||||
```
|
||||
m.social.group
|
||||
```
|
||||
|
||||
**Usage:**
|
||||
|
||||
* For group discussion
|
||||
|
||||
Group is just a regular profile room `m.social.feed` but with a
|
||||
slightly different UI as there is no single owner of the room.
|
||||
|
||||
|
||||
### Sending posts
|
||||
|
||||
We propose to define a custom type for posts.
|
||||
|
||||
```
|
||||
m.social.post
|
||||
```
|
||||
|
||||
**Why ?**
|
||||
|
||||
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.
|
||||
Thus, we need to avoid that a user end up "spamming" his room thinking
|
||||
the room is a regular chat room.
|
||||
|
||||
Therefore, we use different event type to separate the regular messaging
|
||||
from the social media posts. It will still be possible to send room message.
|
||||
However, those should not be displayed on the user wall / group.
|
||||
|
||||
**NB:** An initial version of the proposal was using extensible events but
|
||||
we decided to fall back to regular event while waiting for the extensible events
|
||||
proposal to stabilize.
|
||||
|
||||
|
||||
A type for general content. Its structure is of type:
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "m.social.post",
|
||||
"content": {
|
||||
"body": "The content of the post, can be Markdown",
|
||||
"m.social.image-ref": [ // optional
|
||||
"$<event_id>",
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Embedding images in the post
|
||||
|
||||
If we want to embed images in the post, we should first send the image as a regular
|
||||
event and then put the image event id in the `m.social.image-ref` attribute of the
|
||||
post content. This, to allow user to allow a user to comment an image individually
|
||||
or to reuse it in different posts. This allows us also to display more easily all
|
||||
the images who have been posted in the room.
|
||||
|
||||
|
||||
### Reactions
|
||||
|
||||
* Emoji reactions are standard matrix reactions.
|
||||
* However, comments on posts will be threads.
|
||||
|
||||
Comments will have the same structure as post but will have the 'm.social.comment'
|
||||
type to allow the owner of the room to allow commenting but preventing the other users
|
||||
to send posts on this group. As said, comment need to have a thread relation to a post
|
||||
event. Failing to do so will have no impact, but the event shouldn't be displayed.
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
{
|
||||
"type": "org.matrix.msc3639.social.comment",
|
||||
"content": {
|
||||
"body": "ok",
|
||||
"m.relates_to": {
|
||||
"rel_type": "m.thread",
|
||||
"event_id": "$GKhFi7r_7bFx4pWUPfPox8nbCM27aqRkFHwK0PG-Avw"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Alternative
|
||||
|
||||
There has been some discussion about whether we should restrict the
|
||||
room to a specific type of content (i.e. the type of the room define
|
||||
the UI and how the content should be treated). Here is some consideration about the alternative proposal.
|
||||
|
||||
### Advantage of this approach
|
||||
|
||||
* flexibility
|
||||
|
||||
If one day we use another client which could display video only
|
||||
feed, then we could reuse this room and start posting other events
|
||||
type to this room.
|
||||
|
||||
It will help as we have all our followers in the same room.
|
||||
|
||||
### Disadvantages of this approach
|
||||
|
||||
#### Complexity / room size
|
||||
|
||||
This approach comes with a higher complexity.
|
||||
|
||||
* filter algorithm more complex because we need to take into account
|
||||
the multiple events type.
|
||||
* higher room size (the ratio event displayed / event in the room will
|
||||
be higher). May lead to slower client.
|
||||
|
||||
We need to take into account that there might be content which just
|
||||
can't be displayed by the social media app that we are using.
|
||||
|
||||
The app should warn the user about this.
|
||||
|
||||
// TODO : See how the room size impact the time to join.
|
||||
The discussion may need to take into account the time it takes to join one large room
|
||||
with many states vs many small ones. (Is it preferable to have many small rooms
|
||||
that are auto joined or one big room with multiple 'feeds' (different event types)
|
||||
in it.)
|
||||
|
||||
#### Moderation
|
||||
|
||||
* if we let the user post content in a room it may be more complex
|
||||
to moderate the room as the user could write event using an event
|
||||
type that we don't use. Means longer time before removing those events.
|
||||
|
||||
|
||||
## Privacy
|
||||
|
||||
The permissions of the rooms should be easily editable by the user.
|
||||
|
||||
Special attention should be accorded to those events,
|
||||
|
||||
```
|
||||
m.room.join_rules
|
||||
m.room.encryption
|
||||
m.room.power_levels
|
||||
```
|
||||
|
||||
* It must be clear to the user if the actual room is private or not.
|
||||
* It must be clear to the user if the actual room is end-to-end encrypted.
|
||||
* The user should be able to restrict the users able to write in his room.
|
||||
* The user should be that all the followers can see each others.
|
||||
|
||||
|
||||
|
||||
## Unstable prefix
|
||||
|
||||
The following mapping will be used for identifiers in this MSC during development:
|
||||
|
||||
|
||||
| Proposed final identifier | Purpose | Development identifier |
|
||||
| ------------------------- | ----------------------- | ------------------------------------- |
|
||||
| `m.social.profile` | Profile room | `org.matrix.msc3639.social.profile` |
|
||||
| `m.social.group` | Group room | `org.matrix.msc3639.social.group` |
|
||||
| `m.social.post` | Post event | `org.matrix.msc3639.social.post` |
|
||||
| `m.social.comment` | Comment on a post event | `org.matrix.msc3639.social.comment` |
|
||||
| `m.social.image-ref` | Link to an image event | `org.matrix.msc3639.social.image-ref` |
|
||||
|
||||
|
||||
|
||||
## Further idea
|
||||
|
||||
### Image post
|
||||
|
||||
An earlier version of the proposal allowed to define custom events for
|
||||
|
||||
### Alternative proposal
|
||||
|
||||
Instead of filtering the room events according to their types,
|
||||
we could filter the room directly according to his type.
|
||||
Thus defining how the room UI.
|
||||
|
||||
We could define
|
||||
|
||||
* m.social.feed : for regular social media
|
||||
* m.social.image : for image social media
|
||||
|
||||
This solution solve the main disadvantages of the previous solution
|
||||
but lacks the flexibility.
|
||||
|
||||
|
||||
### Idea: Tagging
|
||||
|
||||
*NB:* This is only an idea
|
||||
|
||||
We could add a `tags` entry in the event content. The content of those
|
||||
tags could be 'hashtags'.
|
||||
|
||||
This will be useful for art social media. But we could also see an
|
||||
implementation in regular social media like to tag other person.
|
||||
|
||||
```json
|
||||
{
|
||||
"m.social.post": [/* the post content */],
|
||||
"m.social.tag": [
|
||||
"@mxid",
|
||||
"my chair"
|
||||
]
|
||||
}
|
||||
```
|
||||
### Unstable prefix
|
||||
|
||||
| Proposed final identifier | Purpose | Development identifier |
|
||||
| ------------------------- | ---------------------------------------------------------------- | --------------------------------- |
|
||||
| `m.social.image` | Image event (deprecated, could be restored in a further version) | `org.matrix.msc3639.social.image` |
|
||||
| `m.social.tags` | Tags property of `m.social.post` or `m.social.image` event | `org.matrix.msc3639.social.tag` |
|
||||
|
||||
|
||||
Loading…
Reference in New Issue