Update HIP-1046 with mirror node details

HIP/hip-1046.md

@@ -1,7 +1,7 @@
 ---
 hip: 1046
 title: Adding support for gRPC-Web proxy endpoints to the Address Book
-author: Joseph Sinclair <Joseph Sinclair<@jsync-swirlds>, Mark Blackman <mark@swirldslabs.com>, Simi Hunjan <simi@hashgraph.com>
+author: Joseph Sinclair <Joseph Sinclair<@jsync-swirlds>, Mark Blackman <mark@swirldslabs.com>, Simi Hunjan <simi@hashgraph.com>, Steven Sheehy <steven.sheehy@hashgraph.com>
 working-group: Mike Cave <mike@hedera.com>, Alex Popowycz <a@hedera.com>
 requested-by: Hedera
 type: Standards Track
@@ -12,7 +12,7 @@ discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/disc
 status: Accepted
 last-call-date-time: 2024-10-29T07:00:00Z
 created: 2024-09-18
-updated: 2024-10-22
+updated: 2025-05-21
 ---
 
 ## Abstract
@@ -49,8 +49,6 @@ Given that this proposal involves an incremental change to the already existing
 
 ## User stories
 
-## 
-
 1. As a Frontend Developer, I want the Hedera JavaScript SDK to dynamically retrieve gRPC-Web endpoints, so that my web application can securely connect to the Hedera network even as gRPC-Web endpoints change over time.
 
     Acceptance Criteria:
@@ -93,7 +91,7 @@ message NodeCreateTransactionBody {
     /**
      * A web proxy for gRPC from non-gRPC clients.
      */
-    proto.ServiceEndpoint grpc_proxy_endpoint = 8;**
+    proto.ServiceEndpoint grpc_proxy_endpoint = 8;
 }
 ```
 
@@ -110,7 +108,7 @@ message NodeUpdateTransactionBody {
     /**
      * A web proxy for gRPC from non-gRPC clients.
      */
-    proto.ServiceEndpoint grpc_proxy_endpoint = 9;**
+    proto.ServiceEndpoint grpc_proxy_endpoint = 9;
 }
 
 ```
@@ -131,19 +129,66 @@ message Node {
     /**
      * A web proxy for gRPC from non-gRPC clients.
      */
-    proto.ServiceEndpoint grpc_proxy_endpoint = 11;**
+    proto.ServiceEndpoint grpc_proxy_endpoint = 11;
 }
 
+### Mirror Node
+
+The mirror node REST API will be updated to add the gRPC proxy endpoints. The `/api/v1/network/nodes` endpoint currently returns an array of "nodes" objects. A new property `grpc_proxy_endpoint` will be added to each node in the "nodes" JSON response object. The `grpc_proxy_endpoint` will match the same structures as the objects returned in the `service_endpoints` list and thus will contain `domain_name`, `ip_address_v4`, and `port` fields.
+
+An example `/api/v1/network/nodes` message REST API response with the new property is shown below.
+
+```json
+{
+  "nodes": [
+    {
+      "decline_reward": true,
+      "description": "address book 1",
+      "file_id": "0.0.102",
+      "grpc_proxy_endpoint": {
+        "domain_name": "proxy.example.com",
+        "ip_address_v4": "",
+        "port": 80
+      },
+      "max_stake": 50000,
+      "memo": "0.0.4",
+      "min_stake": 1000,
+      "node_account_id": "0.0.4",
+      "node_cert_hash": "0x01d173753810c0aae794ba72d5443c292e9ff962b01046220dd99f5816422696e0569c977e2f169e1e5688afc8f4aa16",
+      "node_id": 1,
+      "public_key": "0x4a5ad514f0957fa170a676210c9bdbddf3bc9519702cf915fa6767a40463b96f",
+      "reward_rate_start": 1000000,
+      "service_endpoints": [
+        {
+          "domain_name": "",
+          "ip_address_v4": "128.0.0.6",
+          "port": 50216
+        }
+      ],
+      "stake": 20000,
+      "stake_not_rewarded": 19900,
+      "stake_rewarded": 100,
+      "staking_period": {
+        "from": "1655164800.000000000",
+        "to": "1655251200.000000000"
+      },
+      "timestamp": {
+        "from": "187654.000123457",
+        "to": null
+      }
+    }
+  ],
+  "links": {
+    "next": null
+  }
+}
 ```
-new NodeCreateTransaction()
-	....
-	.setNodeType ()
-	...
 
 ## Backwards Compatibility
 
 Initially, there should be no change or impact to existing users of the browser based SDKs and gRPC-Web nodes.
 The current set of nodes will remain available at the current addresses. After all browser based SDKs are migrated to use dynamic lookup of the addresses via the mirror node APIs, the existing nodes are expected to remain at the current addresses for some time, but may, eventually, begin to migrate.  Clients using browser based SDKs should adopt the new SDK versions that support dynamic address lookup within this time period.  Clients not using SDKs to access the gRPC-Web nodes should also migrate to look up the node addresses via the mirror node APIs in the same time period.
+
 Any client that chooses to continue using the legacy approach of manually maintaining a fixed static list of gRPC-Web nodes may continue to do so, with the constraint that those entities may need to make more frequent updates to their static lists, but the information for those updates will be available from the mirror node.
 
 ## Security Implications
@@ -169,6 +214,8 @@ Configuration on the consensus nodes, with the same data configured for the SDK.
 An Hedera File System (HFS) file containing the list in a JSON document.
 This would require Mirror Node to read that file and offer an API to query the contents.
 
+The mirror node gRPC API `NetworkService.getNodes()` returns similar information as the `/api/v1/network/nodes` REST API and could be updated to include a new `grpc_proxy_endpoint` field to keep it consistent. After consideration, this idea was rejected since the consumer of the gRPC proxy endpoints are web browser-based clients that are unable to invoke gRPC in the browser.
+
 ## Open Issues
 
 No open issues