Overview
This PR aims to introduce a new mechanic for matching service providers to claims. Service providers can now specify so-called markers which are used as additional tests before attempting to verify a claim. For now, markers are only HTTP endpoints and can only be tested for their existence — or lack of.
Rationale
Currently, when an identity claim is parsed, it is matched to candidate service providers before attempting to verify the claim. This matching is done solely based on the URI of the claim.
Some service providers are not ambiguous: IRC claims always start with irc:, lichess claims will always use the lichess.org domain.
Most service providers are ambiguous: https://domain.org/username/post could refer to a forem account, a forgejo/gitea account, an owncast instance...
Currently, doip-js simply attempts each of these service providers until one is able to verify the claim.
This worked fine until gitea was forked and forgejo was created. Due to their identical roots, both gitea and forgejo use the same verification mechanism and are thus indistinguishable from doip-js point of view.
Markers are one way of solving this issue. This PR adds a marker to the forgejo service provider that the gitea service provider does not have: the /api/forgejo/v1/version HTTP endpoint.
Note: for this to work, it is important that forgejo gets attempted BEFORE gitea, since gitea does not have a marker that forgejo does not have. doip-js does this.
Thanks to markers, doip-js will perfectly handle the following two scenarios.
Scenario 1: a forgejo claim is asked to be verified. It gets matched to both forgejo and gitea. Forgejo is attempted. doip-js finds that the /api/forgejo/v1/version endpoint exists and continues. It attempts the actual verification which succeeds. This claim is now a verified forgejo account.
Scenario 2: a gitea claim is asked to be verified. It gets matched to both forgejo and gitea. Forgejo is attempted. doip-js finds that the /api/forgejo/v1/version endpoint does not exist and skips forgejo. Gitea is attempted. It attempts the actual verification which succeeds. This claim is now a verified gitea account.
Note: in scenario 1, the gitea service provider is never even attempted, preventing this gitea verification — which would succeed! — to "confuse" doip-js.