Fix spelling mistakes

buds/01.md

@@ -28,7 +28,7 @@ Authorization events must be generic and must NOT be scoped to specific servers.
 
 Events MUST be kind `24242` and have a `t` tag with a verb of `get`, `upload`, `list`, or `delete`
 
-Events MUST have the `content` set to a human readable string explaining to the user what the events inteded use is. For example `Upload Blob`, `Delete dog-picture.png`, `List Images`, etc
+Events MUST have the `content` set to a human readable string explaining to the user what the events intended use is. For example `Upload Blob`, `Delete dog-picture.png`, `List Images`, etc
 
 All events MUST have a [NIP-40](https://github.com/nostr-protocol/nips/blob/master/40.md) `expiration` tag set to a unix timestamp at which the event should be considered expired.
 

buds/03.md

@@ -68,7 +68,7 @@ Take the following event as an example
 
 Once the client discovers that the URL `https://cdn.broken-domain.com/b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553.pdf` is no longer available. It can perform the following steps to find the blob:
 
-1. Get the SHA256 has from the URL
+1. Get the SHA256 hash from the URL
 2. Look for the authors server list `kind:10063`
 3. If found, Attempt to retrieve the blob from each `server` listed started with the first
 4. If not found, the client MAY fallback to using a well-known popular blossom server to retrieve the blob

buds/05.md

@@ -20,7 +20,7 @@ Servers MAY reject media uploads for any reason and should respond with the appr
 
 Servers MAY require a `media` [authorization event](./02.md#upload-authorization-required) to identify the uploader
 
-If a server requires a `media` authorization event it MUST preform the following checks
+If a server requires a `media` authorization event it MUST perform the following checks
 
 1. The `t` tag MUST be set to `media`
 2. MUST contain at least one `x` tag matching the sha256 hash of the body of the request
@@ -33,7 +33,7 @@ Servers MUST respond to `HEAD` requests on the `/media` endpoint in a similar wa
 
 This endpoint is intentionally limited to optimizing a single blob with the goal of making it easier to distribute
 
-How the blob is optimized is the sole respirability of the server and the client should have no say in what optimization process is used
+How the blob is optimized is the sole responsibility of the server and the client should have no say in what optimization process is used
 
 The goal of this endpoint is to provide a simple "trusted" optimization endpoint clients can use to optimize media for distribution
 

buds/06.md

@@ -8,7 +8,7 @@ Defines how clients can verify if the upload can be completed before sending the
 
 ## HEAD /upload - Upload requirements
 
-The `HEAD /upload` endpoint `MUST` use the `X-SHA-256`, `X-Content-Type` and `X-Content-Length` headers sent by client to get the SHA-256 hash, MIME type and size of the blob that will be uploaded, returning a HTTP status code and a custom header `X-Reason` to indicate some human readable message about the upload requirements.
+The `HEAD /upload` endpoint MUST use the `X-SHA-256`, `X-Content-Type` and `X-Content-Length` headers sent by client to get the SHA-256 hash, MIME type and size of the blob that will be uploaded, returning a HTTP status code and a custom header `X-Reason` to indicate some human readable message about the upload requirements.
 
 ### Headers
 
@@ -38,7 +38,7 @@ Example response from the server if the upload can be done:
 HTTP/1.1 200 OK
 ```
 
-If the upload cannot proceed, the server `MUST` return an appropriate `4xx` HTTP status code and a custom header `X-Reason` with a human readable error message.
+If the upload cannot proceed, the server MUST return an appropriate `4xx` HTTP status code and a custom header `X-Reason` with a human readable error message.
 
 Some examples of error messages:
 

buds/09.md

@@ -35,7 +35,7 @@ The clients can show a blob report button on posts or in blob details. Or its RE
 
 ### Server behavior
 
-The servers MAY keep the reports somewhere for operators to check and take action on them. they MAY use a list of trusted people or moderators to directly take action on blob without operator request. 
+The servers MAY keep the reports somewhere for operators to check and take action on them. they MAY use a list of trusted people or moderators to directly take action on blob without operator request.
 
 Servers MAY consider removed blobs sha256 as blocked to prevent rewrite.
-Servers SHOULD advertise a route or landing page to provide their rules and term of service which affects the report process.
+Servers SHOULD advertise a route or landing page to provide their rules and terms of service which affects the report process.