an alternative to ActivityPub for decentralized social networks?
11 views
Skip to first unread message
jack mills
Jul 1, 2021, 7:00:18 AM7/1/21
to friam
another example of the (free) market responding to the censorship of the existing centralized social networks: https://cointelegraph.com/news/former-la-dodgers-owner-earmarks-100m-for-blockchain-based-social-media
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).
this will be based on a new protocol similar to ActivityPub called the Decentralized Social Networking Protocol (DSNP): https://unfinished.com/wp-content/uploads/dsnp_whitepaper.pdf
DSNP also addresses identity, authentication, and security.
jack
Chris Lemmer-Webber
Jul 1, 2021, 3:55:15 PM7/1/21
to fr...@googlegroups.com, jack mills
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:
> https://cointelegraph.com/news/former-la-dodgers-owner-earmarks-100m-for-blockchain-based-social-media
>
> 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:
https://dustycloud.org/blog/what-is-a-blockchain-really/
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
participate!)
- 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.
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:
> https://cointelegraph.com/news/former-la-dodgers-owner-earmarks-100m-for-blockchain-based-social-media
>
> 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).
https://dustycloud.org/blog/what-is-a-blockchain-really/
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
participate!)
- 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.
Christoph Dorn
Jul 2, 2021, 2:40:32 PM7/2/21
to fr...@googlegroups.com, Chris Lemmer-Webber, jack mills
On 2021-07-01 12:55 p.m., Chris Lemmer-Webber wrote:
> ...
nightmare and large GB size blockchains are not practical. You don't
want to have to rely on third party full nodes.
Blockchains ought to record "references" for introductions to groups of
entities held in distributed data stores (like Citadels). Blockchains
solve the decentralized centralized discovery problem which is essential
to finding trusted new content outside of your existing network.
Blockchains: periodic registry topic announcements -> Citadels (
Registries: topic-specific content reference ledgers with previews ->
Stores: actual content)
You can layer whatever protocols and privacy controls you want on top of
this as actual content can be selectively disclosed and identify
obfuscated. Good reasons to choose specific Citadels and protocols to
distribute your content.
It requires a lot more work than just to dump things on a blockchain.
Even if the technical problem is solved you have to win the PR battle
from a position that goes against the current aggregating user data is
gold paradigm.
Christoph
> ...
> 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.
100%. Putting "data" on blockchains is too easy. It is a privacy
> 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.
nightmare and large GB size blockchains are not practical. You don't
want to have to rely on third party full nodes.
Blockchains ought to record "references" for introductions to groups of
entities held in distributed data stores (like Citadels). Blockchains
solve the decentralized centralized discovery problem which is essential
to finding trusted new content outside of your existing network.
Blockchains: periodic registry topic announcements -> Citadels (
Registries: topic-specific content reference ledgers with previews ->
Stores: actual content)
You can layer whatever protocols and privacy controls you want on top of
this as actual content can be selectively disclosed and identify
obfuscated. Good reasons to choose specific Citadels and protocols to
distribute your content.
It requires a lot more work than just to dump things on a blockchain.
Even if the technical problem is solved you have to win the PR battle
from a position that goes against the current aggregating user data is
gold paradigm.
Christoph
Reply all
Reply to author
Forward
0 new messages