Add line numbers

content/enter-the-matrix.md

@@ -53,7 +53,7 @@ As I quickly hinted at, a room can be either public or private. Public rooms can
 
 Now that we know what a room is, let's talk about what's passing inside of one. Earlier, I've been talking about messages, which are actually called "events". Technically speaking, a Matrix event is a JSON object that's sent in a room and dispatched to all other members of the room. It, of course, has an ID that's generated by the homeserver hosting the user who sent the message, taking the general form we saw earlier and the `$` sigil character. This JSON has metadata, such as a class name to identify different event types, an author, a creation timestamp, etc. It basically looks like this:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
   "origin_server_ts": 1526072700313,
   "sender": "@Alice:matrix.alice.tld",
@@ -107,7 +107,7 @@ Note that every endpoint in the Matrix spec always starts with `/_matrix/`.
 
 The request body is a JSON which takes the following form:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
   "username": "Alice",
   "password": "1L0v3M4tr!x",
@@ -118,7 +118,7 @@ Here, the `username` and `password` properties are exactly what you think it is.
 
 Fire this request. You'll now get a `401` status code along with some JSON, which looks like this:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
     "flows": [
         {
@@ -139,7 +139,7 @@ Fire this request. You'll now get a `401` status code along with some JSON, whic
 
 Now, this enpoint uses a part of the spec called the [User-Interactive Authentication API](https://matrix.org/docs/spec/client_server/r0.3.0.html#user-interactive-authentication-api). This means that authentication can be seen as flows of consecutive stages. That's exactly what we have here: two flows, each containing one stage. This example is a very simple one, but it can get quite more complex, such as:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
     "flows": [
         {
@@ -169,7 +169,7 @@ Because I want to keep it as simple as possible here, let's get back at our init
 
 To register against this stage, we'll only add a few lines to our initial request's JSON:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
   "auth": {
     "type": "m.login.dummy",
@@ -182,7 +182,7 @@ To register against this stage, we'll only add a few lines to our initial reques
 
 Note that the value to the `session` property in the newly added `auth` object is the value from `sessions` taken from the homeserver's response to our intial request. This `auth` object will tell the homeserver that this request is a follow-up to the initial request, using the stage `m.login.dummy`. The homeserver will automatically recognise the flow we're using, and will succeed (because we use `m.login.dummy`), returning this JSON along with a `200` status code:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
   "access_token": "olic0yeVa1pore2Kie4Wohsh",
   "device_id": "FOZLAWNKLD",
@@ -208,7 +208,7 @@ There are a few JSON parameters available which I won't cover here because none
 
 Before responding, the homeserver will create the room, fire a few state events in it (such as the initial `m.room.create` state event or a join event for your user). It should then respond with a `200` status code and a JSON body looking like this:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
     "room_id": "!RtZiWTovChPysCUIgn:matrix.project.tld"
 }
@@ -222,7 +222,7 @@ Browsing the room's state is completely useless at this stage, but let's do it a
 
 The request should return a JSON array containing state events such as:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
   "age": 654742,
   "content": {
@@ -246,7 +246,7 @@ The body for our request is the event's content object.
 
 Let's create a `tld.project.foo` event with `bar` as its state key, and `{"baz": "qux"}` as its content. To achieve that, let's send a `PUT` request to `/_matrix/client/r0/rooms/!RtZiWTovChPysCUIgn:matrix.project.tld/state/tld.project.foo/bar?access_token=olic0yeVa1pore2Kie4Wohsh` (from which I've stripped the protocol scheme and FQDN so it doesn't appear too in the post) with the fillowing content:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
   "baz": "qux"
 }
@@ -256,7 +256,7 @@ The homeserver then responds with an object only containing an `event_id` proper
 
 If we retry the request we previously made to retrieve the whole room state, we can now see our event:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
     "age": 58357,
     "content": {
@@ -292,7 +292,7 @@ So far, Alice has registered on the homeserver and created her room, but she fee
 
 Inviting someone into a room is also quite simple, and only requires a `POST` request on the [`/_matrix/client/r0/rooms/{roomId}/invite`](https://matrix.org/docs/spec/client_server/r0.3.0.html#post-matrix-client-r0-rooms-roomid-invite) endpoint. The request's body must contain the invited Matrix ID as such:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
   "user_id": "@Bob:matrix.bob.tld"
 }
@@ -304,7 +304,7 @@ If all went well, the homeserver should respond with a `200` status code and an
 
 In the next request on the [`/_matrix/client/r0/sync`](https://matrix.org/docs/spec/client_server/r0.3.0.html#get-matrix-client-r0-sync) he'll made, Bob will now see an `invite` object inside the `rooms` one contaning the invite Alice sent him, containing a few events including the invite event:
 
-{{< highlight json >}}
+{{< highlight json "lineos=table" >}}
 {
   "invite": {
     "!RtZiWTovChPysCUIgn:matrix.project.tld": {