Re-wrap content after latest additions

1 files changed, 30 insertions, 25 deletions

diff --git a/docs/specification.rst b/docs/specification.rst
index 23b6bed764..07c57f9dda 100644
--- a/docs/specification.rst
+++ b/docs/specification.rst
@@ -78,9 +78,10 @@ The functionality that Matrix provides includes:
   + Mapping of 3PIDs to Matrix IDs
 
 The end goal of Matrix is to be a ubiquitous messaging layer for synchronising
-arbitrary data between sets of people, devices and services - be that for instant
-messages, VoIP call setups, or any other objects that need to be reliably and
-persistently pushed from A to B in an interoperable and federated manner.
+arbitrary data between sets of people, devices and services - be that for
+instant messages, VoIP call setups, or any other objects that need to be
+reliably and persistently pushed from A to B in an interoperable and federated
+manner.
 
 
 Architecture
@@ -1120,8 +1121,8 @@ There are several APIs provided to ``GET`` events for a room:
     
 |/rooms/<room_id>/initialSync|_
   Description:
-    Get all relevant events for a room. This includes state events, paginated non-state
-    events and presence events.
+    Get all relevant events for a room. This includes state events, paginated
+    non-state events and presence events.
   Response format:
     `` { TODO } ``
   Example:
@@ -1129,20 +1130,22 @@ There are several APIs provided to ``GET`` events for a room:
 
 Redactions
 ----------
-Since events are extensible it is possible for malicious users and/or servers to add
-keys that are, for example offensive or illegal. Since some events cannot be simply
-deleted, e.g. membership events, we instead 'redact' events. This involves removing
-all keys from an event that are not required by the protocol. This stripped down
-event is thereafter returned anytime a client or remote server requests it.
+Since events are extensible it is possible for malicious users and/or servers
+to add keys that are, for example offensive or illegal. Since some events
+cannot be simply deleted, e.g. membership events, we instead 'redact' events.
+This involves removing all keys from an event that are not required by the
+protocol. This stripped down event is thereafter returned anytime a client or
+remote server requests it.
 
-Events that have been redacted include a ``redacted_because`` key whose value is the
-event that caused it to be redacted, which may include a reason.
+Events that have been redacted include a ``redacted_because`` key whose value
+is the event that caused it to be redacted, which may include a reason.
 
-Redacting an event cannot be undone, allowing server owners to delete the offending
-content from the databases.
+Redacting an event cannot be undone, allowing server owners to delete the
+offending content from the databases.
 
-Currently, only room admins can redact events by sending a ``m.room.redacted`` event,
-but server admins also need to be able to redact events by a similar mechanism.
+Currently, only room admins can redact events by sending a ``m.room.redacted``
+event, but server admins also need to be able to redact events by a similar
+mechanism.
 
 
 Room Events
@@ -1346,13 +1349,15 @@ prefixed with ``m.``
   JSON format:
     ``{ "reason": "string" }``
   Description:
-    Events can be redacted by either room or server admins. Redacting an event means that
-    all keys not required by the protocol are stripped off, allowing admins to remove
-    offensive or illegal content that may have been attached to any event. This cannot be
-    undone, allowing server owners to physically delete the offending data.
-    There is also a concept of a moderator hiding a non-state event, which can be undone,
-    but cannot be applied to state events.
-    The event that has been redacted is specified in the ``redacts`` event level key.
+    Events can be redacted by either room or server admins. Redacting an event
+    means that all keys not required by the protocol are stripped off, allowing
+    admins to remove offensive or illegal content that may have been attached
+    to any event. This cannot be undone, allowing server owners to physically
+    delete the offending data.  There is also a concept of a moderator hiding a
+    non-state event, which can be undone, but cannot be applied to state
+    events.
+    The event that has been redacted is specified in the ``redacts`` event
+    level key.
 
 m.room.message msgtypes
 -----------------------
@@ -1731,8 +1736,8 @@ There are three main kinds of communication that occur between home servers:
    These are single request/response interactions between a given pair of
    servers, initiated by one side sending an HTTPS GET request to obtain some
    information, and responded by the other. They are not persisted and contain
-   no long-term significant history. They simply request a snapshot state at the
-   instant the query is made.
+   no long-term significant history. They simply request a snapshot state at
+   the instant the query is made.
 
 :Ephemeral Data Units (EDUs):
    These are notifications of events that are pushed from one home server to