Add requirements

Author: NoahMaizels

docs/documentation/act.md

@@ -19,11 +19,19 @@ Updating the grantees list to remove a public key ***will not revoke access*** t
 Likewise, re-uploading the content using the new grantees list will also ***not retroactively revoke access*** to the content.
 :::
 
+## Requirements
+The use of ACT requires the following:
+
+* A Bee light node running on with synced postage batch data. (Running at `http://localhost:1633` by default)
+* A valid postage batch ID. [Buy one](/docs/storage/#purchasing-storage) if needed.
+* Public keys of the nodes you want to grant access to.
+* The **public key of the publishing node**. This can be obtained using the [`bee.getNodeAddresses()` method](/docs/status/#3-get-node-addresses).
+
 ## Create Grantees List
 
 First we create a grantees list with the public keys of anyone we want to grant access to.
 
-### Example Script
+#### Example Script:
 
 The example script below performs the following key operations:
 
@@ -98,7 +106,7 @@ bee.patchGrantees(postageBatchId, ref, historyref, {
 
 Calling this method returns the new list’s updated `ref` and `historyref`, which you should use for future updates or access. 
 
-### Example Script
+#### Example Script:
 
 The example script below performs the following key steps:
 
@@ -167,7 +175,7 @@ In order to view the members of our grantees list we need to use the 64 byte `re
 The grantee list is encrypted, and only the owner can view the grantee list, make sure to use the owner node when using the `bee.getGrantees()` method.
 :::
 
-### Example Script
+#### Example Script:
 
 The example script below performs the following operations:
 
@@ -236,7 +244,7 @@ The first list of grantees contains the first public key we gave access to when
 
 We can upload our content with either of the two lists we created depending on which set of users we wish to give access too. In the example below, we use both lists.
 
-### Example Script
+#### Example Script:
 
 The example script below performs the following operations:
 
@@ -307,7 +315,7 @@ You can choose which `historyref` to share depending on which set of public keys
 
 In order to download using ACT, we must pass in the public key from the grantee list creator along with the file reference and history reference returned from the file upload operation:
 
-### Example Script
+#### Example Script:
 
 The example script below performs the following operations:
 

docs/documentation/gsoc.md

@@ -6,7 +6,7 @@ sidebar_label: GSOC
 ---
 
 
-The GSOC (Graffiti Several Owner Chunk) feature allows a **full node** to receive messages from many other nodes using a shared Single Owner Chunk (SOC). This enables real-time communication and notification over Swarm.
+The GSOC (Graffiti Several Owner Chunk) feature allows a **full node** to receive messages from many other nodes using a shared Single Owner Chunk (SOC). This enables real-time messaging over Swarm.
 
 ## Overview
 

docs/documentation/soc-and-feeds.md

@@ -13,6 +13,15 @@ Swarm provides the ability to store content in content-addressed [chunks](https:
 
 Feeds are a unique feature of Swarm which simulate the publishing of mutable content on Swarm's immutable storage. ***Feeds constitute the primary use case for SOCs.*** Developers can use Feeds to version revisions of a mutable resource by indexing sequential updates to a topic at predictably calculated addresses. Because Feeds are built on top of SOCs, their interfaces are somewhat similar and use common concepts.
 
+
+## Requirements
+
+Interactions with SOC and feeds requires the following:
+
+* A fully initialized Bee light node running with fully synced postage batch data. (Running at `http://localhost:1633` by default)
+* A valid postage batch ID.
+* An Ethereum-compatible private key to sign updates. Using your node or blockchain account wallet's private key is strongly discouraged. Using a dedicated key for SOC / feeds is recommended. 
+
 ## Single Owner Chunks
 
 Bee-js calculates a SOC Swarm reference hash as the keccak256 hash of the concatenation of the  `identifier` and `owner` Ethereum address. The `identifier` is a 32 byte long arbitrary value (by default a hex string or a `Uint8Array`). The `owner` is an Ethereum address that consists of 20 bytes in a format of a hex string or `Uint8Array`.