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

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 payer_account_id field should be added to the JSON response of /api/v1/topics/{topicId}/messages, /api/v1/topics/{topicId}/messages/{sequenceNumber}, and /api/v1/topics/messages/{consensusTimestamp}.

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 processes 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.

So the full topic message REST API response (with consideration for the expanding transactionID object) should become:

{
  "chunk_info": {
    "initial_transaction_id": {
      "account_id": "0.0.1000",
      "nonce": 1,
      "scheduled": true,
      "transaction_valid_start": "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
}

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

A previous idea expressed the transactionId in its string form as shown below. However, after consideration this option limits the information conveyed since the transactionId proto may expand with the change of the string e.g. addition of nonce, schedule

{
  "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
}

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)

Citation

Please cite this document as: