From 902cf8fe924f13cb66ece8e0cf983454fd49bf8d Mon Sep 17 00:00:00 2001 From: April John <30842467+CutestNekoAqua@users.noreply.github.com> Date: Wed, 31 Jul 2024 18:56:42 +0000 Subject: [PATCH] fix: spelling --- app/federation/validation/page.mdx | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/app/federation/validation/page.mdx b/app/federation/validation/page.mdx index 77ea277..e9c4ac2 100644 --- a/app/federation/validation/page.mdx +++ b/app/federation/validation/page.mdx @@ -20,15 +20,16 @@ Things that should be validated include, but are not limited to: - 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). +- 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 and well-documented. + - 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. - All numeric fields in these docs have the appropriate precision (`u64`, `i64`, `f32`, etc.) specified. Do not use a different type in memory than the one specified in the docs. + Best practice is to store a `size` internally as a unsigned int. + All numeric fields in these docs have the appropriate precision (`u64`, `i64`, `f32`, etc.) specified. Thumb rule: Do not use a different type in memory than the one specified in the docs. Exception to that rule: using the same type with a higher bit count, for example using a u128 instead of a u64. Beware of performance impacts this may cause. -- The **validity** of all URLs and URIs (run them through your favorite URL parser). +- 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 Lysand ecosystem. \ No newline at end of file +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 Lysand ecosystem.