Add docs from n0des repository

about/faq.mdx

@@ -79,7 +79,7 @@ We rely on iroh remaining open source, and are committed to keeping it that way,
 
 ## How do iroh and libp2p compare?
 
-Generally, we've put a lot of effort into making iroh "peer to peer connections that *just work*".
+Generally, we've put a lot of effort into making "connections that *just work*".
 This means we've kept the scope small: There's no DHT, swarm, or gossipsub.
 Instead, what you get are reliable direct [QUIC](https://en.wikipedia.org/wiki/QUIC) connections between iroh endpoints.
 On top of these, some of said libp2p features can be implemented as *protocols* on top, see for example [iroh-gossip](https://github.com/n0-computer/iroh-gossip/) which provides gossipsub-like functionality.

concepts/relays.mdx

@@ -34,7 +34,7 @@ relays provide better performance, security, and uptime guarantees compared to
 the public relays. 
 
 Relay code is open source! You can run your own relay server, or [pick a hosting
-provider](https://n0des.iroh.computer).
+provider](/iroh-online).
 
 
 ## Why this architecture is powerful
@@ -76,5 +76,5 @@ required from the application.
 - [Dedicated infrastructure guide](/deployment/dedicated-infrastructure)
 - [Relay source code](https://github.com/n0-computer/iroh/tree/main/iroh-relay)
 - [Relay binary releases](https://github.com/n0-computer/iroh/releases)
-- [Managed relay service](https://n0des.iroh.computer)
+- [Managed relay service](/iroh-online/relays)
 

connecting/gossip.mdx

@@ -122,7 +122,7 @@ println!("Share this ticket to let others join the gossip topic: {ticket}");
 You can also use iroh's rendezvous servers to find bootstrap peers for a topic.
 To do this, you can create an endpoint ticket for relay to use to discover
 peers. For more information on how to broadcast tickets on the relay
-server, see [n0des.iroh.computer](https://n0des.iroh.computer).
+server, see [Iroh Online](/iroh-online).
 
 ### Picking a topic ID
 

deployment/dedicated-infrastructure.mdx

@@ -24,7 +24,7 @@ endpoint to use your relay's URL.
 
 For detailed information on configuring custom relays, including code examples
 and API documentation, see the [iroh relay configuration
-guide](https://n0des.iroh.computer/docs/relays/managed).
+guide](/iroh-online/relays/managed).
 
 ## Why use dedicated relays in production?
 
@@ -36,11 +36,11 @@ latency for your specific use case.
 If you require more control over your relay infrastructure, you can choose to
 [self-host your own
 relay](https://github.com/n0-computer/iroh/tree/main/iroh-relay) or [upgrade to
-a managed relay service](https://n0des.iroh.computer). This managed relay
+a managed relay service](/iroh-online/relays). This managed relay
 service is monitored by [the n0 team](https://n0.computer) who maintain the iroh project, and
 offers SLAs around uptime and performance.
 
-[Sign up for a free trial of n0des](https://n0des.iroh.computer) to get access
+[Sign up for a free trial of Iroh Online](/iroh-online) to get access
 to purchase a managed relay with uptime SLAs.
 
 

deployment/metrics.mdx

@@ -37,9 +37,9 @@ As a convenience, the iroh team  runs a service that collects Prometheus metrics
 applications using iroh. To export your metrics to this service, you can use the
 `iroh-n0des` crate.
 
-First, sign up for an account on [n0des.iroh.computer](https://n0des.iroh.computer/signup) and create a project.
+First, sign up for an account on [Iroh Online](/iroh-online) and create a project.
 
 Then, follow the instructions in the [iroh-n0des
-documentation](https://n0des.iroh.computer/docs/metrics/custom) to set up the exporter in your
+documentation](/iroh-online/metrics/custom) to set up the exporter in your
 application.
 

docs.json

@@ -11,7 +11,7 @@
   "navigation": {
     "tabs": [
       {
-        "tab": "Docs",
+        "tab": "Rust Library",
         "groups": [
           {
             "group": "Getting Started",
@@ -71,6 +71,39 @@
             "pages": ["about/changelog", "about/roadmap", "about/faq"]
           }
         ]
+      },
+      {
+        "tab": "Iroh Online",
+        "groups": [
+          {
+            "group": "Getting Started",
+            "pages": [
+              "iroh-online/index",
+              "iroh-online/quickstart",
+              "iroh-online/projects",
+              "iroh-online/access",
+              "iroh-online/support"
+            ]
+          },
+          {
+            "group": "Metrics",
+            "pages": [
+              "iroh-online/metrics/index",
+              "iroh-online/metrics/how-it-works",
+              "iroh-online/metrics/custom",
+              "iroh-online/metrics/endpoint",
+              "iroh-online/metrics/glossary"
+            ]
+          },
+          {
+            "group": "Relays",
+            "pages": [
+              "iroh-online/relays/index",
+              "iroh-online/relays/public",
+              "iroh-online/relays/managed"
+            ]
+          }
+        ]
       }
     ]
   },

iroh-online/access.mdx

@@ -0,0 +1,60 @@
+---
+title: "Access Control"
+description: "Manage authorization and API keys for your Iroh Online project"
+---
+
+Some features on your Iroh Online project require authorization.
+
+Examples of what **doesn't** require authorization:
+- Synchronizing data across relays 
+- [Holepunching](/concepts/holepunching) connections to other iroh endpoints
+
+Examples of what **does** require authorization:
+- Uploading metrics from endpoints to your project
+- Creating custom metrics
+
+# API Keys
+
+The Iroh Online platform adds access control on top of iroh's permissionless system to control who
+can & cannot make use of resources backed by cloud infrastructure.
+
+Access control in Iroh Online aims to be as minimal as possible, leaving room for your
+app to have its own opinion of how access control should work within your app.
+
+Connections over iroh are end-to-end encrypted, using ED25519 keypairs on either
+end of the connection. Iroh Online re-uses ED keys for SSH-style access.
+
+To authorize endpoints to push metrics to your project, Iroh Online uses API Keys.
+
+## Creating an API Key
+
+1. Go to your project dashboard
+2. Click on the "API Keys" tab
+3. Click "Create API Key"
+4. Give your API Key a name
+5. Click "Create"
+
+```rust
+use iroh::Endpoint;
+use iroh_n0des::Client;
+
+#[tokio::main]
+async fn main() -> anyhow::Result<()> {
+    let endpoint = Endpoint::builder().bind().await?;
+    endpoint.online().await;
+
+    // Use your API key to authenticate
+    let client = Client::new(&endpoint, "YOUR_API_KEY").await?;
+
+    Ok(())
+}
+```
+
+See the [quickstart](/iroh-online/quickstart) for a full example of using the Iroh Online client.
+
+## Permissions
+
+Right now, API Keys only control access to pushing metrics to your project.
+In the future, API Keys may be used to control access to other resources
+within your project. If you are interested in permissions or time-based access
+control, please [contact us](https://n0.computer/contact).

iroh-online/index.mdx

@@ -0,0 +1,18 @@
+---
+title: "Welcome to Iroh Online"
+description: "Iroh Online is a service for managing and monitoring the behavior of networks that are built with iroh"
+---
+
+### Hello fren,
+
+The first time you sign up for an account on Iroh Online, you are asked to create a
+**project**.  A project is your control & monitoring center for your network.
+You can provision relays, monitor metrics, create alerts, run simulations, and
+manage workflows. 
+
+## Get Started
+
+- [Quickstart](/iroh-online/quickstart): Learn how to build your first Iroh Online-enabled application.
+- [Access](/iroh-online/access): Understand how to manage access control for your Iroh Online project.
+- [Metrics](/iroh-online/metrics): Learn about the metrics collected by Iroh Online and how to use them to monitor your network.
+- [Relays](/iroh-online/relays): Discover how to provision and manage relay servers for your network.

iroh-online/metrics/custom.mdx

@@ -0,0 +1,54 @@
+---
+title: "Custom Metrics"
+description: "Create behavioral aggregations to monitor the health of your software"
+---
+
+Custom metrics enable you to create behavioral aggregations that can help you monitor the health of your software. 
+
+## Project-level Metrics
+
+For free, the Iroh Online platform will calculate the following metrics for all projects:
+
+- **Connections**: The number of successful and active connections made through the relay servers.
+- **Latency**: The time it takes for a request to travel from one endpoint to another.
+- **Throughput**: Also known as data transfer rate, this is a measurement of the amount of data processed by the relay server in a given time period.
+
+## Relay-level Metrics
+
+Additionally, for projects on the Pro or Enterprise
+plans, the Iroh Online platform will calculate the following relay-level metrics:
+
+- **Holepunching Rate**: The success rate of holepunching attempts made by the relay server.
+- **Uptime**: The amount of time the relay server is operational and available to handle requests.
+
+For a list of all metrics, see the [metrics glossary](/iroh-online/metrics/glossary).
+
+## Creating Custom Metrics
+
+These built-in metrics are not always sufficient for monitoring the health of
+your application, especially when you have specific performance indicators that are
+unique to your use case.
+
+In this tutorial, we will build our first custom metric which will be based on a
+simple iroh-docs protocol implementation. Each time a document is written
+successfully, we will report the metric to the Iroh Online platform. 
+
+For a complete example, see the [iroh-ping example on GitHub](https://github.com/n0-computer/iroh-ping).
+
+```rust
+use iroh::Endpoint;
+use iroh_n0des::Client;
+
+#[tokio::main]
+async fn main() -> anyhow::Result<()> {
+    let endpoint = Endpoint::builder().bind().await?;
+    endpoint.online().await;
+
+    let client = Client::new(&endpoint, "YOUR_API_KEY").await?;
+
+    // Report a custom metric
+    client.metric("document_written", 1).await?;
+
+    Ok(())
+}
+```

iroh-online/metrics/endpoint.mdx

@@ -0,0 +1,37 @@
+---
+title: "Endpoint Metrics"
+description: "Detailed metrics at the endpoint level for Pro and Enterprise plans"
+---
+
+On the pro and enterprise plan, you can get more detailed
+metrics at the endpoint level. These metrics give you visibility into the behavior
+of individual endpoints in your network. This can help you identify performance issues
+or bottlenecks that may be affecting specific endpoints.
+
+Some of the key endpoint-level metrics include:
+
+- **Request Latency**: The time taken to process requests at the endpoint.
+- **Error Rates**: The frequency of errors occurring at the endpoint.
+- **Throughput**: The amount of data processed by the endpoint over time.
+- **Connection Counts**: The number of active direct connections to the endpoint.
+
+In the Iroh Online dashboard, you can view these metrics for each endpoint added to
+your project. Drilling down into a specific endpoint can be a powerful tool to 
+identify and resolve issues quickly.
+
+By monitoring endpoint-level metrics, you can ensure that each node in your
+network is performing optimally, leading to a better overall experience for your users.
+
+## Retention and Lookback
+
+Projects on the Pro or Enterprise plans have access to
+extended retention and lookback for endpoint-level metrics. This allows you to
+analyze historical data and identify trends over time, which can be crucial for
+long-term performance optimization and troubleshooting.
+
+Please refer to the pricing page for more details on plan features
+and benefits. [Contact us](mailto:contact@n0.computer) if you have any questions about upgrading your plan.
+
+## Glossary
+
+For a list of all endpoint-level metrics, see the [metrics glossary](/iroh-online/metrics/glossary).

iroh-online/metrics/glossary.mdx

@@ -0,0 +1,94 @@
+---
+title: "Metrics Glossary"
+description: "Complete reference of all available metrics in Iroh Online"
+---
+
+List of all available metrics. Below is a reference grouping of every metric exposed by the frontend metrics registry, organized by level:
+
+## Project-level metrics
+
+These metrics are aggregated at the project level (overall project view / dashboard).
+
+| Metric (group.metric) | Short description | Units |
+|---|---|---:|
+| direct_data_rate | Measured traffic that doesn't pass through a relay, as a percentage of total traffic | Percentage |
+| direct_connection_rate | Measured connections that become direct at least once during the lifetime of the connection | Percentage |
+| blobs.egress | Blobs egress | Bytes |
+| blobs.ingress | Blobs ingress | Bytes |
+| connections.active | Active connections through relay servers | Count |
+| latency.p50 | 50th percentile latency between endpoints | Milliseconds |
+| latency.p90 | 90th percentile latency between endpoints | Milliseconds |
+| latency.p99 | 99th percentile latency between endpoints | Milliseconds |
+
+## Relay-level metrics
+
+Metrics in this section relate to relays and relay servers (visibility about relay processes/servers).
+
+| Metric (group.metric) | Short description | Units |
+|---|---|---:|
+| relay.bytes_recv | Total bytes received (relay side) | Bytes |
+| relay.bytes_sent | Total bytes sent (relay side) | Bytes |
+| relay.conns_rx_ratelimited | Connections rate-limited events | Count |
+| relay.disco_packets_dropped | Discovery packets dropped | Count |
+| relay.disco_packets_recv | Discovery packets received | Count |
+| relay.disco_packets_sent | Discovery packets sent | Count |
+| relay.disconnects | Disconnect events | Count |
+| relay.frames_rx_ratelimited | Frames rate-limited events | Count |
+| relay.got_ping | Got ping events | Count |
+| relay.other_packets_dropped | Other packets dropped | Count |
+| relay.other_packets_recv | Other packets received | Count |
+| relay.other_packets_sent | Other packets sent | Count |
+| relay.relay_accepts | Relay accepts (new relay connections accepted) | Count |
+| relay.send_packets_dropped | Sent packets dropped | Count |
+| relay.send_packets_recv | Sent packets received | Count |
+| relay.send_packets_sent | Sent packets sent | Count |
+| relay.sent_pong | Sent pong events | Count |
+| relay.unique_client_keys | Unique client keys observed | Count |
+| relay.unknown_frames | Unknown frame types observed | Count |
+| relay.websocket_accepts | WebSocket accepts | Count |
+| relay.relay_server.connections | Relay server connections | Count |
+| relay.relay_server.egress | Number of bytes relayed (egress) | Bytes |
+
+## Endpoint-level metrics
+
+These metrics are collected at the endpoint/node level to give per-endpoint visibility.
+
+| Metric (group.metric) | Short description | Units |
+|---|---|---:|
+| connection_became_direct | Count of connections that switched from using a relay to a direct connection at least once | Count |
+| connection_handshake_success | Count of successfully established secure connections | Count |
+| recv_data_ipv4 | Measured data received directly by nodes through IPv4 | Bytes |
+| recv_data_ipv6 | Measured data received directly by nodes through IPv6 | Bytes |
+| recv_data_relay | Measured data received by nodes through relay (IPv4 or IPv6) | Bytes |
+| send_data | Measured data sent from nodes in the network | Bytes |
+| send_ipv4 | Amount of data sent directly via IPv4 | Bytes |
+| send_ipv6 | Amount of data sent directly via IPv6 | Bytes |
+| send_relay | Amount of data sent through relay (measured by nodes sending data) | Bytes |
+| send_data_network_down | Data send events when network down | Bytes |
+| nodes_contacted_directly | Number of nodes contacted directly | Count |
+| nodes_contacted | Number of nodes contacted (any) | Count |
+| num_direct_conns_added | Number of direct connections added | Count |
+| num_direct_conns_removed | Number of direct connections removed | Count |
+| num_relay_conns_added | Number of relay connections added | Count |
+| num_relay_conns_removed | Number of relay connections removed | Count |
+| recv_datagrams | Received datagrams | Count |
+| recv_gro_datagrams | Received GRO datagram counts | Count |
+| update_direct_addrs | Direct address update events | Count |
+| portmap.external_address_updated | External address updated events | Count |
+| portmap.local_port_updates | Local port updates events | Count |
+| portmap.mapping_attempts | Mapping attempts (NAT traversal attempts) | Count |
+| portmap.mapping_failures | Mapping failures (failed NAT mappings) | Count |
+| portmap.pcp_available | PCP (Port Control Protocol) availability events | Count |
+| portmap.pcp_probes | PCP probe events | Count |
+| portmap.probes_started | Portmap probes started | Count |
+| portmap.upnp_available | UPnP availability events | Count |
+| portmap.upnp_gateway_updated | UPnP gateway updated events | Count |
+| portmap.upnp_probes_failed | UPnP probes failed | Count |
+| portmap.upnp_probes | UPnP probe events | Count |
+| netreport.report_reports_full | NetReport: reports_full (report fullness events) | Count |
+| netreport.report_reports | NetReport: reports (report events) | Count |
+| netreport.report_stun_packets_dropped | STUN packets dropped (netreport) | Count |
+| netreport.report_stun_packets_recv_ipv4 | STUN packets received (IPv4) | Count |
+| netreport.report_stun_packets_recv_ipv6 | STUN packets received (IPv6) | Count |
+| netreport.report_stun_packets_sent_ipv4 | STUN packets sent (IPv4) | Count |
+| netreport.report_stun_packets_sent_ipv6 | STUN packets sent (IPv6) | Count |