







This essay outlines a set of capabilities and goals comprising decent social computing and then establishes a framework for assessing how well an ecosystem’s identity system supports those goals and capabilities.
Community by Design
Social media empower distributed content creation by algorithmically harnessing "the social fabric" (explicit and implicit signals of association) to serve this content. While this overcomes the bottlenecks and biases of traditional gatekeepers, many believe it has unsustainably eroded the very social fabric it depends on by maximizing engagement for advertising revenue. This paper participates in open and ongoing considerations to translate social and political values and conventions, specifically social cohesion, into platform design. We propose an alternative platform model that includes the social fabric an explicit output as well as input. Citizens are members of communities defined by explicit affiliation or clusters of shared attitudes. Both have internal divisions, as citizens are members of intersecting communities, which are themselves internally diverse. Each is understood to value content that bridge (viz. achieve consensus across) and balance (viz. represent fairly) this internal diversity, consistent with the principles of the Hutchins Commission (1947). Content is labeled with social provenance, indicating for which community or citizen it is bridging or balancing. Subscription payments allow citizens and communities to increase the algorithmic weight on the content they value in the content serving algorithm. Advertisers may, with consent of citizen or community counterparties, target them in exchange for payment or increase in that party's algorithmic weight. Underserved and emerging communities and citizens are optimally subsidized/supported to develop into paying participants. Content creators and communities that curate content are rewarded for their contributions with algorithmic weight and/or revenue. We discuss applications to productivity (e.g. LinkedIn), political (e.g. X), and cultural (e.g. TikTok) platforms.

Identity Systems Don’t Make Decisions - Spherical Cow Consulting
Identity systems don’t make decisions,your architecture does. Why distributed decision-making creates inconsistency and risk in modern IAM.

Modular Politics: Toward a Governance Layer for Online Communities
Governance in online communities is an increasingly high-stakes challenge, and yet many basic features of offline governance legacies--juries, political parties, term limits, and formal debates, to name a few--are not in the feature-sets of the software most community platforms use. Drawing on the paradigm of Institutional Analysis and Development, this paper proposes a strategy for addressing this lapse by specifying basic features of a generalizable paradigm for online governance called Modular Politics. Whereas classical governance typologies tend to present a choice among wholesale ideologies, such as democracy or oligarchy, Modular Politics would enable platform operators and their users to build bottom-up governance processes from computational components that are modular and composable, highly versatile in their expressiveness, portable from one context to another, and interoperable across platforms. This kind of approach could implement pre-digital governance systems as well as accelerate innovation in uniquely digital techniques. As diverse communities share and connect their components and data, governance could occur through a ubiquitous network layer. To that end, this paper proposes the development of an open standard for networked governance.

Exploring Identities in the AT Protocol via Bluesky
The AT Protocol is an open, decentralized network for building social applications. Bluesky, a relatively new social network, is built on top of the AT Protocol. It recently piqued my interest as I came across this fascinating research paper Bluesky and the AT Protocol: Usable Decentralized Social Media. In this post, we’ll dive into one of the key elements of the AT Protocol: identities. We will start with Bluesky user handles, explore additional information about them, and see what else we can discover. DID Resolution A handle in Bluesky is associated with a DID, which can be resolved using DNS or HTTPS. decentralized identifier (DID) A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. […] Many—but not all—DID methods make use of distributed ledger technology (DLT) or some other form of decentralized network. From Decentralized Identifiers (DIDs) v1.0 The DID for @jay.bsky.team can be resolved via a DNS record. Example with dig: > dig _atproto.jay.bsky.team TXT [...] _atproto.jay.bsky.team. 14400 IN TXT "did=did:plc:oky5czdrnfjpqslsw2a5iclo" If you don’t have dig installed, try an online tool like nslookup.io. If no DNS TXT entry exists, the handle may resolve to a DID through a well-known HTTPS endpoint. Let’s take the example of @jamesgunn.bsky.social: > curl https://jamesgunn.bsky.social/.well-known/atproto-did did:plc:lotavzt36yanhfy3j3gpysyj If you don’t have curl installed, you can just open the link in your browser https://jamesgunn.bsky.social/.well-known/atproto-did. PLC Once you have a DID, examine the part after the first colon. This is known as the method. The above two examples use plc, which stands for Public Ledger of Credentials. These PLC DIDs can be looked up in the PLC directory at plc.directory. The AT Protocol also supports the web method, though we focus on plc here. We can use curl again to get more information about a DID. Let’s take @jay.bsky.team’s DID as example. > curl https://plc.directory/did:plc:oky5czdrnfjpqslsw2a5iclo/log | jq [ { "sig": "KuN3A61golVNSDU71wZKLP9lVuXk6YekJAz1lwDzrPsNTEWHBBW_8zSyV6pDxV4KiYXuAXlS1Ik47XkjQZ94mA", "prev": null, "type": "create", "handle": "jay.bsky.social", "service": "https://bsky.social", "signingKey": "did:key:zQ3shP5TBe1sQfSttXty15FAEHV1DZgcxRZNxvEWnPfLFwLxJ", "recoveryKey": "did:key:zQ3shhCGUqDKjStzuDxPkTxN6ujddP4RkEKJJouJGRRkaLGbg" }, { "sig": "TY3ot8yFF-0LL8ceoRwSGaNQj0F1aj-IApYXRGT21G1fnznKHUHT1QE7c1aTrYd9PQLVvXUGag6CZ9EEeIKqgA", "prev": "bafyreidswhiwi4ljkl4es4vwqhkas3spmmktortqbp6lkrb5v7qqdfr3mm", "type": "plc_operation", "services": { "atproto_pds": { "type": "AtprotoPersonalDataServer", "endpoint": "https://bsky.social" } }, "alsoKnownAs": [ "at://jay.bsky.social" ], "rotationKeys": [ "did:key:zQ3shhCGUqDKjStzuDxPkTxN6ujddP4RkEKJJouJGRRkaLGbg", "did:key:zQ3shpKnbdPx3g3CmPf5cRVTPe1HtSwVn5ish3wSnDPQCbLJK" ], "verificationMethods": { "atproto": "did:key:zQ3shXjHeiBuRCKmM36cuYnm7YEMzhGnCmCyW92sRJ9pribSF" } }, { "sig": "WmQmobHA6abtu8xIkBSrDkkoMNjOxP1Tl_1zl1DbIZlA9kjOyxjX-J1rzwWVy3stdzMowpBeBnedkAug84n_RQ", "prev": "bafyreicgb25yf5fro22oyhtkbgerzr4nume4sx757r525skxdzpeoeseha", "type": "plc_operation", "services": { "atproto_pds": { "type": "AtprotoPersonalDataServer", "endpoint": "https://bsky.social" } }, "alsoKnownAs": [ "at://jay.bsky.team" ], "rotationKeys": [ "did:key:zQ3shhCGUqDKjStzuDxPkTxN6ujddP4RkEKJJouJGRRkaLGbg", "did:key:zQ3shpKnbdPx3g3CmPf5cRVTPe1HtSwVn5ish3wSnDPQCbLJK" ], "verificationMethods": { "atproto": "did:key:zQ3shXjHeiBuRCKmM36cuYnm7YEMzhGnCmCyW92sRJ9pribSF" } }, { "sig": "dhstt4uPua8OVs8TVzHTqtCnNMsBDN7kjxIBmTIYBDRkknrtprBJ_AISXFoBZyqfoxq2altp-vlRAPEKSh5zeg", "prev": "bafyreihmf7dapx27fexc7jwj4cdpbxcmhnnwo3x5vrpvbr6lclzj7gpsmi", "type": "plc_operation", "services": { "atproto_pds": { "type": "AtprotoPersonalDataServer", "endpoint": "https://morel.us-east.host.bsky.network" } }, "alsoKnownAs": [ "at://jay.bsky.team" ], "rotationKeys": [ "did:key:zQ3shhCGUqDKjStzuDxPkTxN6ujddP4RkEKJJouJGRRkaLGbg", "did:key:zQ3shpKnbdPx3g3CmPf5cRVTPe1HtSwVn5ish3wSnDPQCbLJK" ], "verificationMethods": { "atproto": "did:key:zQ3shtJpFGgEG3tv3ERKvjo7VHbjDPVyvjYvW7gpie49rtNtc" } } ] Again, feel free to click on it instead, https://plc.directory/did:plc:oky5czdrnfjpqslsw2a5iclo/log. This returns a list of all operations that were performed on this DID. The first entry is the genesis operation — the one that created the DID. It is the only one where prev (previous entry) is null, because it is the first one. Note that the first entry of this DID’s log has a different format. This entry uses the legacy format. Currently, newly created DIDs use the new format (subsequent records), but @jay.bsky.team has been around for a while (the account belongs to Bluesky’s CEO). If you look through the logs you will notice a couple of changes that were made to her identity over time: the handle was changed from jay.bsky.social to jay.bsky.team (note that the legacy format used handle whereas the new format uses alsoKnownAs) the handle now includes at:// the personal data server changed from https://bsky.social to https://morel.us-east.host.bsky.network Signatures Each entry in the log includes a sig field, which contains the signature. This cryptographic signature is derived from the other fields in the entry. For the genesis operation, the rotationKeys (or signingKey for legacy) field contains the public key(s) of the key pair(s) with which the entry was signed. Subsequent operations need to be signed with the key from the previous entry. Additionally, the prev field references the previous entry. Creating a DID The identifier in the DID, which is the last part of the colon-separated string, is constructed from the genesis operation. For @jay.bsky.team: the identifier is oky5czdrnfjpqslsw2a5iclo the genesis operation is this JSON document: { "sig": "KuN3A61golVNSDU71wZKLP9lVuXk6YekJAz1lwDzrPsNTEWHBBW_8zSyV6pDxV4KiYXuAXlS1Ik47XkjQZ94mA", "prev": null, "type": "create", "handle": "jay.bsky.social", "service": "https://bsky.social", "signingKey": "did:key:zQ3shP5TBe1sQfSttXty15FAEHV1DZgcxRZNxvEWnPfLFwLxJ", "recoveryKey": "did:key:zQ3shhCGUqDKjStzuDxPkTxN6ujddP4RkEKJJouJGRRkaLGbg" } Steps: encode the genesis operation in DAG-CBOR (this is a concise binary format and looks a bit like JSON) create a SHA256 hash of the encoded document encode the hash with base 32 and make its letters lowercase. take the first 24 characters add did:plc: as a prefix to create the 32-character DID Verification Based on what we’ve learned so far we can verify a handle from Bluesky. For example, if we want to check @jay.bsky.team: resolve DID via DNS: did:plc:oky5czdrnfjpqslsw2a5iclo look up DID in PLC directory the handle in the alsoKnownAs (or handle for legacy) field must match jay.bsky.team verify all operations using the public keys and signatures reconstruct the DID from the genesis operation and ensure it is the same as the one we found in the DNS TXT record Can we trust the PLC directory though? Say a malicious actor has taken over control and modified all entries in the log. The hacker even constructed the entries in the log so that all the signatures appear valid. How would we still know the PLC directory is compromised? Remember that the DID can be reconstructed from the genesis operation. If that were modified, we’d end up with a different DID from the one we found in the DNS TXT record. Summary This blog explores the AT Protocol, the decentralized foundation of social applications like Bluesky, with a focus on user identities and their technical underpinnings. It explains how Bluesky user handles are associated with Decentralized Identifiers (DIDs), which can be resolved using DNS records or HTTPS endpoints. Detailed examples demonstrate how tools like dig and curl retrieve DID data, revealing the method (plc) and structure used to catalog them in the Public Ledger of Credentials (PLC). The post also examines the DID lifecycle, showcasing how historical operations and changes—such as updates to handles or servers—are logged and accessible for transparency. There are several aspects that we did not investigate, such as: the web method for DIDs tombstone operations in the log recovery how exactly to construct the prev entry in the DID document what the other fields in the DID document mean If you are curious, the links in the next section will help you answer these questions. Links & Further Reading Bluesky Application AT Protocol AT Protocol Identity AT Protocol DID AT Protocol Handle Decentralized Identifiers (DIDs) v1.0 did:plc Method Specification Specification: DAG-CBOR
No Fork Required - Scott's Thoughts
What if another operating system isn't the solution to anything at all? What if device-level identity could tie into existing systems to help pull users out of walled gardens, rather than creating new gardens?
Composable Trust, Part 3: 1 Community, 3 Sovereigns, No Landlords - Eclectic Corvine Muses
An architectural model to yield members, Rosters, and Venues sovereignty over their own domains, and none over each other’s.
The Everything Account
I've been thinking a lot about our accounts lately. We all have an ever-growing pile of digital identities scattered across the web, many forgotten after a brief stint with a random service we found in an app store. It's like second nature at this point: we check out a new

AI, Agency and Protocols_ Power and Governance in Open Social Networks.pdf
Composable Trust, Part 1: Communities Without Credible Exit - Eclectic Corvine Muses
We guarantee that users aren’t subject to platforms. Yet communities are still subject to their stewards. Can we fix this?
Gradients of intimacy and creating shelter: An interview with Erin Kissane
How might we use nature as an inspiration for creating online communities?
✨🙌 AI that helps communities thrive on their own terms
Open protocols + AI-enabled coding = building what we need for ourselves

Field Theory: AI as Social Science Question, Object & Tool
Uses of advanced artificial intelligence are changing how societies organize labor, govern, produce knowledge, and make meaning. In light of these developments, this essay argues that AI models, tools, and systems pose three interrelated imperatives for social science: they demand renewed attention to social theories of how technology, human experience, and social order are entangled; they require study as objects of inquiry in their own right; and they offer capabilities that may transform—or upend—the practice of social investigation itself. From Weber’s analysis of rationalization to Du Bois’s study of technology and inequality to contemporary scholarship on algorithmic governance, the essay examines what social science distinctively offers: the capacity to historicize the apparently unprecedented, to trace connections across scales, and to center those most affected by technological change. It identifies how algorithmic systems are remaking the distribution of opportunity and risk as a central task of social inquiry and asks what futures social science might help bring into being.
Practical Decentralization
The point of decentralization is to guarantee the rights of individuals and communities on the Internet. Pulling that off is a balancing act between practicality and ideology.

W-Social: What does sovereignty mean for social media? – Open Future
The European Commission’s move to W-Social frames it as a European alternative to X, but its closed-source code and reliance on Bluesky’s infrastructure show that sovereign social media requires open infrastructure—not European ownership alone.

Reclaiming my digital identity — Open Indie
This post is the preamble of a 5-part series called The Great Untangling. The following four posts have already been published and are li...

The Internet Transition
The Internet is allowing us to build a richer, more complex society but the way in which we Internet today is failing to support the governance systems that a more complex world requires. I take a look at why these issues are related, try to develop an intuition for a way forward, and point at the emerging field that is coming together to build that future.
