From f30f862e7ebd1315bd87fc87f03aff7608b6d386 Mon Sep 17 00:00:00 2001 From: Ajay Gonepuri Date: Sun, 29 Oct 2023 09:21:32 +0530 Subject: [PATCH] docs: fix typos --- CHANGELOG.md | 4 ++-- draft/aeap-mvp.md | 2 +- spec.md | 4 ++-- webxdc.md | 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 41278af1b3..47220c9887 100644 --- a/CHANGELOG.md +++ b/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 diff --git a/draft/aeap-mvp.md b/draft/aeap-mvp.md index 040125f57a..12233c0072 100644 --- a/draft/aeap-mvp.md +++ b/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. diff --git a/spec.md b/spec.md index ea34862aac..1b86a2c12a 100644 --- a/spec.md +++ b/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. diff --git a/webxdc.md b/webxdc.md index bc35398f0c..34c9de2dfc 100644 --- a/webxdc.md +++ b/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.