Design requirements of store and filter protocols (#285)

* adds design requirements of store and filter protocols

* Update waku-store.md

* Update waku-filter.md

* minor edit

specs/waku/v2/waku-filter.md

@@ -10,6 +10,7 @@ authors: Oskar Thorén <oskar@status.im>, Dean Eigenmann <dean@status.im>, Hanno
 - [Abstract](#abstract)
 - [Content filtering](#content-filtering)
   - [Rationale](#rationale)
+- [Design Requirements](#design-requirements)
 - [Security Consideration](#security-consideration)
   - [Terminology](#terminology)
 - [Adversarial Model](#adversarial-model)
@@ -54,6 +55,11 @@ It is worth noting that a light node could get by with only using the `store`
 protocol to query for a recent time window, provided it is acceptable to do
 frequent polling.
 
+
+# Design Requirements
+
+The effectiveness and reliability of the content filtering service enabled by  `WakuFilter` protocol rely on the *high availability* of the full nodes as the service providers. To this end, full nodes must feature *high uptime* (to persistently listen and capture the network messages) as well as *high Bandwidth* (to provide timely message delivery to the light nodes). 
+
 # Security Consideration
 
 Note that while using `WakuFilter` allows light nodes to save bandwidth, it comes with a privacy cost in the sense that they need to disclose their liking topics to the full nodes to retrieve the relevant messages. Currently, anonymous subscription is not supported by the `WakuFilter`, however, potential solutions in this regard are sketched below in [Future Work](#future-work) section. 

specs/waku/v2/waku-store.md

@@ -9,6 +9,7 @@ authors: Oskar Thorén <oskar@status.im>, Dean Eigenmann <dean@status.im>, Sanaz
 
 - [Table of Contents](#table-of-contents)
 - [Abstract](#abstract)
+- [Design Requirements](#design-requirements)
 - [Security Consideration](#security-consideration)
   - [Terminology](#terminology)
 - [Adversarial Model](#adversarial-model)
@@ -31,8 +32,11 @@ This specification explains the Waku `WakuStore` protocol which enables querying
 
 **Protocol identifier***: `/vac/waku/store/2.0.0-beta2`
 
-# Security Consideration
 
+# Design Requirements
+Nodes willing to provide storage service in `WakuStore` protocol are required to be *highly available* and in specific have a *high uptime* to consistently receive and store network messages. The high uptime requirement makes sure that no message is missed out hence a complete and intact view of the message history is delivered to the querying nodes. Nevertheless, in case that storage provider nodes cannot afford high availability, the querying nodes may retrieve the historical messages from multiple sources to achieve a full and intact view of the past.
+
+# Security Consideration
 The main security consideration to be taken into account while using `WakuStore` is to notice that the querying nodes have to reveal their topics of interest to the queried nodes hence compromising their privacy. 
 
 ## Terminology