commit: 0b700795c130bf7d1ec131483b54e125232e96f6
parent dc6eeb2288dd2f07b468dd7f694fa66ac309da43
Author: Drew DeVault <sir@cmpwn.com>
Date: Wed, 7 Apr 2021 12:03:21 -0400
More typos
How does english even work
Diffstat:
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/content/blog/The-next-chat-app.gmi b/content/blog/The-next-chat-app.gmi
@@ -6,7 +6,7 @@ Crucially, that protocol must be federated. This is Signal’s largest failure.
The next chat app also needs end-to-end encryption. This should be fairly obvious, but it’s worth re-iterating because this will occupy a majority of the design work that goes into the app. There are complex semantics involved in encrypting user-to-user chats, group chats (which could add or remove users at any time), perfect forward secrecy, or multiple devices under one account; many of these issues have implications for the user experience. This is complicated further by the concerns of a federated design, and if you want to support voice or video chat (please don’t), that’ll complicate things even more. You’ll spend the bulk of your time solving these problems. I would advise, however, that you let users dial down the privacy (after explaining to them the trade-offs) in exchange for convenience. For instance, to replace IRC you would need to support channels which anyone can join at any time and which might make chat logs available to the public.
-A new chat app also needs anonymity. None of this nonsense where users have to install your app and give you their phone number to register. In fact, you should know next to nothing about each user, given that the most secure data is the data you don’t have. This is made more difficult when you consider that you’ll also strive to provide an authentic identity for users to establish between themselves — but not with you. Users should also be able to establish a pseudonymous identity, or wear multiple identities. You need to provide (1) a strong guarantee of consistent identity from session to session, (2) without sharing that guarantee with your servers, and (3) offering the ability to able to change to a new identity at will. The full implications of anonymity are a complex issue which is out of scope for this article, but for now it suffices to say that you should at refrain from asking for the user’s phone number.
+A new chat app also needs anonymity. None of this nonsense where users have to install your app and give you their phone number to register. In fact, you should know next to nothing about each user, given that the most secure data is the data you don’t have. This is made more difficult when you consider that you’ll also strive to provide an authentic identity for users to establish between themselves — but not with you. Users should also be able to establish a pseudonymous identity, or wear multiple identities. You need to provide (1) a strong guarantee of consistent identity from session to session, (2) without sharing that guarantee with your servers, and (3) offer the ability to able to change to a new identity at will. The full implications of anonymity are a complex issue which is out of scope for this article, but for now it suffices to say that you should at least refrain from asking for the user’s phone number.
Finally, it needs to be robust, reliable, and performant. Focus on the basics: delivering messages quickly and reliably. The first thing you need to produce is a reliable messenger which works in a variety of situations, on a variety of platforms, in various network conditions, and so on, with the underlying concerns of federation, end-to-end encryption, protocol standardization, group and individual chats, multi-device support, and so on, in place and working. You can try to deliver this in a moderately attractive interface, but sinking a lot of time into fancy animations, stickers, GIF lookups, typing notifications and read receipts — all of this is a distraction until you get the real work done. You can have all of these things, but if you don’t have a reliable system underlying them, the result is worthless.
diff --git a/content/blog/The-next-chat-app.md b/content/blog/The-next-chat-app.md
@@ -64,11 +64,11 @@ you'll also strive to provide an authentic identity for users to establish
between themselves — but not with you. Users should also be able to
establish a pseudonymous identity, or wear multiple identities. You need to
provide (1) a strong guarantee of consistent identity from session to
-session, (2) without sharing that guarantee with your servers, and (3) offering
+session, (2) without sharing that guarantee with your servers, and (3) offer
the ability to able to change to a new identity at will. The full implications
of anonymity are a complex issue which is out of scope for this article, but for
-now it suffices to say that you should at refrain from asking for the user's
-phone number.
+now it suffices to say that you should at least refrain from asking for the
+user's phone number.
Finally, it needs to be **robust, reliable, and performant**. Focus on the
basics: delivering messages quickly and reliably. The first thing you need to
