From 5b0240fe927a10c6f06ea75e1d5f19cac0d95ec5 Mon Sep 17 00:00:00 2001 From: henri2h Date: Tue, 11 Jan 2022 23:38:37 +0100 Subject: [PATCH] fix: typo --- ...ZZ-matrix-for-the-social-media-use-case.md | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/proposals/MSCZZZZ-matrix-for-the-social-media-use-case.md b/proposals/MSCZZZZ-matrix-for-the-social-media-use-case.md index 55d06e096..7eb8cfb01 100644 --- a/proposals/MSCZZZZ-matrix-for-the-social-media-use-case.md +++ b/proposals/MSCZZZZ-matrix-for-the-social-media-use-case.md @@ -9,9 +9,9 @@ a compatibility between the different projects. While writing this specification, the following principles should be respected: -* **simplicity in mind:** the solution should be the simplest one +* **Simplicity in mind:** the solution should be the simplest one -* **not confusing:** The end user shouldn't know the theoretical usage +* **Not confusing:** The end user shouldn't know the theoretical usage of the room. i.e. A user which isn't using the social media app shouldn't be able to 'spam' the main room. @@ -26,7 +26,7 @@ The discovery of the user rooms using profile as room is the topic of While Matrix could be used for almost anything, we will restrict ourselves on the following use cases. -* **'Reqular'** social media (Twitter style, Facebook : Circles, MinesTRIX) +* **'Regular'** social media (Twitter style, Facebook : Circles, MinesTRIX) * **'Art'** social media (Matrix Art) ## The proposal @@ -76,7 +76,7 @@ Clients should notify the user that encryption shouldn't be enabled on 'big room 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 recommanded maximum number of +TODO (1) : Define what large room means and what is the recommended maximum number of participants in a E2EE room. **UI considerations :** @@ -101,7 +101,7 @@ slightly different UI as there is no single owner of the room. This type is only an idea yet and should be defined more clearly. -May be the topic of another MSC. +Maybe the topic of another MSC. ``` m.social.event @@ -121,7 +121,7 @@ What should be defined for the event * event time end * add a way to say if we will come (maybe use regular polls) -regular events : the actual event is already defined in matrix, +Regular events : the actual event is already defined in matrix, no need to reimplement. ### Room content @@ -157,14 +157,14 @@ be displayed on the user wall / in the group. **Why defining a specific m.social.pictures event ?** When sending events, we want to be sure that the other users will be -be able to see our posts. Thus it might be problematic with image +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 images only social media or is not able to render +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 sended post. +to previously sent post. -Defining separate types help making sure the app displaying them +Defining separate types helps make sure the app displaying them is able to support all the content of this specific event type. See the later point for regular room message fallback. @@ -184,7 +184,7 @@ Could be text, pictures, video ... **TODO:** -Define what base events the clients supporting those event +Define what base events the clients supporting those events should be able to display. like: @@ -297,7 +297,7 @@ One may want to advertise the room that he posted a specific content and provide a link to it). A [solution adapted from the one proposed by @MurzNN](https://github.com/matrix-org/matrix-doc/pull/1767#issuecomment-787431678) -is to define event like this one +is to define events like this one ```json { @@ -330,7 +330,7 @@ is to define event like this one } ``` -On regular chat client like element, it should render as a simple link. +On a regular chat client like element, it should render as a simple link. Another solution is to just send two events, one m.post.post or m.social.image and a summary in the form of a room message. @@ -360,7 +360,7 @@ See [MSC3394 - new auth rule that only allows someone to post a message in rela for such a proposal. -## Aternative +## 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 @@ -417,7 +417,7 @@ We could define * m.social.image : for image social media This solution solve the main disadvantages of the previous solution -but lacks the flexiblity. +but lacks the flexibility. ## Privacy