ActivityPub, as it exists and is deployed, is not sufficient. Its basis
might be a start. In some ways, Project Liberty, to the extent I've
read it, also extends from its ideas (it does borrow from the same
ActivityStreams vocabulary and has clearly read the AP spec), but I'll
boldly say: in the wrong direction. OcapPub explains some degree of the
amount things should go.
For one thing, Figure 1 shows an ACL. So, observe that first. ;)
The problem is that Project Liberty misunderstands the solution
involving *embracing local contexts*. More below.
jack mills writes:
> another example of the (free) market responding to the censorship of the
> existing centralized social networks:
> because said censorship is possible due to the fact that these are
> centralized systems, the obvious alternative to explore is decentralization
> (personally, i consider "decentralized" to be a superset of "blockchain"
> but those two concepts are frequently conflated).
See the part about blockchains as decentralized centralization:
But really, that's being a bit smarmy to shake people out of their
current zeitgeist'y assumptions. Better put, a blockchain is "a
decentralized machine"... but really, a *single* machine. But, from an
eg CapTP perspective, it's still a single machine.
Here are some questions that might help figure out why Project Liberty
has done things wrong:
- What if email were on a blockchain? I run my own email server. Do I
need all emails sent over SMTP from every machine on the system? Is
that really the best way to scale? (Hint: it would mean I can't
- Why does a follow graph need to be public?
- Why do people behave differently in different communities, and how
might we choose to design our systems to *accomodate* this?
In a sesne, most of the systems trying to do better than ActivityPub are
making a key mistake: they're still heavily influenced by a centralized
vision. Blockchains provide what appear to be an easy path to that,
with a "decentralized centralization" approach.
I believe blockchains can provide valuable nodes on the system, but we
interepret them as just single-machines abstractly spread out across
many... not the part that provides decentralization itself. I'll make
the following assertion: the *properly decentralized* social network
system could have even been done on *E's* CapTP. And that's actually a
better set of assumptions to start with... including for effects on
community health. Even if you involve blockchains!
So, I think it's done wrong. Nice to see my name show up in the
citations though ;)
Been working hard (with Randy Farmer's help, thanks Randy!) on an
alternative vision though, which does recognize the importance of
a context-centric approach. Hopefully more to say soon.