versia-pub/docs
2
0
Fork 0
mirror of https://github.com/versia-pub/docs.git synced 2025-12-06 06:18:19 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix: spelling

Browse source
This commit is contained in:
April John 2024-07-31 18:56:42 +00:00 committed by GitHub
parent 3059c20bd5
commit 902cf8fe92
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 6 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
app/federation/validation/page.mdx
View file

@ -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 **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 **all required headers**.
- The presence of a **valid signature**. - 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. - 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. - 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. - For example, a `size` field on a `ContentFormat` structure should be a positive integer, not a negative number or a floating-point number.
<Note> <Note>
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.
</Note> </Note>
- 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). - 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. 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.