atproto blog tweaksHEADmaster

1 files changed, 17 insertions, 10 deletions

diff --git a/posts/2024/atproto_progress.md b/posts/2024/atproto_progress.md
index 364f0b2..6a1a0c6 100644
--- a/posts/2024/atproto_progress.md
+++ b/posts/2024/atproto_progress.md
@@ -1,14 +1,13 @@
 Title: Progress on atproto Values and Value Proposition
 Author: bnewbold
-Date: 2024-08-11
+Date: 2024-08-12
 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.
+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 some of my own early notes on goals and values for the protocol, 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.
+Fast-forwarding a year and a half, today the network is openly federated with hundreds of PDS instances. It 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.
 
@@ -23,7 +22,7 @@ The future development of the protocol should have a clear, neutral, trustworthy
 
 - ✅ open written specification of existing protocol
 - ✅ open source software reference implementation
-- ✅ license on protocol specs
+- ✅ open license on protocol spec text
 - ⬜ open compliance/interoperation test suite
 - ⬜ independent protocol governance (eg, a standards body)
 
@@ -63,7 +62,7 @@ The future development of the protocol should have a clear, neutral, trustworthy
 - ✅ 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)
+- ⬜ 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.
@@ -90,7 +89,7 @@ The future development of the protocol should have a clear, neutral, trustworthy
 
 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.
+This area is central to the entire project!
 
 **Milestones and Capabilities**:
 
@@ -100,7 +99,7 @@ This area is very central to the entire project.
 - ✅ 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
+- ⬜ scenes, communities, or similar “structure” to bsky app 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.
 
@@ -114,7 +113,7 @@ atproto should be a reasonable choice for small teams to build new applications,
 - ✅ 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!)
+- ⬜ better auth mechanism (OAuth)
 - ⬜ 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
@@ -122,9 +121,17 @@ atproto should be a reasonable choice for small teams to build new applications,
 **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
+## How Did It Go?
 
 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.
 
+In retrospect, it feels like the big "launch" milestones relevant to the protocol were:
+
+- [custom domain handles](https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial) in April 2023
+- [feed generators](https://bsky.social/about/blog/7-27-2023-custom-feeds) in July 2023
+- [open federation](https://bsky.social/about/blog/02-22-2024-open-social-web) in February 2024
+- [independent labelers and Ozone](https://bsky.social/about/blog/03-12-2024-stackable-moderation) in March 2024
+
+Handles and feed generators came fairly easy. There was a federation sandbox in May 2023, and we were close to opening up much sooner than we did, but waited to ensure the servers and moderation systems were robust to trolls and spammers. Finally getting to federation and launching Ozone were long projects, but came out better for the effort, and left me feeling like we had crested the hilltop with most of the original big ideas in place. We are very close to landing OAuth, another long project, which along with other developer polish could end up being a symbolic milestone for building independent apps.