updates to v0.90 blog post

src/app/blog/iroh-0-90-the-canary-series/page.mdx

@@ -34,9 +34,9 @@ Welcome to a new release of `iroh`, a library for building on direct connections
 
 Last time we published a release blog, we said our next release would be our release candidate for `1.0`. But, while working through all of our breaking changes and updates, we realized that waiting until we had everything worked through and finished before releasing was *not* actually the best way for us to get a stable release into the hands of our users.
 
-In the pre 1.0 era, we’d found that 3 week release cycles were the sweet spot for our team. Not only did 3-week cycles help our working cadence, but it also made sure we got user feedback quickly, and allowed us to move forward with confidence. We want that confidence more than ever going into 1.0.
+In the pre 1.0 era, we’d found that three-week release cycles were the sweet spot for our team. Not only did three-week cycles help our working cadence, but it also made sure we got user feedback quickly, and allowed us to move forward with confidence. We want that confidence more than ever going into 1.0.
 
-So, we’ve decided that along with maintaining the `0.35` release (as well as the public infrastructure that supports `0.35`), we will be doing a series of releases that we will refer to as the “canary” releases. They will be versioned releases starting with `0.90`, and continuing up until we are ready for our `1.0-rc`.
+So, we’ve decided that along with maintaining the `0.35` release (as well as the public infrastructure that supports `0.35`), we will be doing a series of releases that we will refer to as “canary” releases. They will be versioned releases starting with `0.90`, and continuing up until we are ready for our `1.0-rc`.
 
 The biggest difference between the way we are thinking about our new series of releases is, starting with `0.90`, we are not guaranteeing network/protocol level stability until we make it to `1.0-rc`.
 
@@ -46,7 +46,7 @@ So for those who:
 - do not need worry about backwards-compatibility for their networks
 - are still in the prototyping stage, or have small, easily updated deployments
 
-We **highly** recommend coming along with us on our `0.90` canary journey. Our `0.90`, for example, already includes performance improvements, and we want you to benefit from these kinds of changes ASAP.
+We **highly** recommend coming along with us on our `0.90` canary journey. Our `0.90` release, for example, already includes performance improvements, and we want you to benefit from these kinds of changes ASAP.
 
 But, if your network cannot tolerate multiple breaking changes over a short period of time (on the order of months), then stay on the `0.35` series until we have a release candidate.
 
@@ -70,12 +70,36 @@ As described in our [last release blog post](/blog/iroh-0-35-prepping-for-1-0#re
 
 `iroh` no longer uses the STUN protocol to learn about our external addresses. We now rely on QUIC address discovery to to that. To that effect, the `iroh-relay`s starting from `0.90` no longer support the STUN protocol. Our `iroh` configuration has also changed, as the `RelayNode` now only has `quic` configuration options.
 
-## 👀 `n0-watcher` crate, and the `Watcher` trait 👀
+## 👀 `n0-watcher` crate and the `Watcher` trait 👀
 
-Many of APIs now return `impl Watcher` , like the `Endpoint::node_addr` method. Knowing your node’s `NodeAddr` may take a few milliseconds, since it needs to do some probing to discover its own public facing addresses (if any exist). Returning a `Watcher` here allows our users to “wait” for the `NodeAddr` value to “initialize” and also watch for any potential changes to our `NodeAddr`, in case the user needs to inform other processes about any address changes.
+Many of our APIs now return `impl Watcher`, like the `Endpoint::node_addr` method. Knowing all of the details of your node’s `NodeAddr` may take a few milliseconds.. Something like the local address may be almost instant, but knowing it's home `RelayUrl` or it's publically available addresses may take more time, since it needs to do some external probing to discover.
+
+Returning a `Watcher` here allows our users to “wait” for the `NodeAddr` in the way that is most useful for them. If you just want the earliest value, let's say because you know you are on an local network, call `initialize` to get the first value that appears.
+
+If you want updates, let's say because you need to know the `RelayUrl` or public facing addresses, you can call `stream` to get updates when new information comes in.
+
+```rust
+use iroh::Endpoint;
+use n0_watcher::Watcher;
+
+let endpoint = Endpoint::builder()
+    .alpns(vec![b"my-alpn".to_vec()])
+    .bind()
+    .await?;
+let node_addr = endpoint.node_addr().initialized().await?;
+let stream = endpoint.node_addr().stream();
+```
 
 Take a look at the [n0-watcher](https://docs.rs/n0-watcher/0.2.0/n0_watcher/) crate docs for more info, but just know that the `Watcher` trait is re-exported in `iroh`, so if you want to use the `Endpoint::node_addr` or `Endpoint::home_relay` methods in `iroh`, you will also need to import the `iroh::Watcher` trait.
 
+## ❗ Subtle expectation changes around `Endpoint::node_addr` and `Endpoint::home_relay` ❗
+
+With some shifting of internals, two specific methods have changed in a subtle way, without changing names.
+
+`Endpoint::node_addr` used to wait until a full net-report ran, so the first update to `node_addr` would usually include a `RelayUrl`. Now, `node_addr` returns whatever direct addresses we know about ASAP, without waiting for a `relay_url`. If you had code that relied on the existance of a `RelayUrl` in the `NodeAddr`, you must now listen for updates to check for its existence, or just use the `Endpoint::home_relay` method.
+
+Also, previously the `home_relay` and `node_addr` updated at the same time, which means that previously you could use the existance of one to imply the existence of the other. This is no longer the case, so make sure that your code does not rely on this logic.
+
 ## ⚠️ Breaking Changes
 
 - iroh