feat(relay): rename server to relay everywhere that is relevant

Cargo.toml

@@ -1,6 +1,6 @@
 [workspace]
 members = [
-  "pkarr", "server",
+  "pkarr", "relay",
 ]
 
 # See: https://github.com/rust-lang/rust/issues/90148#issuecomment-949194352

Dockerfile

@@ -33,7 +33,7 @@ COPY . .
 RUN cargo build --release --target x86_64-unknown-linux-musl
 
 # Strip the binary to reduce size
-RUN strip target/x86_64-unknown-linux-musl/release/pkarr-server
+RUN strip target/x86_64-unknown-linux-musl/release/pkarr-relay
 
 # ========================
 # Runtime Stage
@@ -44,13 +44,13 @@ FROM alpine:3.20
 RUN apk add --no-cache ca-certificates
 
 # Copy the compiled binary from the builder stage
-COPY --from=builder /usr/src/app/target/x86_64-unknown-linux-musl/release/pkarr-server /usr/local/bin/pkarr-server
+COPY --from=builder /usr/src/app/target/x86_64-unknown-linux-musl/release/pkarr-relay /usr/local/bin/pkarr-relay
 
 # Set the working directory
 WORKDIR /usr/local/bin
 
-# Expose the port the pkarr server listens on (should match that of config.toml)
+# Expose the port the pkarr relay listens on (should match that of config.toml)
 EXPOSE 6881
 
-# Set the default command to run the homeserver binary
-CMD ["pkarr-server", "--config=./config.toml"]
+# Set the default command to run the relay binary
+CMD ["pkarr-relay", "--config=./config.toml"]

README.md

@@ -9,8 +9,8 @@ Where we are going, this [https://o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89u
 ## TLDR
 - To publish resource records for your key, sign a small encoded DNS packet (<= 1000 bytes) and publish it on the DHT (through a relay if necessary).
 - To resolve some key's resources, applications query the DHT directly, or through a [relay](./design/relays.md), and verify the signature themselves. 
-- Clients and Pkarr servers cache records extensively and minimize DHT traffic as much as possible for improved scalability. 
-- The DHT drops records after a few hours, so users, their friends, or service providers should periodically republish their records to the DHT. Also Pkarr servers could republish records recently requested, to keep popular records alive too.
+- Clients and Relays cache records extensively and minimize DHT traffic as much as possible for improved scalability. 
+- The DHT drops records after a few hours, so users, their friends, or service providers should periodically republish their records to the DHT. Also Pkarr relays could republish records recently requested, to keep popular records alive too.
 - Optional: Existing applications unaware of Pkarr can still function if the user added a Pkarr-aware DNS servers to their operating system DNS servers. 
 
 ## DEMO 
@@ -30,14 +30,14 @@ Or if you prefer Rust [Examples](./pkarr/examples/README.md)
 ```mermaid
 sequenceDiagram
     participant Client
-    participant Server
+    participant Relay
     participant DHT
     participant Republisher
 
-    Client->>Server: Publish
-    note over Server: Optional Pkarr Server
-    Server->>DHT: Put
-    Note over Server,DHT: Store signed DNS packet
+    Client->>Relay: Publish
+    note over Relay: Optional Pkarr Relay
+    Relay->>DHT: Put
+    Note over Relay,DHT: Store signed DNS packet
 
     Client->>Republisher: Republish request
     note over Client, Republisher: Notify Hosting provider mentioned in RRs
@@ -46,31 +46,31 @@ sequenceDiagram
         Republisher->>DHT: Republish
     end
 
-    Client->>Server: Resolve
-    Server->>DHT: Get
-    DHT->>Server: Response
-    Server->>Client: Response
+    Client->>Relay: Resolve
+    Relay->>DHT: Get
+    DHT->>Relay: Response
+    Relay->>Client: Response
 ```
 
 ### Clients
 #### Pkarr enabled applications.
 
-Native applications, can directly query and verify signed records from the DHT if they are not behind NAT. Otherwise, they will need to use a Pkarr server as a relay.
+Native applications, can directly query and verify signed records from the DHT if they are not behind NAT. Otherwise, they will need to use a Pkarr Relay.
 
-Browser web apps should try calling local Pkarr server at the default port `6881`, if not accessible, they have to query a remote server instead. Eitherway, these apps should allow users to configure servers of their choice.
+Browser web apps should try calling local Pkarr relay at the default port `6881`, if not accessible, they have to query a remote relay in parallel to fallback on. Eitherway, these apps should allow users to configure relays of their choice.
 
-Clients with private keys are also capable of submitting signed records either to the DHT directly, or through Pkarr relay server, to update user's records when needed.
+Clients with private keys are also capable of submitting signed records either to the DHT directly, or through Pkarr relay, to update user's records when needed.
 
 #### Existing applications
 To support existing applications totally oblivious of Pkarr, users will have to (manually or programatically) edit their OS DNS servers to add one or more DNS servers that recognize Pkarr and query the DHT to resolve packets from there. However, the best outcome would be adoption from existing widely used resolvers like `1.1.1.1` and `8.8.8.8`.
 
-### Servers
+### Relays
 
 Pkarr relays are optional but they:
 1. Act as [relays](https://pkarr.org/relays) to enable web applications to query the DHT.
 2. Act as [resolvers](https://pkarr.org/resolvers) to provide lower latency, more reliability and scalability.
 
-Relays are very light and cheap to operate, that they can easily run altruistically, but private, and paid servers are possible too.
+Relays are very light and cheap to operate, that they can easily run altruistically, but private, and paid relays are possible too.
 
 ### Republishers
 
@@ -96,7 +96,7 @@ To ensure a good chance of scalability and resilience, a few expectations need t
     - Popular records may or may not be refreshed by the DNS servers as they get queries for them.
 2. This is **not a realtime communication** medium
     - Records are heavily cached like in any DNS system.
-    - You are expected to update your records rarely, so you should expect servers to enforce harsh rate-limiting and maybe demand proof of work.
+    - You are expected to update your records rarely, so you should expect relays to enforce harsh rate-limiting.
     - Records are going to be cached heavily to reduce traffic on the DHT, so updates might take some time to propagate, even if you set TTL to 1 second.
     - In case of a chache miss, traversing the DHT might take few seconds.
 

flake.nix

@@ -28,7 +28,7 @@
           "Cargo.toml"
           "Cargo.lock"
           "pkarr"
-          "server"
+          "relay"
         ];
 
         buildSrc = flakeboxLib.filterSubPaths {
@@ -56,16 +56,16 @@
             workspaceBuild = craneLib.buildWorkspace {
               cargoArtifacts = workspaceDeps;
             };
-            "pkarr-server" =  craneLib.buildPackageGroup {
-              packages = [ "pkarr-server" ];
-              mainProgram = "pkarr-server";
+            "pkarr-relay" =  craneLib.buildPackageGroup {
+              packages = [ "pkarr-relay" ];
+              mainProgram = "pkarr-relay";
             };
           }
         );
       in
       {
         packages = {
-          pkarr-server = multiBuild.pkarr-server;
+          pkarr-relay = multiBuild.pkarr-relay;
         };
 
         legacyPackages = multiBuild;

server/README.md → relay/README.md

@@ -1,4 +1,4 @@
-# Pkarr Server
+# Pkarr Relay
 
 A server that functions as a [pkarr](https://github.com/Nuhvi/pkarr/) [relay](https://pkarr.org/relays) and
 [resolver](https://pkarr.org/resolvers).
@@ -20,17 +20,17 @@ cp src/config.example.toml config.toml
 Run with an optional config file
 
 ```bash
-../target/release/pkarr-server --config=./config.toml
+../target/release/pkarr-relay --config=./config.toml
 ```
 
 You can customize logging levels
 
 ```bash
-../target/release/pkarr-server --config=./config.toml -t=pkarr=debug,tower_http=debug
+../target/release/pkarr-relay --config=./config.toml -t=pkarr=debug,tower_http=debug
 ```
 
 ## Using Docker
-To build and run the Pkarr server using Docker, this repository has a `Dockerfile` in the top level. You could use a small `docker-compose.yml` such as:
+To build and run the Pkarr relay using Docker, this repository has a `Dockerfile` in the top level. You could use a small `docker-compose.yml` such as:
 
 ```
 services:
@@ -40,23 +40,10 @@ services:
     volumes: 
       - ./config.toml:/config.toml
       - .pkarr_cache:/cache
-    command: pkarr-server --config=/config.toml
+    command: pkarr-relay --config=/config.toml
 ```
 Alternatively, lunch docker correctly attaching the `config.toml` as a volume in the right location. In the example above `.pkarr_cache` relative directory is used to permanently store pkarr cached keys.
 
-An example `./config.toml` here (we are mounting it on the container)
-```
-relay_port = 6881
-dht_port = 6881
-cache_path = "/cache"
-cache_size = 1_000_000
-resolvers = []
-minimum_ttl = 300
-maximum_ttl = 86400
-[rate_limiter]
-behind_proxy = false
-per_second = 2
-burst_size = 10
-```
+An example `./config.toml` can be copied from `./src/config.example.toml` and customized as needed.
 
-This will make the Pkarr server accessible at http://localhost:6881.
+This will make the Pkarr relay accessible at http://localhost:6881.

server/src/config.rs → relay/src/config.rs

@@ -1,4 +1,4 @@
-//! Configuration for the server
+//! Configuration for Pkarr relay
 
 use anyhow::{Context, Result};
 use serde::{Deserialize, Serialize};

server/src/lib.rs → relay/src/lib.rs

@@ -101,7 +101,7 @@ impl Relay {
                         "operating environment provides no directory for application data"
                     )
                 })?;
-                path.join("pkarr-server")
+                path.join("pkarr-relay")
             }
         };