Validation

Implementations MUST strictly validate all incoming data to ensure that it is well-formed and adheres to the Versia Protocol. If a request is invalid, the instance MUST return a 400 Bad Request HTTP status code.

Things that should be validated include, but are not limited to:

  • The presence of all required fields.
  • The format of all fields (integers should not be strings, dates should be in ISO 8601 format, etc.).
  • The presence of all required headers.
  • The presence of a valid signature.
  • The length of all fields (for example, the username field on a User entity) should be at least 1 character long.
    • Do not set arbitrary limits on the length of fields that other instances may send you. For example, a bio field should not be limited to 160 characters, even if your own implementation has such a limit.
    • If you do set limits, they should be reasonable, well-documented and should allow Users to easily view the remote original, by, for example, linking to it.
  • The type, precision and scale of all numeric fields.
    • For example, a size field on a ContentFormat structure should be a positive integer, not a negative number or a floating-point number.
  • The validity of all URLs and URIs (run them through your favorite URL parser, optionally fetch the linked URL).
  • The time of all dates and times (people should not be born in the future, or in the year 0).

It is your implementation's duty to reject data from other instances that does not adhere to the strict spec. This is crucial to ensure the integrity of your instance and the network as a whole. Allowing data that is technically valid but semantically incorrect can lead to the degradation of the entire Versia ecosystem.