Waku v2: Shape up historical API

Addresses #164

specs/waku/waku-v2.md

@@ -116,6 +116,8 @@ message RPC {
 	repeated SubOpts subscriptions = 1;
 	repeated Message publish = 2;
     repeated ContentFilter contentFilter = 3;
+    repeated HistoryQuery historyQuery = 4;
+    repeated HistoryResponse historyResponse = 5;
 
 	message SubOpts {
 		optional bool subscribe = 1;
@@ -136,6 +138,16 @@ message Message {
 	optional bytes key = 6;
     optional string contentTopic = 7;
 }
+
+message HistoryQuery {
+    // TODO Include time range, topic/contentTopic, limit, cursor, (request-id), etc
+}
+
+
+message HistoryResponse {
+    // TODO Include Messages, cursor, etc
+}
+
 ```
 
 WakuSub does not currently use the `ControlMessage` defined in GossipSub.
@@ -148,6 +160,8 @@ However, later versions will add likely add this capability.
 These are messages sent to directly connected peers. These SHOULD NOT be
 gossiped. See section below on how the fields work.
 
+TODO Give brief summary of each type here
+
 ### Message
 
 The `from` field MAY indicate which peer is publishing the message.
@@ -191,11 +205,17 @@ Since such a node is doing extra work for a light node, it MAY also account for
 usage and be selective in how much service it provides. This mechanism is
 currently planned but underspecified.
 
-### Historical message support
+### HistoryQuery
+
+RPC call to query historical messages.
+
+TODO To be specified in more detail
+
+### HistoryResponse
 
-TODO(Dean): Fill out this section with historical message API.
+RPC call to respond to a HistoryQuery call.
 
-- Add issue for this in specs repository
+TODO To be specified in more detail
 
 ## Changelog