-
Notifications
You must be signed in to change notification settings - Fork 2
Description
In Curate V1 - V2, list creators can currently add custom fields (long text, short text, number, image, etc.), but cannot create a field where users choose from predefined options (e.g., a dropdown/select field).
The proposal is to introduce a new “Select” field type on the frontend side only, without modifying the metaevidence structure.
Once the field is added to the list, if a user submits an item directly via the smart contract (bypassing the frontend) and doesn’t follow the intended options, it is their responsibility and could be challenged (according to the policy).
The list creator can choose whether to define the subset of allowed options in the policy. If defined, jurors can use it to verify compliance in case of a challenge.
Filter Feature
This change also connects with issue #83: Once the list is deployed, these select fields could automatically become filters, simplifying navigation and improving usability.
In alternative, the list creator could have a frontend option to decide whether a specific select field should be available as a filter or not.
Context and Comparison
In Curate V1, the only partially similar element is the “Rich Address” field. But the options(chains) are manually maintained by Kleros team and rely on third-party services (block explorers). Moreover, user has no flexibility in case they want to add other chains.
Additional Notes
- We may limit the number options per "select" field to keep the UI lightweight.
- Adding a few common field templates (e.g., “Date,” “Year”) would help anticipate frequent requests and reduce one-off implementations.