change ports (#98)

ethersphere · Nov 18, 2020 · e4720e2 · e4720e2
1 parent 2e05430
commit e4720e2
Show file tree

Hide file tree

Showing 17 changed files with 163 additions and 163 deletions.
diff --git a/docs/advanced/persistence.md b/docs/advanced/persistence.md
@@ -17,7 +17,7 @@ It is possible to instruct your node never to delete certain chunks, by locally
 Locally pinning a chunk is best done upon upload by passing the `swarm-pin` header to the upload you are doing. As an example, you can upload a file and pin it at the same time by using
 
 ```sh
-curl -H "Content-Type: image/x-jpeg" -H "swarm-pin: true" --data-binary @kitten.jpg localhost:8080/files?name=cat.jpg
+curl -H "Content-Type: image/x-jpeg" -H "swarm-pin: true" --data-binary @kitten.jpg localhost:1633/files?name=cat.jpg
 ```
 
 ## Persistence in the network by global pinning
@@ -57,7 +57,7 @@ To make use of the global pinning feature (and request a repair if a chunk not f
 An example of a request to download a file with the targets query parameter passed in:
 
 ```sh
-curl http://localhost:8080/files/3b2791985f102fe645d1ebd7f51e522d277098fcd86526674755f762084b94ee?targets=<target comes here>
+curl http://localhost:1633/files/3b2791985f102fe645d1ebd7f51e522d277098fcd86526674755f762084b94ee?targets=<target comes here>
 ```
 
 If your chunk is not found in the network, but you sent a request to the passed-in target for repair then you get a `202` response back, indicating that the request has been accepted for processing.

diff --git a/docs/advanced/pss.md b/docs/advanced/pss.md
@@ -14,7 +14,7 @@ Once your Bee node is up and running, you will be able to subscribe to feeds usi
 Here we subscribe to the topic `test-topic`
 
 ```sh
-websocat ws://localhost:8080/pss/subscribe/test-topic
+websocat ws://localhost:1633/pss/subscribe/test-topic
 ```
 
 Our node is now watching for new messages received in it's nearest neighbourhood.
@@ -37,7 +37,7 @@ For example, if we want to send a PSS message with **topic** `test-topic` to a n
 
 ```sh
 curl -XPOST \
-localhost:8082/pss/send/test/7bc5?recipient=0349f7b9a6fa41b3a123c64706a072014d27f56accd9a0e92b06fe8516e470d8dd \
+localhost:1833/pss/send/test/7bc5?recipient=0349f7b9a6fa41b3a123c64706a072014d27f56accd9a0e92b06fe8516e470d8dd \
 --data "Hello Swarm"
 ```
 
@@ -51,28 +51,28 @@ Run the following command to start the first node. Note that we are passing `""`
 
 ```sh
 bee start \
-    --api-addr=:8082 \
+    --api-addr=:1833 \
     --debug-api-enable \
-    --debug-api-addr=:6062 \
+    --debug-api-addr=:1835 \
     --data-dir=/tmp/bee2 \
     --bootnode="" \
-    --p2p-addr=:7072 \
+    --p2p-addr=:1834 \
     --swap-enable=false
 ```
 
 We must make a note of the Swarm overlay address, underlay address and public key which are created once each node has started. We find this information from the addresses endpoint of the Debug API.
 
 ```sh
-curl -s localhost:6062/addresses | jq
+curl -s localhost:1835/addresses | jq
 ```
 
 ```json
 {
   "overlay": "7bc50a5d79cb69fa5a0df519c6cc7b420034faaa61c175b88fc4c683f7c79d96",
   "underlay": [
-    "/ip4/127.0.0.1/tcp/7072/p2p/16Uiu2HAmP9i7VoEcaGtHiyB6v7HieoiB9v7GFVZcL2VkSRnFwCHr",
-    "/ip4/192.168.0.10/tcp/7072/p2p/16Uiu2HAmP9i7VoEcaGtHiyB6v7HieoiB9v7GFVZcL2VkSRnFwCHr",
-    "/ip6/::1/tcp/7072/p2p/16Uiu2HAmP9i7VoEcaGtHiyB6v7HieoiB9v7GFVZcL2VkSRnFwCHr"
+    "/ip4/127.0.0.1/tcp/1834/p2p/16Uiu2HAmP9i7VoEcaGtHiyB6v7HieoiB9v7GFVZcL2VkSRnFwCHr",
+    "/ip4/192.168.0.10/tcp/1834/p2p/16Uiu2HAmP9i7VoEcaGtHiyB6v7HieoiB9v7GFVZcL2VkSRnFwCHr",
+    "/ip6/::1/tcp/1834/p2p/16Uiu2HAmP9i7VoEcaGtHiyB6v7HieoiB9v7GFVZcL2VkSRnFwCHr"
   ],
   "ethereum": "0x0000000000000000000000000000000000000000",
   "public_key": "0349f7b9a6fa41b3a123c64706a072014d27f56accd9a0e92b06fe8516e470d8dd"
@@ -83,26 +83,26 @@ Now the same for the second node.
 
 ```sh
 bee start \
-    --api-addr=:8083 \
+    --api-addr=:1933 \
     --debug-api-enable \
-    --debug-api-addr=:6063 \
+    --debug-api-addr=:1935 \
     --data-dir=/tmp/bee3 \
     --bootnode="" \
-    --p2p-addr=:7073 \
+    --p2p-addr=:1934 \
     --swap-enable=false
 ```
 
 ```sh
-curl -s localhost:6063/addresses | jq
+curl -s localhost:1935/addresses | jq
 ```
 
 ```json
 {
   "overlay": "a231764383d7c46c60a6571905e72021a90d506ef8db06750f8a708d93fe706e",
   "underlay": [
-    "/ip4/127.0.0.1/tcp/7073/p2p/16Uiu2HAmAqJkKJqZjNhuDtepc8eBANM9TvagaWUThfTN5NkfmKTq",
-    "/ip4/192.168.0.10/tcp/7073/p2p/16Uiu2HAmAqJkKJqZjNhuDtepc8eBANM9TvagaWUThfTN5NkfmKTq",
-    "/ip6/::1/tcp/7073/p2p/16Uiu2HAmAqJkKJqZjNhuDtepc8eBANM9TvagaWUThfTN5NkfmKTq",
+    "/ip4/127.0.0.1/tcp/1934/p2p/16Uiu2HAmAqJkKJqZjNhuDtepc8eBANM9TvagaWUThfTN5NkfmKTq",
+    "/ip4/192.168.0.10/tcp/1934/p2p/16Uiu2HAmAqJkKJqZjNhuDtepc8eBANM9TvagaWUThfTN5NkfmKTq",
+    "/ip6/::1/tcp/1934/p2p/16Uiu2HAmAqJkKJqZjNhuDtepc8eBANM9TvagaWUThfTN5NkfmKTq",
     "/ip4/81.98.94.4/tcp/25178/p2p/16Uiu2HAmAqJkKJqZjNhuDtepc8eBANM9TvagaWUThfTN5NkfmKTq"
   ],
   "ethereum": "0x0000000000000000000000000000000000000000",
@@ -113,11 +113,11 @@ curl -s localhost:6063/addresses | jq
 Because we configured the nodes to start with no bootnodes, neither node should have peers yet.
 
 ```sh
-curl -s localhost:6062/peers | jq
+curl -s localhost:1835/peers | jq
 ```
 
 ```sh
-curl -s localhost:6063/peers | jq
+curl -s localhost:1935/peers | jq
 ```
 
 ```json
@@ -130,13 +130,13 @@ Let's connect node 2 to node 1 using the localhost (127.0.0.1) underlay address
 
 ```sh
 curl -XPOST \
-  localhost:6063/connect/ip4/127.0.0.1/tcp/7072/p2p/16Uiu2HAmP9i7VoEcaGtHiyB6v7HieoiB9v7GFVZcL2VkSRnFwCHr
+  localhost:1935/connect/ip4/127.0.0.1/tcp/1834/p2p/16Uiu2HAmP9i7VoEcaGtHiyB6v7HieoiB9v7GFVZcL2VkSRnFwCHr
 ```
 
 Now, if we check our peers endpoint for node 1, we can see our nodes are now peered together.
 
 ```sh
-curl -s localhost:6062/peers | jq
+curl -s localhost:1835/peers | jq
 ```
 
 ```json
@@ -152,7 +152,7 @@ curl -s localhost:6062/peers | jq
 Of course, since we are p2p, node 2 will show node 1 as a peer too.
 
 ```sh
-curl -s localhost:6063/peers | jq
+curl -s localhost:1935/peers | jq
 ```
 
 ```json
@@ -168,7 +168,7 @@ curl -s localhost:6063/peers | jq
 We will use `websocat` to listen for PSS messages topic ID `test-topic` on our first node.
 
 ```sh
-websocat ws://localhost:8082/pss/subscribe/test-topic
+websocat ws://localhost:1833/pss/subscribe/test-topic
 ```
 
 Now we can use PSS to send a message from our second node to our first node. 
@@ -177,14 +177,14 @@ Since our first node has a 2 byte address prefix of `a231`, we will specify this
 
 ```sh
 curl \
-  -XPOST "localhost:8083/pss/send/test-topic/7bc5?recipient=0349f7b9a6fa41b3a123c64706a072014d27f56accd9a0e92b06fe8516e470d8dd"\
+  -XPOST "localhost:1933/pss/send/test-topic/7bc5?recipient=0349f7b9a6fa41b3a123c64706a072014d27f56accd9a0e92b06fe8516e470d8dd"\
   --data "Hello Swarm"
 ```
 
 The PSS API endpoint will now create a PSS message for it's recipient in the form of a 'Trojan Chunk' and send this into the network so that it may be pushed to the correct neighbourhood. Once it is received by it's destination target it will be decrypted and determined to be a message with the topic we are listening for. Our second node will decrypt the data and we'll see a message pop up in our `websocat` console!
 
 ```sh
-sig :: ~ » websocat ws://localhost:8082/pss/subscribe/test-topic
+sig :: ~ » websocat ws://localhost:1833/pss/subscribe/test-topic
 Hello Swarm
 ```
 

diff --git a/docs/advanced/starting-a-test-network.md b/docs/advanced/starting-a-test-network.md
@@ -12,9 +12,9 @@ Starting a network is easiest achieved by making use of configuration files. We
 **config_1.yaml**
 ```yaml
 network-id: 7357
-api-addr: :8080
-p2p-addr: :7070
-debug-api-addr: 127.0.0.1:6060
+api-addr: :1633
+p2p-addr: :1634
+debug-api-addr: 127.0.0.1:1635
 debug-api-enable: true
 bootnode: ""
 data-dir: /tmp/bee/node1
@@ -25,9 +25,9 @@ swap-enable: false
 **config_2.yaml**
 ```yaml
 network-id: 7357
-api-addr: :8081
-p2p-addr: :7071
-debug-api-addr: 127.0.0.1:6061
+api-addr: :1733
+p2p-addr: :1734
+debug-api-addr: 127.0.0.1:1735
 debug-api-enable: true
 data-dir: /tmp/bee/node2
 bootnode: ""
@@ -49,12 +49,12 @@ We can now inspect the state of our network by sending HTTP requests to the [Deb
 
 
 ```sh
-curl -s http://localhost:6060/topology | jq .connected
+curl -s http://localhost:1635/topology | jq .connected
 > 0
 ```
 
 ```sh
-curl -s http://localhost:6061/topology | jq .connected
+curl -s http://localhost:1735/topology | jq .connected
 > 0
 ```
 
@@ -70,16 +70,16 @@ In order to create a network from our two isolated nodes, we must first instruct
 First, we will need to find out the network address of the first node. To do this, we send a HTTP request to the `addresses` endpoint of the Debug API. 
 
 ```sh
-curl localhost:6060/addresses | jq
+curl localhost:1635/addresses | jq
 ```
 
 ```json
 {
   "overlay": "f57a65207f5766084d3ebb6bea5e2e4a712504e54d86a00961136b514f07cdac",
   "underlay": [
-    "/ip4/127.0.0.1/tcp/7070/p2p/16Uiu2HAmUdCRWmyQCEahHthy7G4VsbBQ6dY9Hnk79337NfadKJEs",
-    "/ip4/192.168.0.10/tcp/7070/p2p/16Uiu2HAmUdCRWmyQCEahHthy7G4VsbBQ6dY9Hnk79337NfadKJEs",
-    "/ip6/::1/tcp/7070/p2p/16Uiu2HAmUdCRWmyQCEahHthy7G4VsbBQ6dY9Hnk79337NfadKJEs",
+    "/ip4/127.0.0.1/tcp/1634/p2p/16Uiu2HAmUdCRWmyQCEahHthy7G4VsbBQ6dY9Hnk79337NfadKJEs",
+    "/ip4/192.168.0.10/tcp/1634/p2p/16Uiu2HAmUdCRWmyQCEahHthy7G4VsbBQ6dY9Hnk79337NfadKJEs",
+    "/ip6/::1/tcp/1634/p2p/16Uiu2HAmUdCRWmyQCEahHthy7G4VsbBQ6dY9Hnk79337NfadKJEs",
     "/ip4/xx.xx.xx.xx/tcp/40317/p2p/16Uiu2HAmUdCRWmyQCEahHthy7G4VsbBQ6dY9Hnk79337NfadKJEs"
   ]
 }
@@ -92,12 +92,12 @@ Note the addresses starting with an `/ip4`, followed by `127.0.0.1`, which is th
 **config_2.yaml**
 ```yaml
 network-id: 7357
-api-addr: :8081
-p2p-addr: :7071
-debug-api-addr: 127.0.0.1:6061
+api-addr: :1733
+p2p-addr: :1734
+debug-api-addr: 127.0.0.1:1735
 debug-api-enable: true
 data-dir: /tmp/bee/node2
-bootnode: "/ip4/127.0.0.1/tcp/7070/p2p/16Uiu2HAmUdCRWmyQCEahHthy7G4VsbBQ6dY9Hnk79337NfadKJEs"
+bootnode: "/ip4/127.0.0.1/tcp/1634/p2p/16Uiu2HAmUdCRWmyQCEahHthy7G4VsbBQ6dY9Hnk79337NfadKJEs"
 password: some pass phze
 welcome-message: "Bzz Bzz Bzz"
 swap-enable: false
@@ -110,11 +110,11 @@ Look at the the output for your first node, you should see our connection messag
 Let's also verify that we can see both nodes in using each other's Debug API's.
 
 ```sh
-curl -s http://localhost:6060/peers | jq
+curl -s http://localhost:1635/peers | jq
 ```
 
 ```sh
-curl -s http://localhost:6060/peers | jq
+curl -s http://localhost:1635/peers | jq
 ```
 
 Congratulations! You have made your own tiny two bee Swarm! 🐝 🐝
diff --git a/docs/advanced/swap.md b/docs/advanced/swap.md
@@ -24,7 +24,7 @@ bee start \
 
 ```sh
 dd if=/dev/urandom of=/tmp/test.txt bs=1m count=20
-curl -F file=@/tmp/test.txt http://localhost:8080/files
+curl -F file=@/tmp/test.txt http://localhost:1633/files
 ```
 
 If we set `--verbosity 5` in our Bee configuration, we will be able to see these individual transactions being recorded on our node's internal per peer ledgers.
@@ -47,7 +47,7 @@ TRAC[2020-09-28T15:18:08+01:00] crediting peer f1e2872581de18bdc68060dc8edd3aa96
 We also have a rich set of features to be able to query the current accounting state of your node. For example, you may query your node's current balance by send a POST request to the balances endpoint.
 
 ```sh
-curl localhost:6060/chequebook/balance | jq
+curl localhost:1635/chequebook/balance | jq
 ```
 
 ```json
@@ -60,7 +60,7 @@ curl localhost:6060/chequebook/balance | jq
 It is also possible to examine per-peer balances.
 
 ```sh
-curl localhost:6060/balances | jq
+curl localhost:1635/balances | jq
 ```
 
 ```json
@@ -83,7 +83,7 @@ curl localhost:6060/balances | jq
 In Swarm, these per-peer balances simply represent trustful agreements between nodes. Tokens only actually change hands when a node settles a cheque. This can either be triggered manually or when a certain threshold is reached with a peer. In this case, a settlement takes place. You may view these using the settlements endpoint.
 
 ```sh
-curl localhost:6060/settlements | jq
+curl localhost:1635/settlements | jq
 ```
 
 ```json
@@ -110,7 +110,7 @@ curl localhost:6060/settlements | jq
 More info can be found by using the chequebook api.
 
 ```sh
-curl localhost:6060/chequebook/cheque | jq
+curl localhost:1635/chequebook/cheque | jq
 ```
 
 ```json
@@ -134,7 +134,7 @@ As our node's participation in the network increases, we will begin to see more
 To do this, we simply POST the relevant peer's address to the `cashout` endpoint.
 
 ```sh
-curl -XPOST http://localhost:6060/chequebook/cashout/d7881307e793e389642ea733451db368c4c9b9e23f188cca659c8674d183a56b
+curl -XPOST http://localhost:1635/chequebook/cashout/d7881307e793e389642ea733451db368c4c9b9e23f188cca659c8674d183a56b
 ```
 
 ```json
@@ -146,7 +146,7 @@ You may check the status of your transaction using [Goerli Etherscan](https://go
 Finally, we can now see the status of the cashout transaction by sending a GET request to the same URL.
 
 ```sh
-curl http://localhost:6060/chequebook/cashout/d7881307e793e389642ea733451db368c4c9b9e23f188cca659c8674d183a56b | jq
+curl http://localhost:1635/chequebook/cashout/d7881307e793e389642ea733451db368c4c9b9e23f188cca659c8674d183a56b | jq
 ```
 
 ```json

diff --git a/docs/advanced/tags.md b/docs/advanced/tags.md
@@ -32,14 +32,14 @@ To follow the status of your upload while it is splitting you must generate the
 Create a tag by sending a POST request to the `tag` API endpoint:
 
 ```console
-curl -s -XPOST http://localhost:8080/tags | jq .uid
+curl -s -XPOST http://localhost:1633/tags | jq .uid
 > 4074122506
 ```
 
 Use the returned UID to instruct your POST upload request to track this upload using the `Swarm-Tag-UID` header:
 
 ```console
-curl -F [email protected] -H "Swarm-Tag-UID: 4074122506" http://localhost:8080/files
+curl -F [email protected] -H "Swarm-Tag-UID: 4074122506" http://localhost:1633/files
 ```
 
 :::info
@@ -53,7 +53,7 @@ You can use `curl --verbose` to view the HTTP response headers such as the `Swar
 To get the current status of an upload, send a GET request to the `tag/<Swarm-Tag-UID>` API endpoint.
 
 ```console
-curl http://localhost:8080/tags/4074122506 | jq
+curl http://localhost:1633/tags/4074122506 | jq
 ```
 
 The response contains all the information that you need to follow the status of your file as it is synced with the network.

diff --git a/docs/api-reference/api-reference.md b/docs/api-reference/api-reference.md
@@ -6,18 +6,18 @@ id: api-reference
 The Bee node exposes two HTTP API endpoints, the `API` and the `DebugAPI`. These endpoints are the your primary interfaces to a *running* Bee node. API-endpoints can be queried using familiar HTTP requests, and will respond with a semantically accurate [HTTP status and error codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status) as well as data payloads in [JSON](https://www.json.org/json-en.html) format where appropriate.
 
 ## API
-The API-endpoint exposes all functionality to upload and download content to and from the Swarm network. By default, it runs on port `:8080`.
+The API-endpoint exposes all functionality to upload and download content to and from the Swarm network. By default, it runs on port `:1633`.
 
 Detailed information about Bee API endpoint can be found here:
 
 - <a href="../../api" target="_blank" rel="noopener noreferrer">Bee API reference.</a>
 
 
 ## Debug API
-The debug-API is disabled by default but be enabled by setting the `enable-debug-api` configuration option to `true`. The debug-API exposes functionality to inspect the state of your Bee node while it is running, as well as some other features that should not be exposed to the public internet. The Debug API runs on port `:6060` by default.
+The debug-API is disabled by default but be enabled by setting the `enable-debug-api` configuration option to `true`. The debug-API exposes functionality to inspect the state of your Bee node while it is running, as well as some other features that should not be exposed to the public internet. The Debug API runs on port `:1635` by default.
 
 - <a href="../../debug-api" target="_blank" rel="noopener noreferrer">Debug API reference.</a>,
 
 :::danger 
-Your Debug API should not be exposed to the public internet, make sure that your network has a firewall which blocks port `6060`, or bind the Debug API to `localhost`
+Your Debug API should not be exposed to the public internet, make sure that your network has a firewall which blocks port `1635`, or bind the Debug API to `localhost`
 :::