HIP-171: Add Message Sender's Account Id to Mirror Node API Response

[scalemaildev]

As per: #171

---

hip: <HIP number (this is determined by the HIP editor)>
title: Add Message Sender's Account Id to Mirror Node API Response
author: John Conway (@scalemaildev)
type: Standards Track
category: Mirror
needs-council-approval: Yes
status: Review
created: 2021-10-18
discussions-to: #190
updated: 2021-11-04

Abstract

When returning a GET request from the mirror node API for a topic's message(s), return the account ID of each message's sender within its metadata.

Motivation

During the development of the Hashgraph Chess Application I ran into a problem: the game needed to filter out chess moves and chat messages that aren't from one of the game's two players. But I also didn't want to make either player the admin of their game's topic.

Since the account ID of a message's sender isn't included in the message metadata, I had to put their ID into the message content. This leaves the application open to spoof attacks, as anyone can submit a message to the topic with this field reconstructed. While there are some workaround methods to address this (such as querying the message by its transaction ID) the simplest method for resolving this problem would be to add the account ID of a message's sender to its metadata.

Rationale

Many use cases for the HCS would want to know who is sending a message to a public topic. Workaround methods, such as querying the transaction ID for a message and pulling the sender's ID from its timestamp, would involve extra API calls -- this puts unnecessary strain on the mirror node and adds complexity to the app. Having a trustworthy source of information for who sent a message would allow developers to handle logic involving the sender's ID within their application.

Originally, I had requested giving the GET request an additional parameter for adding the account ID to the metadata -- because some use cases might not want to make a message's sender public. However, on closer inspection the sender ID can be gleaned from querying the message timestamp anyway. So the message sender's identity is always accessible, it just isn't immediately available.

User stories

As a developer, I want to know what account sent an HCS message from the message's metadata.

Specification

A new metadata field should be added to the responses of a mirror node's GET request for messages. My suggestion is a key of 'sender_id' and the value being a string containing the sender's account ID in the typical 'x.y.zzz' format.

Backwards Compatibility

N/A

Security Implications

There may be some concern with having a sender's ID available, but this information can be gleaned from querying the message's transaction ID anyway.

How to Teach This

N/A

Reference Implementation

TBD...

Rejected Ideas

N/A

Open Issues

N/A

References

Hashgraph Chess Repo

Copyright/license

This document is licensed under the Apache License, Version 2.0 -- see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

[sergmetelin]

This message is a Last Call notification calling for community feedback on this HIP.

If no substantial changes will be requested for this HIP before 2021-11-23 07:00:00 +0000, this HIP will change its status to Council Review.

[steven-sheehy]

This HIP is a bit lacking in detail and should be updated with specifics. My assumption is you are asking if a payer_account_id field could be added to the JSON response of /api/v1/topics/{topicId}/messages, /api/v1/topics/{topicId}/messages/{sequenceNumber}, and /api/v1/topics/messages/{consensusTimestamp}?

If so, I think it is pretty reasonable to add that. We already have a topic_message.payer_account_id in the table but it is only populated if chunkInfo is present in the protobuf. Services validates that if chunkInfo is populated that the payer of the transaction must match chunkInfo.payerAccountId. So really we can just always populate it with the transaction.payer_account_id so it's present for both chunked and non-chunked messages. Then we can return it on the REST API without incurring the cost of a join against the transaction table. This will require a database migration to backfill this data for entries that are null.

Since we're adding fields to the topic messages, we should also maybe add the missing chunk information:

"chunk_info": {
  "initial_transaction_id": "0.0.8-1234567890-000000006",
  "number": 2,
  "total": 5
}

So the full topic message REST API response should become:

{
  "chunk_info": {
    "initial_transaction_id": "0.0.1000-1234567890-000000006",
    "number": 2,
    "total": 5
  },
  "consensus_timestamp": "1234567890.000000001",
  "topic_id": "0.0.7",
  "message": "bWVzc2FnZQ==",
  "payer_account_id": "0.0.1000",
  "running_hash": "cnVubmluZ19oYXNo",
  "running_hash_version": 2,
  "sequence_number": 1
}

Can you make the above changes to the HIP if you agree?

[scalemaildev]

It looks fine to me.

Updated in PR: #225

[scalemaildev]

Any update on this? I see it's still waiting on council approval.

[steven-sheehy]

HIP-171 has been implemented in v0.49.1 and live in production since Feb. 23 2022.