docs: fix typos

CHANGELOG.md

@@ -1078,7 +1078,7 @@ Bugfix release attempting to fix the [iOS build error](https://github.com/deltac
 
 ### Changes
 - Look at Authentication-Results. Don't accept Autocrypt key changes
-  if they come with negative authentiation results while this contact
+  if they come with negative authentication results while this contact
   sent emails with positive authentication results in the past. #3583
 - jsonrpc in cffi also sends events now #3662
 - jsonrpc: new format for events and better typescript autocompletion
@@ -2664,7 +2664,7 @@ Bugfix release attempting to fix the [iOS build error](https://github.com/deltac
 
 - delete all consumed secure-join handshake messagess #1209 #1212
 
-- rust-level cleanups #1218 #1217 #1210 #1205
+- Rust-level cleanups #1218 #1217 #1210 #1205
 
 - python-level cleanups #1204 #1202 #1201
 

draft/aeap-mvp.md

@@ -57,7 +57,7 @@ Note that usually a mail is signed by a key that has a UID matching the from add
 ### Notes:
   
 - We treat protected and non-protected chats the same
-- We leave the aeap transition statement away since it seems not to be needed, makes things harder on the sending side, wastes some network traffic, and is worse for privacy (since more pepole know what old addresses you had).
+- We leave the aeap transition statement away since it seems not to be needed, makes things harder on the sending side, wastes some network traffic, and is worse for privacy (since more people know what old addresses you had).
 - As soon as we encrypt read receipts, sending a read receipt will be enough to tell a lot of people that you transitioned
 - AEAP will make the problem of inconsistent group state worse, both because it doesn't work if the message is unencrypted (even if the design allowed it, it would be problematic security-wise) and because some chat partners may have gotten the transition and some not. We should do something against this at some point in the future, like asking the user whether they want to add/remove the members to restore consistent group state.
 

spec.md

@@ -192,7 +192,7 @@ in different orders, esp. on creating new groups.
 To remove a member, a `Chat-Group-Member-Removed` header must be sent
 with the value set to the email-address of the member to remove.
 When receiving a `Chat-Group-Member-Removed` header,
-only exaxtly the given member has to be removed from the member list.
+only exactly the given member has to be removed from the member list.
 
 Messenger clients MUST NOT construct the member list
 on other group messages
@@ -339,7 +339,7 @@ only on image changes.
 
 In older specs, the profile-image was sent as an attachment
 and `Chat-User-Avatar:` specified its name.
-However, it turned out that these attachments are kind of unuexpected to users,
+However, it turned out that these attachments are kind of unexpected to users,
 therefore the profile-image go to the header now.
 
 

webxdc.md

@@ -38,11 +38,11 @@ While this describes an already working "proof of concept" usage there are alrea
 
 webxdc empowers FOSS developments in unprecedented ways: 
 
-- well-known paradim: use all the existing JS/html5 libraries and designs of your choice
+- well-known paradigm: use all the existing JS/html5 libraries and designs of your choice
 - quick onboarding: only a handful API methods to learn 
 - serverless (but really): no worrying about hosting a server or configuring DNS, AWS etc 
 - permissionless: no worrying about registering at app stores for distribution
-- unbuerocratic: no worrying about login/password/expiry procedures or leaks 
+- unbureaucratic: no worrying about login/password/expiry procedures or leaks 
 - secure: no worrying about cryptographic algos or e2e-encryption complexity
 
 On the flip side, you need to learn how to do state updates between instances of your webxdc apps. This is a classic P2P problem and there are simple (send full state update) and advanced ways (use CRDTs or similar) to arrange decentralized state. In any case, there is no DHT let alone blockchain needed and thus no Crypto or coin needed, either.