New Reference Implementation In PHP: A Discussion

Hey guys,

Let's dive into a discussion about the new reference implementation for our project, focusing on fedi-e2ee and the public-key-directory-specification. Previously, the decision was made to build on SigSum, which led to choosing Go as the primary language for the reference implementation. The thought process was that Go would simplify things in the long run, making development smoother and more efficient. However, as we all know, sometimes the best-laid plans don't always pan out exactly as expected, and that’s okay! It’s all part of the process of innovation and finding the most effective solutions.

The Challenges with SigSum and Go

The initial hurdle came when trying to get SigSum up and running within a GitHub Actions workflow. This turned out to be a grueling experience, consuming a significant amount of time and effort. The complexities involved in the setup and configuration proved more challenging than anticipated. Furthermore, a critical aspect of the project, getting the PKD (Public Key Directory) to communicate effectively with SigSum, remained elusive. Despite numerous attempts and considerable effort, a successful test of this interaction never materialized. This lack of successful testing raised concerns about the viability of the chosen approach and prompted a reevaluation of the technology stack.

The difficulties encountered with SigSum highlighted the need to reconsider the project's direction. This led to discussions and ultimately the decision to remove SigSum from the stack. This was a significant step, as it meant reassessing the foundational elements of the implementation. The decision wasn't taken lightly, but it was deemed necessary to ensure the project's long-term success and stability. Removing SigSum also opened up new possibilities for alternative technologies and approaches that might better suit the project's needs.

Shifting to PHP: A Pragmatic Choice

With SigSum out of the picture, the original rationale for using Go diminished. This prompted a broader discussion about the most suitable language for the reference implementation. Considering various factors, including developer familiarity, ease of use, and the specific requirements of the project, PHP emerged as a strong contender. This decision reflects a pragmatic approach, prioritizing efficiency and maintainability.

Therefore, a decision has been made to archive the existing pkd-server-go repository. The focus will now shift towards developing a new reference implementation using PHP, a language with which I have significantly more experience and fluency. This transition is expected to streamline the development process, reduce potential roadblocks, and ultimately lead to a more robust and reliable implementation. It’s like choosing a tool you're super comfortable with because you know it'll help you get the job done efficiently!

Embracing a Multi-Language Ecosystem

It's important to emphasize that choosing PHP for the reference implementation doesn't restrict others from using different languages for their own server software. The beauty of open-source and collaborative development lies in its flexibility and inclusivity. Developers are welcome and encouraged to write their own server software in Rust, Go, Java, .NET, or any other language they deem suitable for their needs. This diversity of implementations will contribute to a richer ecosystem and foster innovation.

The aim is to provide a solid foundation with the PHP reference implementation, but also to encourage experimentation and exploration with other technologies. This approach ensures that the project benefits from the collective expertise and preferences of the community. It’s like having a main road, but also lots of cool side paths to explore!

Apologies for Churn and Confusion

I understand that these changes may have caused some churn and confusion, and for that, I sincerely apologize. Transitions and adjustments are sometimes necessary in the course of software development, particularly in the early stages of a project. The goal is always to make informed decisions that ultimately benefit the project and the community involved. Transparency and open communication are key to navigating these changes effectively. The decision to shift to PHP was made after careful consideration of the challenges encountered and the potential benefits of the new approach.

Moving forward, I'm committed to providing clear and timely updates on the progress of the PHP reference implementation. Your understanding and continued support are greatly appreciated. It's all about working together to build something awesome, and sometimes that means making a few course corrections along the way. Thanks for sticking with us through the journey!

In-Depth Look at the Technology Choices

Let’s break down a little further why these decisions were made. We all know tech choices are never just about one thing; they’re a mix of what works best for the project, what the team knows, and what the community needs. So, let’s pull back the curtain a bit and see what went into this.

The Initial Draw to Go and SigSum

Initially, Go seemed like a stellar choice. It’s known for its efficiency, concurrency features, and strong support for networking – all of which are crucial for a project dealing with distributed systems and secure communications. The idea of building on SigSum was also attractive. SigSum aims to provide a way to verify the integrity and authenticity of data, which aligns perfectly with the goals of fedi-e2ee and the public-key-directory-specification. It promised a robust foundation for ensuring the security and reliability of our system. Go's reputation for handling such tasks made it a seemingly ideal fit.

However, the practical realities of integrating SigSum into our workflow presented unexpected challenges. Setting up SigSum within GitHub Actions, our chosen CI/CD environment, proved to be far more complex than anticipated. This complexity not only slowed down our development process but also introduced potential points of failure. Furthermore, the critical link between the PKD and SigSum – the ability for them to communicate and work together seamlessly – remained untested and unproven. This was a major concern, as the entire security model relied on this interaction. Despite our best efforts, we couldn’t achieve a satisfactory level of confidence in this integration.

Why PHP? Addressing Concerns and Highlighting Benefits

Now, I know what some of you might be thinking: PHP? Isn't that a bit… unexpected? PHP sometimes gets a bad rap, but it’s come a long way, especially in recent years. Modern PHP is powerful, efficient, and offers a wealth of frameworks and tools that make it a highly productive environment for web development. And that's where it shines, right? For many of us, PHP is like that trusty old friend you can always count on. It's not always the flashiest, but it gets the job done, and it gets it done well.

For me personally, my deep familiarity with PHP was a major factor. I can develop and debug PHP code much more quickly and efficiently than Go. This increased productivity translates directly into faster progress on the project. Think of it as choosing the right tool for the job; sometimes, the best tool is the one you know how to use best! Beyond personal familiarity, PHP boasts a vibrant ecosystem and a large, active community. This means a wealth of resources, libraries, and support are readily available, which can significantly accelerate development and problem-solving. Imagine having a huge toolbox filled with every gadget you could possibly need – that's the PHP ecosystem.

Furthermore, PHP’s mature web development frameworks, such as Laravel and Symfony, provide robust features for building scalable and maintainable applications. These frameworks handle many of the common tasks associated with web development, allowing us to focus on the specific requirements of our project. Security is also a key consideration, and modern PHP frameworks incorporate best practices for protecting against common web vulnerabilities. This ensures that our reference implementation is not only functional but also secure.

A Word on Performance

Now, let’s address the elephant in the room: performance. Some might argue that PHP isn’t as performant as Go. And while that might be true in some highly specific benchmarks, for the purposes of a reference implementation, raw performance is less critical than ease of development and maintainability. The goal of a reference implementation is to demonstrate the functionality and concepts of the system clearly and effectively. It’s a blueprint, not a production-ready system. While performance is always a consideration, it shouldn’t overshadow other important factors like developer productivity and code clarity. The focus is on creating a solid foundation that others can build upon, regardless of their chosen language.

Embracing a Polyglot Approach

This brings us to a crucial point: the choice of PHP for the reference implementation doesn't mean that other languages are off the table. Quite the contrary! We actively encourage the community to explore and implement the specification in whatever language they feel is best suited to their needs. Whether it's Rust, Go, Java, .NET, or something else entirely, we welcome diverse implementations. This polyglot approach allows us to leverage the strengths of different languages and ecosystems, fostering innovation and experimentation.

Think of it as a diverse ecosystem where different species coexist and contribute to the overall health of the environment. Each language brings its own unique strengths and perspectives to the table. By embracing this diversity, we create a more robust and resilient system. The PHP reference implementation serves as a starting point, a foundation upon which others can build and innovate. It provides a clear and concise example of how the specification can be implemented, but it's not the only way. We want to encourage the community to explore alternative approaches and push the boundaries of what’s possible.

The Bigger Picture: Community and Collaboration

Ultimately, this project is about community and collaboration. We’re building this together, and the decisions we make should reflect the needs and preferences of the community. This means being open to feedback, adapting to changing circumstances, and making pragmatic choices that benefit the project as a whole. The shift to PHP is a reflection of this collaborative spirit. It’s a decision that prioritizes developer productivity, maintainability, and community engagement.

I understand that changes like this can sometimes be disruptive, and I appreciate your patience and understanding as we navigate this process. My goal is to be as transparent as possible and to keep you informed every step of the way. I encourage you to share your thoughts, ask questions, and get involved in the discussion. Together, we can build something truly amazing.

Looking Ahead

The path forward involves archiving the pkd-server-go repository and dedicating our efforts to building the PHP reference implementation. This is not just a change of language; it's a strategic move to enhance our development process and deliver a more robust and maintainable solution. The focus will be on creating a clear, concise, and well-documented implementation that serves as a solid foundation for future development.

The PHP implementation will adhere closely to the specification, providing a faithful representation of the intended functionality. It will also incorporate best practices for security and performance, ensuring that it meets the highest standards. We'll be paying close attention to code clarity and readability, making it easy for others to understand and contribute to the project. Think of it as building a house with strong foundations and a clear blueprint – a home that others can easily expand and customize.

Staying Connected and Contributing

Your feedback and contributions are invaluable as we move forward. I encourage you to actively participate in the discussions, share your ideas, and contribute code. The more perspectives we have, the better the final product will be. Open communication is key to success, and I’m committed to keeping you informed every step of the way.

Regular updates will be provided on the progress of the PHP implementation, including timelines, milestones, and any challenges encountered. We’ll also be soliciting feedback on specific design decisions and implementation details. This collaborative approach ensures that the final product meets the needs of the community and reflects the collective wisdom of its members. It’s like a collaborative painting, where everyone adds their unique brushstrokes to create a masterpiece.

Final Thoughts

In conclusion, the decision to shift the reference implementation to PHP is a strategic one, driven by practical considerations and a commitment to community collaboration. While the initial path with Go and SigSum presented unforeseen challenges, these challenges have ultimately led us to a more efficient and sustainable approach. The PHP implementation will provide a solid foundation for the project, while also encouraging exploration and innovation in other languages. Thank you for your understanding, support, and continued involvement in this exciting endeavor. Let’s build something amazing together!