formatting tweaks

proposals/3395-synthetic-appservice-events.md

@@ -17,7 +17,6 @@ For clarity, this MSC introduces a modest set events that could be extended by f
 - User logout
 - User deactivation
 
-
 ## Proposal
 
 An appservice must subscribe to the changes that it wishes to listen for. This can be done by setting a new
@@ -33,7 +32,7 @@ m.synthetic_events:
 ```
 
 Then, when the homeserver wishes to inform a appservice of an event it would send the event over the appservice `/transaction`
-API. The homeserver is NOT expected to retry these events if the appservice is down, 
+API. If the application service is down, these events SHOULD be retried when the appservice comes back up.
 
 ```
 PUT /_matrix/app/v1/transactions/{txnId}
@@ -52,7 +51,8 @@ PUT /_matrix/app/v1/transactions/{txnId}
 }
 ```
 
-For each of the event types given above, there is a definition:
+For each of the event types given above, there is an expected schema. As with all Matrix
+event contents, this can be extended to include implementation specific metadata.
 
 ### `m.user.registration`
 
@@ -60,7 +60,6 @@ This should be sent when a new user registers on the homeserver.
 
 ```json5
 {
-
         "type": "m.user.registration",
         "content": {
             "user_id": "@alice:example.com"
@@ -74,7 +73,6 @@ This should be sent when an existing user logs in on the homeserver.
 
 ```json5
 {
-
         "type": "m.user.login",
         "content": {
             "user_id": "@alice:example.com",
@@ -89,7 +87,6 @@ This should be sent when an existing user logs out of their session.
 
 ```json5
 {
-
         "type": "m.user.logout",
         "content": {
             "user_id": "@alice:example.com",
@@ -105,27 +102,24 @@ This should be sent when an existing user deactivates their account.
 
 ```json5
 {
-
         "type": "m.user.logout",
         "content": {
-            "user_id": "@alice:example.com",
+            "user_id": "@alice:example.com"
         }
 }
 ```
 
 ## Potential issues
 
-
 Appservices can now request permissions to reveal quite intimate details about each user, which means that homeserver
 administrators will need to be more careful when adding new appservice registrations. However, it has always been the
 case that appservices should be considered powerful tools that need review before being connected.
 
 This proposal would not work over a federated context, as federated homeservers are not aware of foregin appservices.
-That being said, the events suggested in this proposal are sensitive and are expected to only be shared with immediate
+That being said the events suggested in this proposal are sensitive and are expected to only be shared with immediate
 appservices connected to the homeserver. It would be possible for an appservice to "proxy" these events to a seperate room
 if federation of the information is desired, though.
 
-
 ## Alternatives
 
 One alternative would be to have homeserver implementations make an "events" room, which sends these events
@@ -150,4 +144,4 @@ is not impacted.
 
 ## Unstable prefix
 
-All keys mentioned in this document beginning with `m.` will use `uk.half-shot.mscXXXX.` as the prefix.
+All keys mentioned in this document beginning with `m.` will use `uk.half-shot.mscXXXX.` as the prefix.