We propose two events type to categorize the content of the event.
```
m.social.post
```
**Why ?**
As the room is displayed alongside the user's 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.
Thus, we need to avoid that a user end up "spamming" his room thinking
the room is a regular chat room.
The solution is to separate the regular messaging from the social
media posts. Thus, defining special events different from the regular
messaging events.
It will still be possible to send room message. But those should not
be displayed on the user wall / in the group.
**Types:**
* `m.social.post`
* `m.social.pictures`
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.
#### Base event
The structure of the event should just be extensible events.
#### Social: Post
```
m.social.post
```
A type for general content. It's structure is of type:
A type for general content. Its structure is of type:
```json
{
"type": "m.social.post",
"content": {
"msgtype": "m.text",
"body": "<h1>The awesome story</h1><p>A long time ago in a galaxy far, far away...</p><ahref='...'>Read full post</a>",
"m.social.post": [
{
"m.text": "The first part of full text of story, located before image.",
}
],
"m.social.image-ref": [
"body": "The content of the post, can be Markdown",
"m.social.image-ref": [ // optional
"$<event_id>",
]
}
}
```
If we want to embed images in the post, we should first send a `m.social.image` event and then it's 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 allow us also to display more easily all the images who have been posted in the room.
**TODO:**
#### Embedding images in the post
Define what base events the clients supporting those events
should be able to display.
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.
#### Social: Image
Base : [MSC3552 - Extensible Events - Images and Stickers](https://github.com/matrix-org/matrix-doc/blob/travis/msc/extev/images/proposals/3552-extensible-events-images.md)
```
m.social.image
```
Events adapted to client like Matrix Art to build pictures only
social media.
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:**
The list of arguments that should be part of event["content"]
// TODO
### Reactions
like :
* Emoji reactions are standard matrix reactions.
* However, comments on posts will be threads.
* m.image
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:**
```json
{
"type": "m.social.image",
"content": {
"m.social.image": [
{
"m.caption": [
{
"m.text": "Tramline in Berlin"
},
{
"body": "Tramline in Berlin",
"mimetype": "text/html"
}
],
"m.file": {
"mimetype": "image/jpeg",
"name": "_MG_0641.jpg",
"size": 10158773,
"url": "mxc://"
},
"m.image": {
"height": 3456,
"width": 5184
},
"m.text": "Tramline Berlin",
"m.thumbnail": [
{
"height": 533,
"mimetype": "image/jpeg",
"size": 215496,
"url": "mxc://nordgedanken.dev/",
"width": 800
}
]
}
]
},
}
```
#### Linking posts/pictures to the regular chat
One may want to advertise the room that he posted a specific content
(only visible in a social media client) that may be of interest to user
and provide a link to it.
This should be up to the user. The client could display a 'advertise in the chat room' button.
A [solution adapted from the one proposed by @MurzNN](https://github.com/matrix-org/matrix-doc/pull/1767#issuecomment-787431678)
is to define events like this one
```json
{
"type": "m.room.message", // will be m.text in the future. According to extensible events
"type": "org.matrix.msc3639.social.comment",
"content": {
"msgtype": "m.text",
"body": "<h1>The awesome story</h1><p>A long time ago in a galaxy far, far away...
</p><ahref='...'>Read the full post in your favorite social matrix client</a>",
"m.social.post": [
{
"m.text": "The first part of full text of story, located before image.",
},
{
"m.file": {
"mimetype": "image/jpeg",
"name": "_MG_0641.jpg",
"size": 10158773,
"url": "mxc://"
},
"m.image": {
"height": 3456,
"width": 5184
},
},
{
"m.text": "The ending text of full story after image.",
On a regular chat client like element, it should render as a simple link.
Another solution is to just send two events, one `m.social.post` or `m.social.image`
and a summary in the form of a room message.
##### Todo
Some client may not be web pages, thus a `href=""` may not make sense.
A text fall back, `Open in xxx to see the whole post` could make sense.
### Reactions
* Emoji reaction will use the regular event.
* However, comments on posts will be threads.
For rooms where only the user can write, it could be interesting to
allow other users to have a comment only permission.
See [MSC3394 - new auth rule that only allows someone to post a message in relation to another message](https://github.com/frandavid100/matrix-doc/blob/threaded-replies/proposals/3394-new-auth-rule-that-only-allows-someone-to-post-a-message-in-relation-to-another-message.md)
for such a proposal.
Another way to achieve this could be to use a different event type for comment so we can prevent people to send a post in a group but still allow them to comment.
### Tagging
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"
]
}
```
## 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 (the main one)
### Advantage of this approach
* flexibility
@ -342,7 +182,6 @@ 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.
@ -369,19 +208,6 @@ in it.)
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.
### 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.
## Privacy
@ -398,21 +224,70 @@ 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 |
henri2h
3 years ago