Accounting for resources (experimental mode)

waku.md

@@ -23,6 +23,7 @@
     - [Mailserver and client](#mailserver-and-client)
         - [Requesting messages](#requesting-messages)
         - [Receiving historic messages](#receiving-historic-messages)
+    - [Accounting for resources](#accounting-for-resources)
 - [Backwards Compatibility](#backwards-compatibility)
     - [Waku-Whisper bridging](#waku-whisper-bridging)
 - [Forwards Compatibility](#forwards-compatibility)
@@ -370,6 +371,21 @@ In order to receive historic messages from a mailserver, a node MUST trust the s
 
 Received envelopes MUST be passed through the Waku envelopes pipelines so that they are picked up by registered filters and passed to subscribers.
 
+### Accounting for resources (experimental)
+
+Nodes MAY implement accounting, keeping track of resource usage. It is heavily inspired by Swarm's [SWAP protocol](https://www.bokconsulting.com.au/wp-content/uploads/2016/09/tron-fischer-sw3.pdf), and works by doing pairwise accounting for resources.
+
+Each node keeps track of resource usage with all other nodes. Whenever an envelope is received from a node that is expected (fits bloom filter or topic interest, is legal, etc) this is tracked.
+
+Every epoch (say, every minute or every time an event happens) statistics SHOULD be aggregated and saved by the client:
+
+| peer  | sent | received |
+|-------|------|----------|
+| peer1 | 0    | 123 |
+| peer2 | 10   | 40  |
+
+In later versions this will be amended by nodes communication threshholds, settlements and disconnect logic.
+
 ## Backwards Compatibility
 
 Waku is a different subprotocol from Whisper so it isn't directly compatible. However, the data format is the same, so compatibility can be achieved by the use of a bridging mode as described below. Any client which does not implement certain packet codes should gracefully ignore the packets with those codes. This will ensure the forward compatibility.