Change Details

The purpose of this endpoint is to allow users an easy way to explore the groups indexed by a plugin. The APIs are designed to be extremely fast, by basically slicing exactly the requested info from the DB without having to search through the DB in any significant way. The `prefix` param is intended to make plugins prefix different kinds of groups with different prefixes (e.g. "T" for token IDs, and "P" for public keys, etc.), so this allows a simple selection of "sub-groups" of a plugin. The `start` params is intended to allow a form of pagination; users can put the last group of the last query here to get the next page. (NB: They would need to lexicographically increment the last group item to get correct pagination, as `start` is inclusive.) Note that this changes how PluginMember is serialized (and therefore is a DB schema update), but since currently nobody is using the system, this is fine. The change is needed as postcard prefixes the length of the group, which makes it impossible to use for a prefix search. An example how this endpoint would be useful is for the Agora plugin: 1. It allows the user to get every token ID that has an offer in a paginated way, so they can have an overview what tokens even exists. 2. Then, when the user clicks on a token ID, the app queries all the offered UTXOs for this token ID and can display them. Depends on D16551.

The purpose of this endpoint is to allow users an easy way to explore the groups indexed by a plugin. Under normal usage, the API will be extremely fast, as it just slices exactly the requested info from the DB. This is because the way users query data is very close to how it's layed out in the DB. There's one edge case where adjacent groups with lots of UTXOs that are all spent in the mempool require a bigger DB scan, however, this will be resolved once the txs are mined, requires a big setup and only wastes (cached + batched) IO reads, so attacks are ineffective compared to costs. The `prefix` param is intended to make plugins prefix different kinds of groups with different prefixes (e.g. "T" for token IDs, and "P" for public keys, etc.), so this allows a simple selection of "sub-groups" of a plugin. The `start` params is intended to allow a form of pagination; users can put the last group of the last query here to get the next page. (NB: They would need to lexicographically increment the last group item to get correct pagination, as `start` is inclusive.) Note that this changes how PluginMember is serialized (and therefore is a DB schema update), but since currently nobody is using the system, this is fine. The change is needed as postcard prefixes the length of the group, which makes it impossible to use for a prefix search. An example how this endpoint would be useful is for the Agora plugin: 1. It allows the user to get every token ID that has an offer in a paginated way, so they can have an overview what tokens even exists. 2. Then, when the user clicks on a token ID, the app queries all the offered UTXOs for this token ID and can display them. Depends on D16551.

The purpose of this endpoint is to allow users an easy way to explore the groups indexed by a plugin. The APIs are designed to be extremely fastUnder normal usage, the API will be extremely fast, as it just slices exactly the requested info from the DB. This is because the way users query data is very close to how it's layed out in the DB. There's one edge case where adjacent groups with lots of UTXOs that are all spent in the mempool require a bigger DB scan, however, this will be resolved once the txs are mined, requires a big setup and only wastes (cached + batched) IO reads, by basically slicing exactly the requested info from the DB without having to search through the DB in any significant wayso attacks are ineffective compared to costs. The `prefix` param is intended to make plugins prefix different kinds of groups with different prefixes (e.g. "T" for token IDs, and "P" for public keys, etc.), so this allows a simple selection of "sub-groups" of a plugin. The `start` params is intended to allow a form of pagination; users can put the last group of the last query here to get the next page. (NB: They would need to lexicographically increment the last group item to get correct pagination, as `start` is inclusive.) Note that this changes how PluginMember is serialized (and therefore is a DB schema update), but since currently nobody is using the system, this is fine. The change is needed as postcard prefixes the length of the group, which makes it impossible to use for a prefix search. An example how this endpoint would be useful is for the Agora plugin: 1. It allows the user to get every token ID that has an offer in a paginated way, so they can have an overview what tokens even exists. 2. Then, when the user clicks on a token ID, the app queries all the offered UTXOs for this token ID and can display them. Depends on D16551.