project-robius / project-robius/robrix

[TSP] Don't send the entire TSP-signed message in the message content's signature field

Open
#599 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

blocked tsp
Dominant language
Rust
Stars
487
Forks
68
Avg merge
1h 22m
Merged PRs (30d)
54

Description

The TSP SDK's sign_anycast() function returns a single byte array that contains the TSP signature, header, and message payload all in one big contiguous chunk.
This is quite inefficient; ideally, we do not want to send the entire message content in the org.robius.tsp_signature field, because it is already included in the Matrix room message event content itself, meaning that the message payload actually gets sent twice.
The other problem with this is that there is a size limit on the content field, so adding large custom subfields is a nonstarter, which will happen for large messages like long text, images, files, etc.

Instead, we should separate out the TSP signature & header from the message payload itself, and include the non-payload bytes only in the content's org.robius.tsp_signature field.

Blocked on this issue from the TSP SDK. See that issue for more info.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the TSP SDK issue 218 and the integration entry point that calls sign_anycast(). Trace how its byte array is placed in the Matrix event content's org.robius.tsp_signature field, then confirm how the message payload is already represented in the room event. Done means the signature field contains only the TSP signature and header after the SDK supports separating them.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.