mirror of
https://gitlab.com/spritely/ocappub.git
synced 2024-12-26 13:49:48 +00:00
spel chekcing
This commit is contained in:
parent
17d5918f8b
commit
82e0945f63
24
README.org
24
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
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user