docs: add Exchange Rates event (NIP-33 kind 30078)

Add documentation for the new exchange rates publishing feature via Nostr.

## Overview

Mostro instances can now publish Bitcoin/fiat exchange rates as NIP-33
addressable events (kind 30078) to provide censorship-resistant price
data for clients.

## Key Features

- **Event kind**: 30078 (NIP-33 addressable, replaceable)
- **d tag**: "mostro-rates" (unique identifier)
- **Content**: Full Yadio API format {\BTC\: {\USD\: 50000.0, ...}}
- **Expiration**: NIP-40 tag (min(interval × 2, 3600))
- **Configurable**: Update interval (default 300s, min 60s)
- **Optional**: Can be disabled via config

## Why Nostr?

In censored regions (Venezuela, Cuba, Iran), HTTP exchange rate APIs
are often blocked. Nostr's decentralized relay network provides:

- Censorship resistance
- Zero scaling cost
- Geographic distribution
- No single point of failure

## Security

Clients MUST:
- Verify event.pubkey matches expected Mostro instance
- Verify signature (NIP-01)
- Check expiration timestamp
- Fall back to HTTP API if Nostr fails

## Implementation

- Daemon PR: MostroP2P/mostro#685
- Client spec: MostroP2P/app#36

Related to the Venezuela censorship resistance use case discussed in:
MostroP2P/mostro#684

Author: Mostronator

src/other_events.md

@@ -224,6 +224,111 @@ The operator of a Mostro instance decides which relays the events from that inst
 
 The `r` label indicates the relays through which the Mostro instance is publishing its events.
 
+## Exchange Rates (NIP-33 Kind 30078)
+
+Each Mostro instance can optionally publish Bitcoin/fiat exchange rates to Nostr relays as [NIP-33](https://github.com/nostr-protocol/nips/blob/master/33.md) addressable events (kind 30078). This enables:
+
+- **Censorship resistance**: Mobile clients in censored regions (Venezuela, Cuba, etc.) can fetch rates via Nostr relays
+- **Zero scaling cost**: Relays distribute events; no per-request infrastructure needed for the rate provider
+- **Backward compatibility**: HTTP API remains available as fallback for clients
+
+The daemon fetches rates from a price API (e.g., Yadio) at a configurable interval and publishes the complete payload to Nostr. This is a **replaceable event** (NIP-33), meaning relays keep only the latest version identified by the `d` tag.
+
+### Event Structure
+
+```json
+[
+  "EVENT",
+  "RAND",
+  {
+    "id": "<Event id>",
+    "pubkey": "<Mostro's pubkey>",
+    "kind": 30078,
+    "tags": [
+      ["d", "mostro-rates"],
+      ["published_at", "1732546800"],
+      ["source", "yadio"],
+      ["expiration", "1732550400"]
+    ],
+    "content": "{\"BTC\": {\"USD\": 50000.0, \"EUR\": 45000.0, \"VES\": 850000000.0, \"ARS\": 105000000.0, ...}}",
+    "sig": "<Mostro's signature>",
+    "created_at": 1732546800
+  }
+]
+```
+
+### Tags
+
+- **d**: `"mostro-rates"` — NIP-33 identifier that makes this event replaceable. Each new rate update replaces the previous one.
+- **published_at**: Unix timestamp when the daemon published the event (daemon time, not source timestamp).
+- **source**: Rate source identifier (e.g., `"yadio"`).
+- **expiration**: Unix timestamp for event expiration ([NIP-40](https://github.com/nostr-protocol/nips/blob/master/40.md)). Prevents stale rates from being served. Calculated as `min(update_interval × 2, 3600)` to allow for delays while capping at 1 hour.
+
+### Content Format
+
+The `content` field contains the full rate response in JSON format matching the source API structure (Yadio format):
+
+```json
+{
+  "BTC": {
+    "BTC": 1,
+    "USD": 50000.0,
+    "EUR": 45000.0,
+    "VES": 850000000.0,
+    "ARS": 105000000.0,
+    "AED": 260491.35,
+    "..."
+  }
+}
+```
+
+**Rate semantics**: Each value under `"BTC"` represents the price of 1 BTC in that currency.
+
+**Example**: `"USD": 50000.0` means 1 BTC = 50,000 USD.
+
+### Configuration
+
+Exchange rate publishing is configured in `settings.toml`:
+
+```toml
+[mostro]
+# Enable Nostr exchange rate publishing (default: true)
+publish_exchange_rates_to_nostr = true
+
+# Update interval in seconds (default: 300, minimum: 60)
+exchange_rates_update_interval_seconds = 300
+```
+
+If `publish_exchange_rates_to_nostr` is `false`, no exchange rate events are published.
+
+### Client Usage
+
+Clients should:
+
+1. **Subscribe** to events with filter: `{"kinds": [30078], "#d": ["mostro-rates"], "authors": [<mostro_pubkey>]}`
+2. **Verify** the event signature and that `event.pubkey` matches the expected Mostro instance pubkey (prevents price manipulation)
+3. **Parse** the `content` field as JSON
+4. **Check** the `expiration` tag to ensure rates are not stale
+5. **Fall back** to HTTP API if Nostr fails or rates are expired
+
+### Security Considerations
+
+**⚠️ CRITICAL**: Clients MUST verify `event.pubkey == expected_mostro_pubkey` before using the rates. Without this check, a malicious actor could publish fake rates to manipulate prices.
+
+**Signature verification**: Use standard Nostr signature verification (NIP-01) to ensure the event was signed by the Mostro instance's private key.
+
+**Expiration**: Clients should reject events where `current_time > expiration` to avoid using stale rates.
+
+### Why Nostr?
+
+In countries with government censorship (Venezuela, Cuba, Iran, etc.), HTTP access to exchange rate APIs is often blocked. Nostr's decentralized relay network makes censorship impractical:
+
+- **Geographic distribution**: Relays are hosted worldwide
+- **No single point of failure**: Blocking one relay doesn't affect others
+- **Standard Nostr infrastructure**: No special infrastructure needed; uses existing Nostr relay network
+
+This aligns with Mostro's mission to provide censorship-resistant peer-to-peer Bitcoin trading.
+
 # Development Fee
 
 The development fee mechanism provides sustainable funding for Mostro development by automatically sending a configurable percentage of the Mostro fee to a lightning address on each successful order, this a regular event with kind 8383 which is expected to be stored by relays.