/v1/keys endpoint should include input_fee_ppk #289

New issue

Closed

opened 2025-09-24 10:08:54 +00:00 by robwoodgate · 2 comments

robwoodgate commented

2025-09-24 10:08:54 +00:00

(Migrated from github.com)

In #182, I raised a related point that the /v1/keys endpoint should ideally return ALL keyset fields required for active wallet operations.

This allows a consumer to call just ONE endpoint and get data needed for active wallet ops - fees, expiry, keys etc etc

That way, the /v1/keysets endpoint can just be called when non-operational, historic or inactive keyset metadata is required.

@callebtc made the comment:

Nevertheless: wallets should hit /keysets for metadata, and /keys for the actual keys.

I agree in principle - if there was a lot of incidental metadata - but in the v1 API, both are practically identical:

/v1/keysets
    {
      "id": <hex_str>,
      "unit": <str>,
      "active": <bool>,
      "input_fee_ppk": <int|null>,
      "final_expiry": <int|null>
    }

/v1/keys
    {
      "id": <keyset_id_hex_str>,
      "unit": <currency_unit_str>,
      "final_expiry": <unix_timestamp_int|null>
      "keys": {
        <amount_int>: <public_key_str>,
        ...
      }
    }

active is implied in /v1/keys - as only active keysets are returned.
Which means the only "missing" metadata is input_fee_ppk, which is vital to wallet operations.

It seems sub-optimal to make a consumer lookup two endpoints just to get the keyset fee, which is as as vital to wallet ops as final_expiry.

In #182, I raised a related point that the `/v1/keys` endpoint should ideally return ALL keyset fields required for active wallet operations. This allows a consumer to call just ONE endpoint and get data needed for active wallet ops - fees, expiry, keys etc etc That way, the `/v1/keysets` endpoint can just be called when non-operational, historic or inactive keyset metadata is required. @callebtc made the comment: > Nevertheless: wallets should hit `/keysets` for metadata, and `/keys` for the actual keys. I agree in principle - if there was a lot of incidental metadata - but in the v1 API, both are practically identical: ```ts /v1/keysets { "id": <hex_str>, "unit": <str>, "active": <bool>, "input_fee_ppk": <int|null>, "final_expiry": <int|null> } /v1/keys { "id": <keyset_id_hex_str>, "unit": <currency_unit_str>, "final_expiry": <unix_timestamp_int|null> "keys": { <amount_int>: <public_key_str>, ... } } ``` `active` is implied in /v1/keys - as only active keysets are returned. Which means the only "missing" metadata is `input_fee_ppk`, which is vital to wallet operations. It seems sub-optimal to make a consumer lookup two endpoints just to get the keyset fee, which is as as vital to wallet ops as `final_expiry`.

a1denvalu3 commented

2025-09-27 09:30:48 +00:00

(Migrated from github.com)

I agree👍