aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--posts/2022/atproto_good_for.md98
1 files changed, 98 insertions, 0 deletions
diff --git a/posts/2022/atproto_good_for.md b/posts/2022/atproto_good_for.md
new file mode 100644
index 0000000..1d9e3de
--- /dev/null
+++ b/posts/2022/atproto_good_for.md
@@ -0,0 +1,98 @@
+Title: What is atproto.com good for?
+Author: bnewbold
+Date: 2022-11-23
+Tags: tech, dweb
+Status: draft
+
+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),
+[adeonsine](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).