diff --git a/content/client-server-api/modules/reference_relations.md b/content/client-server-api/modules/reference_relations.md
index c29f9a47..b88b56ae 100644
--- a/content/client-server-api/modules/reference_relations.md
+++ b/content/client-server-api/modules/reference_relations.md
@@ -8,20 +8,24 @@ type: module
 
 Generically referencing another event can be done with a `rel_type` of `m.reference`
 as a form of [relationship](#forming-relationships-between-events). There is no
-implied meaning behind the reference, and is usually context-dependent. Such an
+implied meaning behind the reference, and is usually context-dependent. One
 example is the [key verification framework](#key-verification-framework) which uses
 reference relations to associate distinct events with a specific verification attempt.
 
-The aggregation format of `m.reference` relations consists of a single `chunk` property to
-indicate all the events which `m.reference` the event (the parent). Currently,
-only a single `event_id` field is present on the events in the `chunk`.
-
 {{% boxes/note %}}
 Clients which wish to use threads or replies are expected to use other relationship
 types than references. References are typically used to associate data rather than
 messages.
 {{% /boxes/note %}}
 
+#### Server behaviour
+
+##### Server-side aggregation of `m.reference`
+
+The aggregation format of `m.reference` relations consists of a single `chunk` property,
+which lists all the events which `m.reference` the event (the parent). Currently,
+only a single `event_id` field is present on the events in the `chunk`.
+
 An example `m.reference` would be:
 
 ```json