Formatting, added semantic breaks for better readability

standards/core/lightpush.md

@@ -15,7 +15,7 @@ previous version: `/vac/waku/lightpush/2.0.0-beta1` [19/WAKU2-LIGHTPUSH](https:/
 
 ## Motivation and Goals
 
-Light nodes with short connection windows and limited bandwidth wish to push messages to other nodes in the Waku network to request message services.
+Light nodes with short connection windows and limited bandwidth wish to push messages to other nodes in the Waku network to request message services.<br>
 A common use case is to request that the service node publish the message to an `11/WAKU2-RELAY` pubsub-topic.
 Additionally, there is sometimes a need for confirmation that a message has been received "by the network"
 (here, at least one node).
@@ -44,13 +44,17 @@ message LightPushResponse {
 
 ### Message Relaying
 
-Nodes that respond to `LightPushRequest` SHOULD either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic`
-or perform another requested service.
-Services beyond [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) are as yet underdefined.
-Depending on the network configuration, the lightpush client may not need to provide `pubsub_topic` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)).
-If the node is unable to do so for some reason, they SHOULD return an error code in `LightPushResponse`.
-Once the relay is successful, the `relay_peer_count` will indicate the number of peers that the node has managed to relay the message to. It's important to note that this number may vary depending on the node subscriptions and support for the requested pubsub_topic. The client can use this information to either consider the relay as successful or take further action, such as switching to a lightpush service peer with better connectivity.
-The field `relay_peer_count` may not be present or has the value zero in case of error or in other future use cases, where no relay is involved.
+Nodes that respond to `LightPushRequest` SHOULD
+- either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic`<br>
+- or perform another requested service.
+  `Services beyond [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) are as yet underdefined.`
+
+Depending on the network configuration, the lightpush client may not need to provide `pubsub_topic` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)).<br>
+
+If the node is unable to perform the request for some reason, it SHOULD return an error code in `LightPushResponse`.<br>
+
+Once the relay is successful, the `relay_peer_count` will indicate the number of peers that the node has managed to relay the message to. It's important to note that this number may vary depending on the node subscriptions and support for the requested pubsub_topic. The client can use this information to either consider the relay as successful or take further action, such as switching to a lightpush service peer with better connectivity.<br>
+>The field `relay_peer_count` may not be present or has the value zero in case of error or in other future use cases, where no relay is involved.
 
 ### Examples of possible error codes