1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
Title: What is atproto.com good for?
Author: bnewbold
Date: 2022-11-23
Tags: tech, dweb
Bluesky released early documentation for the ["AT
Protocol"](https://atproto.com) (atproto) a few weeks ago, and I've been
noodling around with it. Technically, it strikes an appealing balance between
rigid cryptographically-signed content-addressable storage on the one hand, and
familiar web-friendly schemas and integrations on the other. But at an
ecosystem level, there are already a bunch of existing open social media
projects. Does atproto bring anything interesting to the table? How might it fit
in compared to other similar protocols?
First, as quick background, atproto is a dweb social media protocol which
aspires to replace Twitter as a centralized platform. Bluesky, the organization
developing it, is a small company with history intertwingled with Jack Dorsey
and Twitter itself. The folks there also have ties to more established dweb
tech projects like IPFS, Scuttlebutt, and dat.
What sets atproto apart from other dweb and fediverse projects is that it is
explicitly trying to support some of the “big world” features of Twitter. This
means global discovery and “leaderboard” metrics (“likes”, “followers”), and
also means “broadcast” content that gets rapidly replicated to millions
(billions?) of users. It also supports, to some degree, the ability to
redistribute and discuss pieces of content outside of their original context
(“context collapse”).
I myself mostly dislike these properties for social media, but I do think they
have positive social value in some cases. For example, short-form official
announcements (eg, local weather warnings, flash flood alerts, public transit
disruption), or short-form journalism (eg, as live blogging breaking events).
I do not have a Twitter account, but some of the use cases that I personally
still end up going there for today include local breaking news (what is that smoke
cloud in my city, what is happening at a protest); seeing what “anybody” is
saying about a project (eg, search by project name or domain name); checking if
people or institutions are A Thing (what do they say in public feed, who is
interacting with them); and generally what individual people or institutions
are up to. These are all "big world" use cases that can't be met by the circle
of folks a couple social hops from me.
It does feel to me that some these use-cases were well served by older web and
indieweb tech, like (micro)blogs and RSS. Especially for the last case (“what
are people up to”), which depending on the person may best be found on a
homepage or blog. Maybe if social platforms were more open and had better
sitemap tech then generic search engines could provide the big world features?
But many current dweb/fediverse projects try to specifically steer away from
“big world” aggregations, and instead focus on “small world” in-community
discussion. They do provide the technical ability to engage across communities
and with the broader public. But I suspect many want to avoid rapid
aggregation, leaderboards, and global discovery.
My take is that atproto should explicitly double-down on these use cases,
because others are not. The project should also try to support existing
(indie)web protocols like RSS and (possibly) ActivityPub. I don’t think they
should directly try to support private messaging (leave that to Signal and
Matrix, maybe with some identity/contact level interop), or forum-like
small-world discussion with community-level norms (leave that to Discourse for
web-index-able stuff, or SSB, or Mastodon).
Speaking of ActivityPub, I see two main contrasts against atproto. The first is
that atproto specifies how user content should be canonically **stored**, while
ActivityPub specifies **event notifications** between servers. An analogy is
that ActivityPub is more like RSS (in which content may be truncated or
otherwise non-canonical in an RSS feed) matter much), while atproto is more
like a git repo (original content is transferred in canonical form; there is
some awkwardness about large blobs/media). I think the atproto way makes it
easier for an ecosystem to be interoperable in the long run, reduces the stress
and obligations of hosting content on servers (because it is easy to backup and
migrate), and empowers individual users. The other big contrast is
full-strength account migration support in atproto, which works even without
any participation by former hosting providers.
This last feature, building on [decentralized identifiers
(DIDs)](https://en.wikipedia.org/wiki/Decentralized_identifier), is in my view
the least mature and riskiest part of the currently proposed system. DID is a
W3C specification, but really feels like it comes from the blockchain/web3
world. did:web does exist and should work fine, but itself is a big nothing
burger because it does not enable the interesting account migration features
that a true DID would. It should be possible to implement something like
[Certificate
Transparency](https://en.wikipedia.org/wiki/Certificate_Transparency) to do
global-trusted and rapidly resolvable DIDs without wasteful proof-of-whatever,
but that would require an effort and institution like Let’s Encrypt did for SSL
certificates. It is unclear if or when that might actually happen. As it stands
today DID has a pile of good intentions and standardization scaffolding, but in
reality is just blockchain and vaporware.
---
As part of noodling around with the protocol, I wrote a simple partial
command-line tool and personal data server (PDS),
[adenosine](https://gitlab.com/bnewbold/adenosine). You can check out the
minimal web interface at the examples
[pierre-manard.robocracy.org](https://pierre-manard.robocracy.org) and
[voltaire.demo.adenosine.social](https://voltaire.demo.adenosine.social).
|
