diff --git a/README.org b/README.org index ae9df1f..4b76381 100644 --- a/README.org +++ b/README.org @@ -89,7 +89,7 @@ not specified: been rolled out onto the ActivityPub network. Compounding this situation is the general confusion/belief that -autorization must stem from authentication. +authorization must stem from authentication. This document aims to show that not only is this not true, it is also a dangerous assumption with unintended consequences. An alternative approach based on "object capabilities" is @@ -134,7 +134,7 @@ be people who cared about human rights and the needs of marginalized groups, and spam has been relatively minimal. [fn:json-ld] The technology that ActivityPub uses to accomplish this is - called [[https://json-ld.org/][json-ld]] and admittedly has been one of the most controvercial + called [[https://json-ld.org/][json-ld]] and admittedly has been one of the most controversial decisions in the ActivityPub specification. Most of the objections have surrounded the unavailability of json-ld libraries in some languages or the difficulty of mapping an open-world @@ -164,7 +164,7 @@ popular implementation of ActivityPub, and also largely responsible for driving interest in the protocol amongst other projects), its premise was semi-true; while it wasn't that there were no neo-nazis on the fediverse, the primary group which had driven recent adoption were -themselves marginalized groups who felt betrayed by ther larger +themselves marginalized groups who felt betrayed by the larger centralized social networks. They decided it was time for them to make homes for themselves. The article participated in an ongoing narrative that (from the @@ -184,7 +184,7 @@ from these groups. Even untargeted messages, such as general hate speech, may have a severe negative impact on one's well being. Spam, likewise, is an increasing topic of administrators and -implementors (as it has historically been for other federated social +implementers (as it has historically been for other federated social protocols, such as email/SMTP and OStatus during its heyday). It appears that the same nature of decentralized social networks in allowing marginalized communities to make communities for themselves @@ -259,7 +259,7 @@ hear them. What if we're focusing on breadth, when we really should be focusing on depth?" -- from a conversation with Evan Prodromou, initial designer of - both ActivityPub and OStatus' protcol designs + both ActivityPub and OStatus' protocol designs #+END_QUOTE What is Evan trying to say here? @@ -571,7 +571,7 @@ things that ACLs could never safely do... because [[http://waterken.sourceforge. When spam began to become a serious problem for email, Paul Graham wrote a famous essay called [[http://www.paulgraham.com/spam.html][A Plan for Spam]]. -The general idea was to use content filtering, specifically bayesian +The general idea was to use content filtering, specifically Bayesian algorithms, to detect spam. At the time of this article's release, this worked surprisingly well, with the delightful property that spammers' own messages would @@ -587,7 +587,7 @@ While most spam sent today is sent using what we might call "amateur" methods, possible sophisticated attacks are getting worse and worse. To add to this problem, false-negatives from these systems can be -disasterous. +disastrous. [[https://www.nytimes.com/2017/03/20/technology/youtube-lgbt-videos.html][YouTube has marked non-sexual LGBT+ videos as "sensitive"]], and many machine learning systems have been found to pick up [[https://www.propublica.org/article/machine-bias-risk-assessments-in-criminal-sentencing][racist assumptions]] from their surrounding environment @@ -664,7 +664,7 @@ In this case, if the message was nice, Alice might refund Bob one or both stamps. She might even decide to hand him the authority to send messages to her in the future, for free. -But say Bob is a spammer and is sending a viagra ad; Alice can keep +But say Bob is a spammer and is sending a Viagra ad; Alice can keep the stamps. Now Bob has to "pay" Alice to be spammed (and depending on how we decide to implement it, Alice might be able to keep this payment). @@ -694,12 +694,12 @@ knew how. We do not want to have to throw away the network we have. As such, this document does not try to solve all possible problems. For example, a Webfinger-centric interface is roughly incompatible -with Tor onion services, even if supporing such services would be +with Tor onion services, even if supporting such services would be desirable and could be more easily accomplished with a [[https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/making-dids-invisible-with-petnames.md][petname system]]. -(Imagine trying to complete the webfinger address of a user that +(Imagine trying to complete the Webfinger address of a user that is using a v3 tor onion service address!) As such, this document simply assumes the possibility that we will -live with webfinger-based addresses for now, even if not optimal for +live with Webfinger-based addresses for now, even if not optimal for the long term. Incremental improvement is better than no improvement at all, and @@ -719,7 +719,7 @@ there is a lot we can make better. ** Rights amplification and group-style permissions -** multiBox vs sharedInbox +** MultiBox vs sharedInbox * Limitations