Adopt validateChallengeSettings and update to the latest pkc-js

[Rinse12]

What changed in pkc-js

pkc-js now validates community.settings.challenges[i] in two layers, on the edit, community-creation and start paths. Merged in pkcprotocol/pkc-js#288 (commit d9028724e), shipping in the first release after v0.0.84.

Layer 1, core, no challenge code involved. options and publicOptions are checked against the optionInputs your ChallengeFileFactory returns:

Check	Error code
An options key that no optionInputs entry declares	ERR_CHALLENGE_OPTION_NOT_DECLARED_IN_OPTION_INPUTS
A missing option whose optionInputs entry has required: true	ERR_CHALLENGE_REQUIRED_OPTION_MISSING
A publicOptions entry that no optionInputs entry declares	ERR_CHALLENGE_PUBLIC_OPTION_NOT_DECLARED_IN_OPTION_INPUTS

Layer 2, the new optional validateChallengeSettings hook, for semantic checks only this package can make:

validateChallengeSettings?: (args: { challengeSettings: CommunityChallengeSetting }) => void

• Optional. Omit it if there is nothing semantic to check.
• Sync, and no network. It runs on every community start, so an async validator hitting a third party would turn that outage into a startup problem.
• Rejection is a throw of anything, including a plain new Error("..."). No pkc-js import needed. Core wraps it with code ERR_CHALLENGE_SETTINGS_VALIDATION_FAILED, keeping the original as cause and your message in details.validationError.
• Keep the factory itself cheap and non-throwing: it runs on load as well as on edit, so a throwing factory fails community startup rather than the offending edit.

Full guide: docs/protocol/challenge-authoring.md

What this package needs

@bitsocial/flags-challenge currently pins @pkcprotocol/pkc-js at 0.0.37.

No option in src/schema.ts is marked required: true. Core's new required check therefore does nothing for this package until you declare it. serviceUrl and issuer look like genuine requirements.

Suggested validateChallengeSettings checks:

• serviceUrl parses with new URL() and uses http: or https:. A malformed URL here means every author is rejected by a service that was never reachable.
• allowedFlags parses into the list shape the challenge expects, and is non-empty if an empty list would reject everyone.
• emitFlair is a boolean string.
• namespace and profile match whatever format the issuer service requires.

Do not call serviceUrl from the hook to check reachability; that belongs in getChallenge().

Worth considering: publicOptions

pkc-js also gained owner-controlled publicOptions (pkcprotocol/pkc-js#287), letting a community owner publish named options into the community record. If a client needs to read allowedFlags to produce a publishable comment, this challenge is a candidate for requiring that option to be listed in publicOptions, throwing from the hook when it is not. Unpublished rules mean authors are rejected by a rule they cannot see.

Tasks

• Bump @pkcprotocol/pkc-js to the release named above
• Mark the genuinely required options with required: true
• Add validateChallengeSettings covering the checks above
• Decide whether any option must be published via publicOptions
• Add tests for each rejection

[Rinse12]

This shipped in @pkcprotocol/pkc-js@0.0.85 (released 2026-08-21), so "the first release after v0.0.84" above means 0.0.85 or later.

Release notes, including the upgrade note for community owners: https://github.com/pkcprotocol/pkc-js/releases/tag/v0.0.85