25 artículos etiquetados con "cwtch-stable"

We first introduced UI tests last January. At the time we had developed a suite of UI tests that could be run manually in a development environment. However, we faced a number of issues consistently running these tests in our automated pipelines.

One of the main threads of work that needs to be complete early in the Cwtch Stable roadmap is integrating UI tests into our CI pipelines, in addition to expanding their scope. Now that Flutter 3 has stabilized desktop support, and we have invested effort in improving Cwtch performance, it is time to ensure these tests are running on every build.

One of the tenets for Cwtch Stable is Universal Availability and Cohesive Support:

"People who use Cwtch understand that if Cwtch is available for a platform then that means all features will work as expected, that there are no surprise limitations, and any differences are well documented. People should not have to go out of their way to install Cwtch."

This development log seeks to capture the current state of Cwtch platform support, and how we plan to make platform support decisions going forward as we move towards Cwtch Stable.

The questions we aim to answer in this post are:

• What systems do we currently support?
• How do we decide what systems are supported?
• How do we handle new OS versions?
• How does application support differ from library support?
• What blockers exist for systems we wish to support, but currently cannot e.g ios?

From the start of the Cwtch project, the source code for all components making up Cwtch has been freely available for anyone to inspect, use, and modify.

But open source code is only one defense against malicious actors who might seek to undermine your privacy and security. This is why, as part of our ongoing Cwtch Stable work, we are working towards making all parts of the Cwtch chain reproducible and verifiable.

The whole point of reproducible builds is that you no longer have to trust binaries provided by the Cwtch Team because you can independently verify that the binaries we release are built from the Cwtch source code.

In this devlog we will talk about how Cwtch bindings are currently built, the changes we have made to Cwtch bindings to make future distributions verifiable, and the next steps we will be taking to make all Cwtch builds reproducible. This will be useful to anyone who is looking to reproduce Cwtch bindings specifically, and to anyone who wants to start implementing reproducible builds in their own project.

Cwtch grew out of a prototype and has been allowed to evolve over time as we discovered better ways of implementing safe and secure metadata resistant communications.

As we grew, we inserted experimental functionality where it was most accessible to place - not, necessarily, where it was ultimately best to place it - this has led to some degree of overlapping, and inconsistent, responsibilities across Cwtch software packages.

As we move out of Beta and towards Cwtch Stable it is time to revisit these previous decisions with both the benefit of hindsight, and years of real-world testing.

In this post we will outline our plans for the Cwtch API that realign responsibilities, and explicitly enable new functionality to be built in a modular, controlled, and secure way. In preparation for Cwtch Stable, and beyond.

As of December 2022 we have released 10 versions of Cwtch Beta since the initial launch, 18 months ago, in June 2021.

There is a consensus among the team that the next large step for the Cwtch project to take is a move from public Beta to Stable – marking a point at which we consider Cwtch to be secure and usable.

This post outlines the general principles that are guiding the development of Cwtch Stable, the obstacles that prevent a stable Cwtch release, and closes with an overview of the next steps and our timeline for tackling them.