diff --git a/specification/activitypub.md b/specification/activitypub.md
index c378a6f47..0b2c31d3b 100644
--- a/specification/activitypub.md
+++ b/specification/activitypub.md
@@ -538,7 +538,7 @@ Every object *MAY* have a `shares` collection. This is a list of all `Announce`
 
 Activities as defined by ActivityStreams are the core mechanism for creating, modifying and sharing content within the social graph.
 
-Client to server interaction takes place through clients posting Activities to an actor's outbox. To do this, clients *MUST* discover the URL of the actor's outbox from their profile and then *MUST* make an HTTP `POST` request to this URL with the Content-Type of `application/ld+json; profile="https://www.w3.org/ns/activitystreams"`. Servers *MAY* interpret a Content-Type or Accept header of `application/activity+json` as equivalent to `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` for client-to-server interactions. The request *MUST* be authenticated with the credentials of the user to whom the outbox belongs. The body of the `POST` request *MUST* contain a single Activity (which *MAY* contain embedded objects), or a single non-Activity object which will be wrapped in a Create activity by the server.
+Client to server interaction takes place through clients posting Activities to an actor's outbox. To do this, clients *MUST* discover the URL of the actor's outbox from their profile and then *MUST* make an HTTP POST request to this URL with the Content-Type of `application/ld+json; profile="https://www.w3.org/ns/activitystreams"`. Servers *MAY* interpret a Content-Type or Accept header of `application/activity+json` as equivalent to `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` for client-to-server interactions. The request *MUST* be authenticated with the credentials of the user to whom the outbox belongs. The body of the `POST` request *MUST* contain a single Activity (which *MAY* contain embedded objects), or a single non-Activity object which will be wrapped in a Create activity by the server.
 
 ### Example 11: Submitting an Activity to the Outbox
 ``` json
@@ -762,7 +762,7 @@ Servers *MAY* support uploading document types to be referenced in activites, su
 
 Servers communicate with other servers and propagate information across the social graph by posting activities to actors' inbox endpoints. An Activity sent over the network *SHOULD* have an `id`, unless it is intended to be transient (in which case it *MAY* omit the `id`).
 
-`POST` requests (eg. to the inbox) *MUST* be made with a Content-Type of `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` and `GET` requests (see also section 3.2 Retrieving objects) with an Accept header of `application/ld+json; profile="https://www.w3.org/ns/activitystreams"`. Servers *SHOULD* interpret a Content-Type or Accept header of `application/activity+json` as equivalent to `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` for server-to-server interactions.
+**POST** requests (eg. to the inbox) *MUST** be made with a Content-Type of `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` and `GET` requests (see also section 3.2 Retrieving objects) with an Accept header of `application/ld+json; profile="https://www.w3.org/ns/activitystreams"`. Servers *SHOULD* interpret a Content-Type or Accept header of `application/activity+json` as equivalent to `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` for server-to-server interactions.
 
 In order to propagate updates throughout the social graph, Activities are sent to the appropriate recipients. First, these recipients are determined through following the appropriate links between objects until you reach an actor, and then the Activity is inserted into the actor's *inbox* (delivery). This allows recipient servers to: