Syntax highlighting

content/enter-the-matrix.md

 
 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:
 
-```json
+{{< highlight json >}}
 {
   "origin_server_ts": 1526072700313,
   "sender": "@Alice:matrix.alice.tld",
   "type": "m.room.message",
   "room_id": "!TCnDZIwFBeQyBCciFD:matrix.alice.tld"
 }
-```
+{{< / highlight >}}
 
 The example above is an event sent from Alice to Bob and Charlie in the room they're all in. It's a message, as hinted at by the `m.room.message` class name in the `type` property. The `content` property, which must be an object, contains the event's actual content. In this case, we can see the message is text, and the text itself. This precision is needed because `m.room.message` can be a text, but also an image, a video, a notice, etc. as mentioned in [the spec](https://matrix.org/docs/spec/client_server/r0.3.0.html#m-room-message).
 
 
 The request body is a JSON which takes the following form:
 
-```json
+{{< highlight json >}}
 {
   "username": "Alice",
   "password": "1L0v3M4tr!x",
 }
-```
+{{< / highlight >}}
 
 Here, the `username` and `password` properties are exactly what you think it is. The Matrix ID generated for a new user contains what's provided in the `username` property as the `localpart`.
 
 Fire this request. You'll now get a `401` status code along with some JSON, which looks like this:
 
-```json
+{{< highlight json >}}
 {
     "flows": [
         {
     "params": {},
     "session": "HrvSksPaKpglatvIqJHVEfkd"
 }
-```
+{{< / highlight >}}
 
 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:
 
-```json
+{{< highlight json >}}
 {
     "flows": [
         {
     },
     "session": "qxATPqBPdTsaMBmOPkxZngXR"
 }
-```
+{{< / highlight >}}
 
 Here we can see two flows, one with a single stage, the other one with two stages. Note that there's also a parameter in the `params` object, to be used with the `m.login.recaptcha` flow.
 
 
 To register against this stage, we'll only add a few lines to our initial request's JSON:
 
-```json
+{{< highlight json >}}
 {
   "auth": {
     "type": "m.login.dummy",
   "username": "Alice",
   "password": "1L0v3M4tr!x",
 }
-```
+{{< / highlight >}}
 
 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:
 
-```json
+{{< highlight json >}}
 {
   "access_token": "olic0yeVa1pore2Kie4Wohsh",
   "device_id": "FOZLAWNKLD",
   "home_server": "matrix.project.tld",
   "user_id": "@Alice:matrix.project.tld"
 }
-```
+{{< / highlight >}}
 
 Let's see what we have here:
 
 
 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:
 
-```json
+{{< highlight json >}}
 {
     "room_id": "!RtZiWTovChPysCUIgn:matrix.project.tld"
 }
-```
+{{< / highlight >}}
 
 Here you are, you have created and joined your very first room! As you might have guessed, the value for the `room_id` property is the ID of the newly created room.
 
 
 The request should return a JSON array containing state events such as:
 
-```json
+{{< highlight json >}}
 {
   "age": 654742,
   "content": {
     "age": 654742
   }
 }
-```
+{{< / highlight >}}
 
 Now let's try to send our own state event in the room, shall we? I order to do that, you'll need to send a `PUT` request to the [`/_matrix/client/r0/rooms/{roomId}/state/{eventType}/{stateKey}`](https://matrix.org/docs/spec/client_server/r0.3.0.html#put-matrix-client-r0-rooms-roomid-state-eventtype) endpoint, repacing the room's ID, the event's type and its state key with the right values. Note that if your state key is an empty string, you can just omit it from the URL. Again, don't forget to append your access token!
 
 
 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:
 
-```json
+{{< highlight json >}}
 {
   "baz": "qux"
 }
-```
+{{< / highlight >}}
 
 The homeserver then responds with an object only containing an `event_id` property, which contains the ID of the newly created state event.
 
 If we retry the request we previously made to retrieve the whole room state, we can now see our event:
 
-```json
+{{< highlight json >}}
 {
     "age": 58357,
     "content": {
         "age": 58357
     }
 }
-```
+{{< / highlight >}}
 
 Note that sending an update of a state event is done the same way as sending a new state event with the same class name and the same state key.
 
 
 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:
 
-```json
+{{< highlight json >}}
 {
   "user_id": "@Bob:matrix.bob.tld"
 }
-```
+{{< / highlight >}}
 
 Note that the request is the same if Bob has registered on the same server as Alice.
 
 
 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:
 
-```json
+{{< highlight json >}}
 {
   "invite": {
     "!RtZiWTovChPysCUIgn:matrix.project.tld": {
     }
   }
 }
-```
+{{< / highlight >}}
 
 Now Bob will be able to join the room by sending a simple `POST` request to the [`/_matrix/client/r0/rooms/{roomId}/join`](https://matrix.org/docs/spec/client_server/r0.3.0.html#post-matrix-client-r0-rooms-roomid-join) endpoint.