So #[0] posted a blog post about bluesky that ruffled some feathers: https://fiatjaf.com/ab1127fb.html

This triggered a long skeet stream reply from bluesky developer Paul Frazee: https://staging.bsky.app/profile/pfrazee.com/post/3jv72j3fp6g2r

This then caused me to write up some thoughts:

The world of decentralized protocols is gaining momentum, and it's exciting to see projects like Nostr and Bluesky at the forefront. Many of us have dedicated years to developing these protocols, and now they're capturing global interest. I've been tracking various decentralized social media protocols for a long time, and if you're interested, you can find my comprehensive database of open social media protocol projects here: https://airtable.com/shri7e7EHoTi0cEjO

Nostr, at_protocol, and other projects take inspiration from Secure Scuttlebutt, which I had the pleasure of working on alongside talented individuals like @pfrazee and @jay. Nostr is a slightly modified version of Scuttlebutt, while at_protocol represents a more significant reimagining. At_protocol borrows ideas from the IPFS ecosystem and W3C DID standards, while Nostr incorporates concepts from Bitcoin technology (not a blockchain or cryptocurrency project). Both projects have received substantial support from #[1] , who funds them but doesn't control their direction.

Nostr began as a humble side project, growing organically as developers adopted it. In contrast, Bluesky started with significant press and a high-profile search for a team lead, taking years to evolve from an idea to a funded project. Bluesky's community experienced challenges that led to a split, and the original community renamed itself https://dsocialcommons.org/. Nostr, on the other hand, never encountered such issues, with developers contributing to the project independently.

The two projects represent different approaches to open source development: the cathedral model (Bluesky) and the bazaar model (Nostr). Both have seen success, but I must express my disappointment with Bluesky's choice to follow the cathedral model. Despite my frustration, I have great admiration for the team behind Bluesky and the work they're doing. However, Bluesky employees maintain full control over the at_protocol, leaving little room for external contributors.

In contrast, Nostr provides an open platform for contributions, enabling me to create an app (nos.social) and write specifications that are openly debated: https://github.com/nostr-protocol/nips/pull/457. Bluesky's code is indeed open source, but their development process is not. This is reminiscent of how Safari's WebKit or Android operate as open source projects without truly embracing the open source development methodology.

Recently, I expressed concerns about Bluesky as it currently operates as a single unified network. Friends advised me to take a step back and give the team time. I experimented with their Indigo PDS server and found it promising. I believe that the at_protocol will eventually become an open, multi-server protocol. The people behind Bluesky have a long history of working on open protocols and are not developing this technology to create a new, closed ecosystem.

On a personal note, I feel a stronger social connection to Bluesky's early adopter community but appreciate Nostr's openness for contributions. I could potentially create an at_protocol client, but making substantial contributions to the Bluesky protocol seems reserved for employees and select advisors. Therefore, I choose to invest my time and effort in open projects. I firmly believe in Conway's law, which states that the structure of the organization building a technology will shape the technology itself.

I believe @fiatjaf might be overly critical of Bluesky. He had the luxury of working in obscurity without the pressure of media attention while figuring things out. In contrast, Bluesky faces high expectations and the responsibility to "replace Twitter." The stress that the Bluesky team endures while trying to develop their project under the watchful eyes of many likely contributed to their adoption of the cathedral model of open source. I empathize with the challenges they face in this environment.

Much of the internet was built using the bazaar model, consisting of small pieces loosely joined. This approach gave us the web and numerous other systems we use today. Bluesky's design-driven model is more meticulously architected, but it reminds me of Java and XML (no offense intended).

I believe that these networks can interoperate. I already communicate between the fediverse and Nostr daily, and while it's not perfect, it mostly works. I'm optimistic that we'll achieve similar interoperability with at_protocol once the system becomes more open. It is essential to recognize the strengths and weaknesses of both approaches and to appreciate the incredible work and progress made in both projects. As the world of decentralized protocols continues to grow, I remain hopeful for a future that embraces collaboration and openness.