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
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
Title: Progress on atproto Values and Value Proposition
Author: bnewbold
Date: 2024-08-11
Tags: tech, dweb
Status: draft
It has been a wild 18 months working at Bluesky on atproto. Goalposts and narratives have a way of getting pulled around by crises and the priorities of the week, making it is easy to lose track of the big picture. In this post, i'm dredging up my own personal hopes and goals for the protocol from the early days, to see how much progress has been made.
When I started in January 2023 the company was shifting from an R&D project to building out a real-world product, while at the same time finishing design of large social-technical components of the protocol. As a tiny team we designed and implemented the repo synchronization protocol, core moderation system, and "app-view" concept all in a couple months. While at the same time adding basic product features (search! Android!), and growing the early community to tens of thousands of users.
Fast-forwarding a year and a half, today the network is openly federated with hundreds of PDS instances, is home to millions of user accounts, there are thousands of independent currated feeds, and dozens of independent labeling services are in operation.
I should be clear that the roadmap below is a personal and historic artifact. This was never a roadmap for the whole team. In particular, team's overall philosophy is that developing and prioritizing "product" and "protocol" together will lead to better outcomes. I'm taking a more "protocol" perspective here.
## Open/Libre Protocol
**Goals:** The protocol itself should have a written specification, with no restrictions on reuse. Independent parties should be able to implement it and interoperate with no concerns about intellectual property. The most popular and influential implementations and service providers should have good (if not always perfect) compliance with the specification.
The future development of the protocol should have a clear, neutral, trustworthy governance process. There should be resiliency against "embrace/extend/extinguish" by any large providers.
**Milestones and Capabilities**:
- ✅ open written specification of existing protocol
- ✅ open source software reference implementation
- ✅ license on protocol specs
- ⬜ open compliance/interoperation test suite
- ⬜ independent protocol governance (eg, a standards body)
**Summer 2024 Status**: Doing an Ok job keeping production reality and written specs synchronized; gaps between real-world behavior and documentation are common with this sort of project. There are some areas of written specs to be completed or updated. Standards body work will require more independent stakeholders to get started.
## Credible Exit
**Goals:**: There should be no technical or social single-point-of-failure for the overall protocol and network. There should be no single organization or individual who can entirely exclude others from the ecosystem (though the ecosystem may *collectively* exclude bad actors). There should be multiple independent interoperating service providers for each infrastructure component.
**Milestones and Capabilities**:
- ✅ open firehose and public repositories
- ✅ open/libre PDS implementation which supports self-hosting
- ✅ open/libre Relay implementation
- ✅ open/libre AppView implementation
- ✅ open/libre client app implementation
- ✅ account migration functionality in production network
- ✅ open federation in the production network
- ⬜ `did:plc` transparency log and multiple replica/witness/operator parties
- ⬜ `did:plc` as a separate legal entity
- ⬜ multiple independent PDS providers with open registration
- ⬜ multiple independent Relay services
- ⬜ multiple independent AppView services
**Summer 2024 Status**: Great progress on proven technical functionality and available open software. Serious independent infrastructure operators are lacking for several components, but it is still early days. PLC socio-technical path forward has solidified compared to early 2023, and centralization risk with PLC is manageable.
## Own Your Identity and Data
**Goals:** Individual account holders should have ultimate control over their network identity, and retain ownership of content they create and contribute to the network.
**Milestones and Capabilities**:
- ✅ repo export (CAR download) and parse/dump tools
- ✅ `did:plc` supports rotation keys
- ✅ custom domain handles (own your handle)
- ✅ accessible repo export (in-app download CAR button)
- ✅ personal private data export mechanism (eg, preferences)
- ⬜ data reuse intent mechanism (something like robots.txt)
- ⬜ accessible `did:plc` identity control (in-app and/or supporting tools)
**Summer 2024 Status**: This has a bright spot for the protocol, with most core functionality enabled early on. It would be great for more users to have recovery keys registered for their PLC identities; this will require UI/UX work and encouragement. Though the functionality is still a win even if adopted only by high-stakes or institutional accounts.
## Algorithmic Choice
**Goals:** Users should have individual control over what content they see and what is recommended to them. New entrants (communities, companies, etc) should be able to provide curation and discovery services.
**Milestones and Capabilities**:
- ✅ transparent timeline "algorithm" (open source implementation)
- ✅ feed generator system
- ✅ lists (for content curration)
- ✅ easier developer access to existing public mod labels (eg, label firehose)
- ✅ hashtags
- ✅ interaction feedback API for feed generators
- ⬜ cheaper firehose subscription at scale (filters/variations of existing firehose)
**Summer 2024 Status**: The protocol has been fairly successful in this area. The feed tooling ecosystem in particular has made feed curration relatively accessible, with tens of thousands of feeds created.
## Composable Multi-Party Moderation
There should not be a single organization or party who has unique control of moderation policy and enforcement across the entire global network. It should be possible for new entrants to participate in moderation of any subset of the existing network.
This area is very central to the entire project.
**Milestones and Capabilities**:
- ✅ core labeling system and moderation SDK
- ✅ individual interaction controls (thread gates, blocks, mutes)
- ✅ account lists for moderation (mod lists)
- ✅ moderation service protocol support (labeling and reports)
- ✅ Ozone mod service software open source and self-hostable
- ⬜ inter-provider infrastructure takedowns: delegation and notifications
- ⬜ scenes, communities, or similar “structure” to Bluesky Social network, as scopes for moderation
**Summer 2024 Status**: The independent labeler service system launched later than other components. Independent moderation services have seen successes and failures, and it will probably take more time to see where the ecosystem lands.
## Foundation for New Apps
atproto should be a reasonable choice for small teams to build new applications, even if they don't particularly care about decentralized protocols. That is, social graph network effects and features provided by the protocol ("problems solved", "value created") should outweigh added complexity, friction, or inefficiencies ("problems introduced", "costs").
**Milestones and Capabilities**:
- ✅ protocol architecture designed to support multiple Lexicons and apps
- ✅ allow non-bsky records in repos (PDS+Relay)
- ✅ enable PDS proxying to arbitrary services (eg, new AppView)
- ⬜ OAuth (very soon!)
- ⬜ docs, resources, examples for creating new Lexicons and end-to-end applications
- ⬜ generic Lexicon validation (resolution process, etc)
- ⬜ SDK and infra shown to work well (first-class) with non-bsky Lexicons
**Summer 2024 Status**: This is the area we have invested the least visible time and effort towards to date, though this was always going to be a later-stage goal. A lot of early work went in to ensuring this would be possible, but only recently has it even been possible to write arbitrary records or proxy to independent services. There are a growing number of early-adopter apps, the developers of which have had to reverse-engineer many aspects of the protocol.
## More Thoughts
The huge waves of press, user growth, and infrastructure demands in 2023 were challenging, but more than we could have hoped for. An intensely engaged community moved in with strong opinions and high expectations around product features and community dynamics. It has been an amazing opportunity to ship high-concept network features to a large and more-or-less receptive audience. We've had a never-sleeping, ever-mischievous developer scene watching every git commit and repeatedly front-running our product launches.
A large contingent of the network does not give a shit about protocols, adverserial interop, enshittification, protocol bridging, or moderation across geo-political and cultural borders. I'm so proud that those folks have had reason to stick around. I think that set of concerns is important and will be positive differentiators for atproto and Bluesky in the long run. But realistically, we need to create a fun no-compromises environment where people want to invest time and energy, or none of it will matter very much.
|
