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