Merge branch 'Frando/hooks' of github.com:okdistribute/docs into Frando/hooks

Author: okdistribute

connecting/endpoint-hooks.mdx

@@ -19,7 +19,7 @@ Hooks run at two points:
 
 Hooks are registered with `Endpoint::builder().hooks(...)`. If multiple hooks are installed, they run in the order they were added, and a rejection from any hook short-circuits the rest.
 
-Note that hooks cannot *use* connections, they can only *observe* or *reject* them. This is an important separation of concerns: If hooks were allowed to use the connections in any way, they could interfer with the actual protocols running within these connections. Hooks can, however, *reject* connections before they are passed on to protocol handlers. This makes it possible to implement custom authentication schemes with hooks that work without any support from the protocols running in these connections.
+Note that hooks cannot *use* connections, they can only *observe* or *reject* them. This is an important separation of concerns: If hooks were allowed to use the connections in any way, they could interfere with the actual protocols running within these connections. Hooks can, however, *reject* connections before they are passed on to protocol handlers. This makes it possible to implement custom authentication schemes with hooks that work without any support from the protocols running in these connections.
 
 > **Note:** Hooks live on the `Endpoint` instance. Never store an `Endpoint` inside your hook type (even indirectly), or it may cause reference-counting cycles and prevent clean shutdown.
 
@@ -89,7 +89,7 @@ async fn main() -> n0_error::Result<()> {
 Hooks can be used to enforce policy. If a hook returns a rejection result, the connection is immediately aborted.
 The example below rejects all incoming connections after the handshake. Outgoing connections will still dial.
 
-In real applications, you would inspect `ConnectionInfo` and reject connections by checking the connection's remote id or aLPN against authentication state in your app.
+In real applications, you would inspect `ConnectionInfo` and reject connections by checking the connection's remote id or ALPN against authentication state in your app.
 
 ```rust
 use iroh::endpoint::{AfterHandshakeOutcome, ConnectionInfo, Endpoint, EndpointHooks, Side};
@@ -144,7 +144,7 @@ This example demonstrates how hooks can feed information to external tasks, givi
 ### [Aggregating information about remote endpoints](https://github.com/n0-computer/iroh/blob/feat-multipath/iroh/examples/remote-info.rs)
 
 This example implements a `RemoteMap` that tracks and aggregates information about all remotes our endpoint knows about.
-This can be useful if your app needs to chose between remotes, or for building diagnostic tools.
+This can be useful if your app needs to choose between remotes, or for building diagnostic tools.
 
 * A hook forwards `ConnectionInfo` updates into a worker task.
 * The worker maintains a map of all remotes with counts of active connections and observed statistics (e.g. latency/RTT, whether relay/IP paths were used, etc).