Skip to content

Switch base-entity $id from HTTP URL to URN scheme #23

@mgoldsborough

Description

@mgoldsborough

Problem

The base entity schema declares its $id as:

https://upjack.dev/schemas/v1/upjack-entity.schema.json

and every app entity schema references it via allOf: [{$ref: "https://upjack.dev/..."}].

That URL is a name, not a location — there's no guarantee the schema is actually served there. But because the $id looks like an HTTP URL, every JSON-Schema-aware consumer (FastMCP, validators, third-party tools) is justified in trying to dereference it over the network. This caused the exact bug fixed in 0.5.0: tools/list was blocking for ~4s per activity-enabled server while FastMCP's serializer tried to fetch the URL.

The 0.5.0 fix inlines the $ref at load_schema time so library-internal flows never re-resolve. That's a workaround. The root cause is that we're using a URL as an identifier.

Proposal

Switch the base-entity $id and the canonical $ref target to a URN:

{
  "$id": "urn:upjack:schemas:v1:entity"
}

URNs are, by spec, non-dereferenceable — consumers can't accidentally try to HTTP-fetch them. Any tool that wants to resolve the schema has to bring its own local copy, which is exactly the contract Upjack ships anyway (bundled upjack-entity.schema.json).

Consequences

  • Breaking change to the published schema contract — existing app schemas reference the HTTPS URL.
  • Target 0.6.0.
  • Migration: app-schema authors update one string. The library continues to bundle the schema under the new \$id and auto-inline it at load time.
  • The load_schema / `_inline_base_entity_ref` machinery stays — same mechanism, different URI.
  • Follow-up: consider whether resolve_entity_schema helper (or a codemod in the app-builder skill) should help authors migrate.

Out of scope

  • Hosting the schema somewhere real (e.g., on schemas.nimblebrain.ai) — the whole point of this change is that the schema doesn't need to be hosted.
  • Generalizing to arbitrary $id URLs in user-authored schemas — those are the author's responsibility.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions