diff options
Diffstat (limited to 'posts/2022/atproto_good_for.md')
| -rw-r--r-- | posts/2022/atproto_good_for.md | 98 |
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). |