Update Translations

This commit is contained in:
Sarah Jamie Lewis 2023-08-02 10:31:24 -07:00
parent a4bb7dfe05
commit cf195fbd91
78 changed files with 6300 additions and 0 deletions

View File

@ -0,0 +1,94 @@
---
title: Path to Cwtch Stable
description: "The 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 the next steps and a timeline to tackle them."
slug: path-to-cwtch-stable
tags:
- cwtch
- cwtch-stable
- planning
image: /img/devlog1_small.jpg
hide_table_of_contents: false
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
As of December 2022 we have released 10 versions of Cwtch Beta since the [initial launch, 18 months ago, in June 2021](https://openprivacy.ca/discreet-log/10-cwtch-beta-and-beyond/).
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.
![](/img/devlog1.png)
<!--truncate-->
### Tenets of Cwtch Stable
It is important to state that Cwtch Stable **does not mean an end to Cwtch development**. Rather, it establishes a baseline at which point Cwtch is considered to be a fully supported project. The Cwtch Team have set the following tenets that guide our decision-making and priorities:
1. **Consistent Interface** each new Cwtch release should be accompanied by consistent releases to all support libraries. This requires a stable and documented API so that we can be clear when upgrading a library will result in breaking change for downstream projects. We should not, as a general rule, have to make breaking changes to this API interface in order to support new experimental features.
2. **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.
3. **Reproducible Builds** Cwtch builds should be trivially reproducible, including the ability to reproduce all bundled assets. Reproducibility should not rely on containerization, but all containers used in our build process should be reproducible.
4. **Proven Security** we can demonstrate that Cwtch provides first class security through well documented design, testing, and audit procedures. We should be able to do this for Cwtch in addition to all functional dependencies.
### Known Problems
To begin, let's outline the current state of Cwtch and lay out the issues that stand in the way of Cwtch Stable.
1. **Lack of a Stable API for future feature development** while the core Cwtch API has remained fairly unchanged in recent releases we understand that the addition of new features e.g. cohesive group support likely requires new API hooks that allow safe manipulation of Cwtch Profile (transactional semantics and post-event hooks). Before we can even consider a stable release we need to define what this API should look like, and implement it. (Tenet 1)
2. **Special functionality in libCwtch-go** our C-API bridge (libCwtch-go) currently implements a lot of special functionality in support for both experimental features (e.g. profile images) and UI settings. This special behaviour makes it difficult to track feature responsibility. This behaviour must either be pushed back into the main Cwtch library, or defined to be the responsibility of a downstream application e.g. Cwtch UI. (Tenet 1)
3. **libCwtch-rs partial support** - we currently do not officially consider [libCwtch-rs](https://lib.rs/crates/libcwtch) when updating libCwtch-go as part of our release schedule. Before we can consider a Cwtch Stable release we should have multiple beta releases where libCwtch-rs has full support for any and all new Cwtch features. (Tenet 1, Tenet 2)
4. **Lack of Reproducible Pipelines** - while the vast majority of our build pipeline is automated, containerized, and reproducible, there remain bundled assets that cannot be trivially constructed, and assets that have non-reproducible elements (e.g. build-time injected via git tags, and go binaries including build user information). (Tenet 3)
5. **Lack of up to date, and translated, Security Documentation** the [Cwtch security handbook](https://docs.openprivacy.ca/cwtch-security-handbook/) is currently isolated from the rest of our documentation and doesnt benefit from cross-linking, or translations. (Tenet 4)
6. **No Automated UI Tests** we put a lot of work into [building out a testing framework for the UI](https://openprivacy.ca/discreet-log/23-cucumber-testing/), but it currently sits mostly unused, and unexercised in our build pipelines. We should revisit that work. (Tenet 4)
7. **Code Signing Provider** our previous code signing certificate provider had support issues, and we have not yet decided on a replacement. ( Tenet 4)
8. **Second-class Android Support** - while we have put [a lot of effort behind Android support](https://openprivacy.ca/discreet-log/27-android-improvements/) across the Beta timeline, it still clearly suffers from additional issues that desktop editions do not. In order to consider Cwtch stable we must resolve all major bugs impacting Android usability. (Tenet 2)
9. **Lack of Fuzzing** while [Fuzzbot](https://openprivacy.ca/discreet-log/07-fuzzbot/) sets a standard high above most other secure communication applications, we can and should do better. Fuzzbot currently only targets user-endpoint messages, which are the most likely to result in real-world risk, but we should strive to have the same coverage for internal events at both the network level, the internal Cwtch App level, and the event bus level. (Tenet 4)
10. **Lack of Formal Release Acceptance Process** currently the features and experiments that get included in each release are determined in an ad-hoc consensus. This occasionally means that some features are left unsupported on certain platforms, and bugs occasionally arise in platforms (Android in particular) due to “unrelated” changes. In order for Cwtch to be declared stable, a formal acceptance process must ensure that new changes do not break existing features, and that they work across all platforms. (Tenet2, Tenet 4)
11. **Inconsistent Cwtch Information Discovery** our current documentation is split between docs.cwtch.im, cwtch.im and docs.openprivacy.ca, in additional to blogs on Discreet Log. This makes it difficult for people to learn about Cwtch, and also means that our own explanations often must link across multiple different sites. (Tenet 2)
12. **Incomplete Documentation** docs.cwtch.im was very well received. However, it still suffers from incomplete sections, missing links, and an overall lack of screenshots. What screenshots there are lack consistency in sizing, style, and feel. (Tenet 2)
### Plan of Action
Outside of the problems that have standalone solutions (e.g. find a new code signing provider, or fix all Android issues), there are a number of higher level activities that need to be completed before we can be confident in a Cwtch Stable release:
1. **Define, Publish, and Implement a Cwtch Interface Specification Documentation** this should include examples of how new (experimental) behaviour might be implemented from finer-grained composition. Must include moving all special functionality out of libCwtch-go. Should be followed up by implementing the proposed design. (Tenet 1, Tenet 4)
2. **Define, Publish, and Implement a Cwtch Release Process** this document should outline the criteria for publishing a new release, the difference between major and minor versions, how features are tested, how regressions are caught before release, and who is responsible for different parts of the process. (Tenet 2)
3. **Define, Publish, and Implement a Cwtch Support Document** - including answers to the questions: what systems do we support, how do we decide what systems are supported, how do we handle new OS versions, and how does application support differ from library support. This should also include a list of blockers for systems we wish to support, but currently cannot e.g ios. (Tenet 2)
4. **Define, Publish, and Implement a Cwtch Packaging Document** - as a supplement to the Support document we need to define what packaging we support, in addition to what app stores and managers for which we provide official releases. ( Tenet 2)
5. **Define, Publish, and Implement a Reproducible Builds Document** this should cover not only Cwtch binaries, but also Docker containers, and included assets (e.g. Tor binaries). Followed up by implementing the plan into our build pipeline. ( Tenet 3)
6. **Expand the Cwtch Documentation Site** to include the Security Handbook, development blogs, design documentation, and support plans. This should be our only publishing platform, outside of a landing page, and downloads on cwtch.im. This expansion should include a style guide for documentation and screenshots to ensure that we maintain consistent language and visuals when talking about a feature (e.g. we should use the same profile image style, theme, profile names, message style etc.) (Tenet 1, Tenet 2, Tenet 3, Tenet 4)
7. **Expand our Automated Testing to include UI and Fuzzing** - integrate UI automated tests into our build pipeline. Expand our fuzzing to include the event bus, and PeerApp packets. Finally, integrate automated fuzzing into the build pipeline, so that all new features are fuzzed to the same level. (Tenet 4)
8. **Re-evaluate all Issues across all Cwtch related repositories** issues are either bugs that need to be fixed before stable (i.e. they are in service of one of the Tenets), new feature ideas that should be scheduled around stable work (i.e. they dont align with a specific Tenet), or support requests for systems that need input from the Support and Packaging Plans.
9. **Define a Stable Feature Set** there are still a few features which do not exist in Cwtch Beta which would be required for a stable release, such as chat search. Following on from the Cwtch Interface Specification Document, the team should decide what features Cwtch Stable will target, and these features should be prioritized for inclusion in Cwtch 1.11, Cwtch 1.12 and any future Beta releases. (Tenet 1)
### Goals and Timelines
With all of that laid out, we are now ready to introduce a timeline for resolving some of these problems, and moving us towards a state where we can launch Cwtch Stable:
1. By **1st February 2023**, the Cwtch team will have reviewed all existing Cwtch issues in line with this document, and established a timeline for including them in upcoming releases (or specifically commit to not including them in upcoming releases).
2. By **1st February 2023**, the Cwtch team will have finalized a feature set that defines Cwtch Stable and established a timeline for including these features in upcoming Cwtch Beta releases.
3. By **1st February 2023**, the Cwtch team will have expanded the Cwtch Documentation website to include a section for Security, Design Documents, Infrastructure and Support, in addition to a new development blog.
4. By **31st March 2023**, the Cwtch team will have created a style guide for documentation and have used it to ensure that all Cwtch features have consistent documentation available, with at least one screenshot (where applicable).
5. By **31st March 2023** the Cwtch team will have published a Cwtch Interface Specification Document, a Cwtch Release Process Document, a Cwtch Support Plan document, a Cwtch Packaging Document, and a document describing the Reproducible Builds Process. These documents will be available on the newly expanded Cwtch Documentation website.
6. By **31st March 2023** the Cwtch team will have integrated automated UI tests into the build pipeline for the cwtch-ui repository.
7. By **31st March 2023** the Cwtch team will have integrated automated fuzzing into the build pipeline for all Cwtch dependencies maintained by the Cwtch team.
8. By **31st March 2023** the Cwtch team will have committed to a date, timeline, and roadmap for launching Cwtch Stable.
As these documents are written, and these goals met we will be posting them here! Subscribe to our [RSS feed](/blog/rss.xml), [Atom feed](/blog/atom.xml), or [JSON feed](/blog/feed.json) to stay up to date, and get the latest on, Cwtch development.
### Help us get there!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,234 @@
---
title: Cwtch Stable API Design
description: "The post outlines the technical changes we are planning on making to the core Cwtch API in preparation for Cwtch Stable"
slug: cwtch-stable-api-design
tags:
- cwtch
- cwtch-stable
- planning
- api
image: /img/devlog2_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
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](https://docs.cwtch.im/blog/path-to-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.
![](/img/devlog2.png)
<!--truncate-->
### Clarifying Terminology
Over the years we have evolved how we talk about the various parts of the Cwtch ecosystem. To make this document clear we have revised and clarified some terms:
- **Cwtch** refers to the overall ecosystem including all the component libraries, bindings, and the flagship Cwtch application.
- **Cwtchlib** refers to the [reference implementation of the Cwtch Protocol](https://git.openprivacy.ca/cwtch.im/cwtch) / Application framework, currently written in Go.
- **Bindings** refers to C/Java/Kotlin/Rust bindings (primarily [libcwtch-go](https://git.openprivacy.ca/cwtch.im/libcwtch-go)) that act as an interface between Cwtchlib and downstream applications.
- `CwtchPeer` is where the reference Cwtch API is defined. It is responsible for managing the state of a single Cwtch Profile, persistence (e.g. storing messages), and automatically reacting to certain messages like message acknowledgements and providing public profile attributes (e.g. profile display name).
- `ProtocolEngine` is responsible for maintaining networking resources like listening threads, peer connections, ephemeral server connections. At present, `ProtocolEngine` is also responsible for automatically responding to certain kinds of messages like providing file chunks for shared files.
### Tenets of the Cwtch API Design
Based on the tenets we have laid out for the Path to Cwtch Stable, we have adopted the following guiding principles for a new API design:
- **Robustness** - new features and functionality can be implemented in Cwtch without adding new functions or dependencies to existing Cwtch interfaces.
- **Completeness** - all behaviour is either defined in the official library, or explicitly deferred to applications, no special behaviour is implemented by intermediate wrappers.
- **Security** experiments should not compromise existing Cwtch functionality - and should be able to be turned on/off at any time without issue.
### The Cwtch Experiment Landscape
A summary of the experiments that are currently implements or in design, and the changes to the code that were required to support them.
- **Groups** the very first prototypes of Cwtch were designed around group messaging and, as such, multi-party chats are the most integrated experiment within Cwtch sharing interfaces with P2P chat and requiring specialized `ProtocolEngine` functionality to manage ephemeral connections and antispam tokens, including the introduction of new peer events like NewMessageFromGroup.
- **Hybrid Groups** - we have plans to upgrade the Groups experience to a more flexible “hybrid-groups” protocol which requires additional custom hook-response that needs to be tightly controlled and isolated from other parts of the system.
- **Filesharing** like Groups, Filesharing is a cross-cutting feature that required new APIs, new Hooks into Peer Events, and additional capability in `ProtocolEngine`.
- **Profile Images** based on Filesharing and the core get/val functionality, there are only a few small parts of the codebase that are explicitly dedicated to profile images, and these are all event-based reactions that currently reside in the event-decoration module of licwtch-go, but could easily be moved to a standalone module if a hook-based API was available.
- **Server Hosting** the only example of an Application-level experiment in Cwch at present. This functionality requires no changes to the cwtchlib module, but is mainly implemented in the libcwtch-go bindings themselves. Ideally this functionality would be moved into a standalone package.
- **Message Formatting** notable as the the main example of a former experimental-functionality that was promoted to an optional feature, but because it is entirely UI based in implementation there are few insights that can be gained from its history
- **Search / Microblogging** proposed features that would require database access/changes in order to implement fully and efficiently, any proposed changes to the Cwtch API should allow for the possibility of new functionality at all layers of the Cwtch stack, including storage.
- **Status / Profile Metadata** proposed features that only require specific APIs / hooks for saving requested information for the purposes of caching.
### The Problem with Experiments
We have done some work in past to limit the impact an experimental feature can have on the rest of Cwtch, mainly through providing restricted sets of public Cwtch APIs e.g. the `SendMessages` interface that only allows callers to send messages.
We have also worked to package experimental functionality into so-called **Gated Functionalities** that are only available if a given experiment is turned on.
Together, these form the current basis for implementing to Cwtch features in the official libraries, but they are not without problems:
- The scope of a functionality is rather broad, and can only be passed a complete Cwtch profile or a denoted subset of functionality e.g. `SendMessages` there is no current way to scope a function to a specific conversation, or to a given zone (e.g. filesharing code is technically able to update attributes unrelated to filesharing).
- The implementation of experiments has mostly been delegated to bindings and, as such, the gating inside CwtchLib is limited, often relying on state to be passed into it by the bindings, or relying on the bindings explicitly disable the functionality.
- This lack of ownership over experiments by the official CwtchLib means that libraries based on CwtchLib instead of bindings do not have access to the safeguards provided by the bindings.
### Restricting Powerful Cwtch APIs
To carefully expand Cwtch out using additional experimental APIs we must work to limit the impact further e.g. restricting actions to a given type of conversation, or only executing actions at registered times. To do this we require three separate but related strands of work:
- Assume responsibility for experiments and features in Cwtch itself so that Cwtchlib has direct access to which experiments are enabled at any given time. Doing this allows changes to settings to always flow through `Application` and, (as currently happens with Anonymous Communication Network (ACN) state), provides a natural point at which to interface those changes into a Cwtch Profile.
- Finer-grained Interfaces that allow restricting actions to preregistered conversation types e.g. a `RestrictedCwtchConversationInterface` which decorates a Cwtch Profile interface such that it can only interact with a single conversation these can then be passed into hooks and interface functions to limit their impact.
- Registered Hooks at pre-specified points with restricted capabilities to allow experimental functionality to register interest in certain events, and act on them at the correct time, and to allow `CwtchPeer` to control which experiments get access to which events at a given time.
#### Pre-Registered Hooks
In order to implement certain functionality actions need to take place in-between events handled by `CwtchPeer`. As a motivating example consider a new group membership protocol overlayed above the existing messages. Such a protocol may require checking against group permission settings after receiving a new message, but before inserting it into into the database (e.g. the message author needs to be confirmed against the list of current members authorized to post to the group).
This is currently only possible with invasive changes to the `CwtchPeer` interface, explicitly inserting a hook point and acting on it. In an ideal design we would be able to register such hooks for most likely events without additional development effort.
We are introducing a new set of Cwtch APIs designed for this purpose:
- `OnNewPeerMessage` - hooked prior to inserting the message into the database.
- `OnPeerMessageConfirmed` hooked after a peer message has been inserted into the database.
- `OnEncryptedGroupMessage` hooked after receiving an encrypted message from a group server.
- `OnGroupMessageReceived` hooked after a successful decryption of a group message, but before inserting it into the database.
- `OnContactRequestValue` hooked on request of a scoped (the permission level of the attribute e.g. `public` or `conversation` level attributes), zoned ( relating to a specific feature e.g. `filesharing` or `chat`), and keyed (the name of the attribute e.g. `name` or `manifest`) value from a contact.
- `OnContactReceiveValue` hooked on receipt of a requested scoped,zoned, and keyed value from a contact.
Including the following APIs for managing hooked functionality:
- `RegisterEvents` - returns a set of events that the extension is interested processing.
- `RegisterExperiments` - returns a set of experiments that the extension is interested in being notified about
- `OnEvent` - to be called by `CwtchPeer` whenever an event registered with `RegisterEvents` is called (assuming all experiments registered through `RegisterExperiments` is active)
#### `ProtocolEngine` Subsystems
As mentioned in our experiment summary, some functionality needs to be implemented directly in the `ProtocolEngine`. The `ProtocolEngine` is responsible for managing networking clients, and sending/receiving packets from those clients to/from a CwtchPeer (via the event bus).
Some types of data are too costly to send over the event bus e.g. requested chunks from shared files, and as such we need to delegate the handling of such data to a `ProtocolEngine`.
At the moment is this done through the concept of informal “subsystems”, modular add-ons to `ProtocolEngine` that process certain events. The current informal nature of this design means that there are not hard-and-fast rules regarding what functionality lives in a subsystem, and how subsystems interact with the wider `ProtocolEngine` ecosystem.
We are formalizing this subsystem into an interface, similar to the hooked functionality in `CwtchPeer`:
- `RegisterEvents` - returns a set of events that the subsystem needs to consume to operate.
- `OnEvent` to be called by `ProtocolEngine` whenever an event registered with `RegisterEvents` is called (when all the experiments registered through `RegisterExperiments` are active)
- `RegisterContexts` - returns the set of contexts that the subsystem implements e.g. `im.cwtch.filesharing`
This also requires a formalization of two *engine specific* events (for use on the event bus):
- `SendCwtchMessage` encapsulating the existing `CwtchPeerMessage` that is used internally in `ProtocolEngine` for messages between subsystems.
- `CwtchMessageReceived` encapsulating the existing `handlePeerMessage` function which effectively already serves this purpose, but instead of using an Observer pattern, is implemented as an increasingly unwieldy set of if/else blocks.
And the introduction of three **additional** `ProtocolEnine` specific events:
- `StartEngineSubsystem` replaces subsystem specific start event, can be driven by functionalities to (re)start protocol specific handling.
- `StopEngineSubsystem` replaces subsystem specific stop event mechanisms, can be driven by functionalities to stop all protocol specific handling.
- `SubsystemStatus` a generic event that can be published by subsystems with a collection of fields useful for debugging
This will allow us to move the following functionality, currently part of `ProtocolEngine` itself, into generic subsystems:
- **Attribute Lookup Handling** - this functionality is currently part of the overloaded `handlePeerMessage` function, filtered using the `Context` parameter of the `CwtchPeerMessage`. As such it can be entirely delegated to a subsystem.
- **Filesharing Chunk Request Handling** this is also part of handlePeerMessage, also filtered using the `Context` parameter, and is already almost entirely implementing in a standalone subsystem (only routing is handled by `handlePeerMessage`)
- **Filesharing Start File Share/Stop File Share** this is currently part of the `handleEvent` behaviour of `ProtocolEngine` and can be moved into an `OnEvent` handler of the file sharing subsystem (where such events are already processed).
The introduction of pre-registered hooks in combination with the formalizations of `ProtocolEngine` subsystems will allow the follow functionality, currently implemented in `CwtchPeer` or libcwtch-go to be moved to standalone packages:
- **Filesharing** makes heavy use of the getval/retval functionality, we can move all of this into a hooked-based functionality extension.
- Filesharing also depends on the file sharing subsystem to be enabled in a `ProtocolEngine`. This subsystem is responsible for processing chunk requests.
- **Profile Images** we treat profile images as a specialization of the file sharing function, as such the experiment can operate entirely over apis provided by the filesharing experiment. (Right now this specialization lives in libcwtch-go as hooks into the relevant functions)
- **Legacy Groups** while groups themselves are a first-class consideration for Cwtch, the actual process of constructing and receiving group messages relies heavily on processing of events, or interpreting generic conversation attributes, and as such this functionality can be moved entirely to hooked-based functionality. By doing this we also open the path towards introducing new group protocols based on the same interface.
- **Status/Profile Metadata** status depends entirely on OnPeerRequestValue / OnPeerReceiveValue and requires little Cwtch Peer interaction other than saving the result.
#### Impact on Enabling (Powerful) New Functionality
None of the above restricts our ability to introduce new functionality in to Cwtch that is dependent on more invasive changes (e.g. direct database access / updates), but they do allow us to structure such changes into discrete modules:
- **Search** a fulltext search feature requires new indexes to be created in Cwtch Storage (likely using the sqlite FT5 module). As an experiment SearchFunctionality would need access to a hook after database setup in order to create and populate those indexes. This is a far more powerful feature than most as it requires direct database access.
- **Non Chat Conversation Contexts** - the storage backend work we implemented last year had a long-term goal of enabling non-chat contexts like microblogging. Like search, these kinds of experiments will require deeply integrated access to the Cwtch database.
## Application Experiments
One kind of experiment we havent touched on yet is additional application functionality, at present we have one main example: Embedded Server Hosting this allows a Cwtch desktop client to setup and manage Cwtch Servers.
This kind of functionality doesnt belong in Cwtchlib as it would necessarily introduce unrelated dependencies into the core library.
This functionality also doesnt belong in the bindings either. They should be as minimal as possible. To that end, we will be moving this functionality out of the bindings and into dedicated repositories which can be managed via an Application Experiment interface.
## Bindings
The last problem to be solved is how to interface experiments with the bindings (libcwtch-go) and ultimately downstream applications.
We can split the bindings into four core areas:
- **Application Management** - functionality necessary to manage the core Cwtch application e.g. StartCwtch, ReconnectCwtchForeground, Shutdown, CreateProfile etc. This category also include FreePointer which is necessary for safe memory management.
- **Application Experiments** - auxiliary functionality that augments the Cwtch application with new features e.g. Server Hosting etc.
- **Core Profile Management** - core non-experimental functionality that requires a profile e.g. ImportBundle, SendMessage etc. These apis take a handle in addition to the parameters needed to call the underlying function.
- **Experimental Profile Features** auxiliary functionality that augments profiles with additional features e.g. ShareFile, SetProfileImage etc. These apis also take a handle.
The flip side of the bindings is the event bus handing which is responsible for maintaining a queue for the downstream application. This queue provides some filtering and enhancement of events to improve performance. This queue can be moved entirely into Application with only GetAppBusEvent defined and exposed in the bindings.
In an ideal future, all of these bindings could be **generated automatically** from the Cwtchlib interface definitions i.e. there should be no special functionality in the bindings themselves. The generation would need to include C bindings (untyped with automatic checks) and the Dart library calling convention (type safe)
We can define three types of C/Java/Kotlin interface function templates:
- `ProfileMethodName(profilehandle String, args...)` which directly resolves the Cwtch Profile and calls the function.
- `ProfileExperimentalMethodName(profilehandle String, args...)` which checks the current application settings to see if the experiment is enabled, and then resolves the CwtchProfile and calls the function - else errors.
- `ApplicationExperimentalMethodName(args...)` which checks the current application settings to see if the experiment is enabled, and if so, calls the experimental application functionality.
All we need to know from CwtchLib is what methods to export to C bindings, and what template they should use. This can be automatically derived from the context `ProfileInterface` for the first, exported methods of the various `Functionalities` for the second, and `ApplicationExperiment` definitions for the third.
## Timelines and Next Actions
- **Freeze any changes to the bindings interface** - we have made minimal changes to the bindings in the Cwtch 1.9 and 1.10 until we have implemented the proposed changes into cwtchlib.
- As part of Cwtch 1.11 and 1.12 Release Cycles
- Implement the `ProtocolEngine` Subsystem Design as outlined above.
- Implement the Hooks API.
- Move all special behaviour / extra functionalities in the libcwtch-go bindings into cwtchlib with the exception of behaviour related to Application Experiments (i.e. Server Hosting).
- Move event handling from the bindings into Application.
- Move Application Experiments defined in bindings into their own libraries (or integrate them into existing libraries like cwtch-server) keeping the existing interface definitions.
- Once Automated UI Tests have been integrated into the Cwtch UI Repository:
- Write a generate-cwtch-bindings tool that auto generates the libcwtch-go C/Android bindings **and** a dart calling convention library from cwtchlib and any configured application experiments libraries
- Port the existing UI app to use the newly generated dart Cwtch library (this must wait until we have automated UI testing as part of the build process to ensure that there are no regressions during this process).
- At this point the bindings are based off of the generated library and libcwtch-go is deprecated / replaced with automatically generated and versioned bindings.
As these changes are made, and these goals met we will be posting about them here! Subscribe to our [RSS feed](/blog/rss.xml), [Atom feed](/blog/atom.xml), or [JSON feed](/blog/feed.json) to stay up to date, and get the latest on, all Cwtch development.
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)
## Appendix A: Special Behaviour Defined by libcwtch-go
The following is an exhaustive list of functionality currently provided by libcwtch-go bindings instead of the cwtchlib:
- Application Settings
- Including Enabling / Disabling Experiment
- ACN Process Management - starting/stopping/restarting/configuring Tor.
- Notification Handling - augmenting/suppressing/augmenting interesting event notifications (primarily for Android)
- Logging Levels - configuring appropriate logging levels (e.g. `INFO` or `DEBUG`)
- Profile Images Helper Functions - handling default profile images for contacts and groups, in addition to looking up custom profile images if the experiment is enabled.
- UI Contact Structures - aggregating contact information for the main Cwtch UI.
- Group Experiment Functionality
- Experiment Gating
- GetServerInfoList
- GetServerInfo
- UI Server Struct Definition
- Server Hosting Experiment Functionality - creating/deleting/managing the server hosting experiment for desktop Cwtch clients.
- "Unencrypted" Profile Handling - replacing a blank password with a default password where the underlying API expects a password but the profile has been designated "unencrypted".
- Image Previews Experiment Handling - automatically starting the downloading of certain file types (when the experiment is enabled).
- Cwtch UI Reconnection Handling (for Android) - restarting various Cwtch subsystems when the UI attempts to reconnect in circumstances where the Android kernel has killed the underlying process.
- Cwtch Profile Engine Activation - starting/stopping a `ProtocolEngine` when requested by the UI, or in response to changes in ACN state.
- UI Profile Aggregation - aggregating information related to Profiles for the UI (e.g. network connection status / unread messages) into a single event.
- File sharing restarts
- UI Event Augmentation - augmenting various internal Cwtch events with information that the UI needs but that isn't directly embedded within the event (e.g. converting `handle` to a `conversation id`). Much of this augmentation is legacy, implemented before recent changes to internal Cwtch structs, and likely can either be removed entirely, or delegated into Cwtch itself.
- Debug Information - special information available to Cwtch debug builds (memory use / active goroutines etc.)

View File

@ -0,0 +1,129 @@
---
title: Making Cwtch Bindings Reproducible
description: "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."
slug: cwtch-bindings-reproducible
tags:
- cwtch
- cwtch-stable
- reproducible-builds
- bindings
- repliqate
image: /img/devlog3_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
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.
<!--truncate-->
## How Cwtch Bindings are Built
Since we launched Cwtch Beta we have used Docker containers as part of our continuous build process.
When a new change is merged into the repository it kicks off the Cwtch bindings build pipeline which result in the new source tree being downloaded, inspected, compiled, tested, and eventually packaged for different platforms.
The Cwtch Bindings build pipeline results in four compiled libraries:
- **libcwtch.so** For Linux Platforms, built using the [official golang:1.19.X Docker Image](https://hub.docker.com/_/golang)
- **libcwtch.dll** For Windows Platforms, built using our own [mingw-go Docker Image](https://git.openprivacy.ca/openprivacy/mingw-go)
- **libcwtch.ld** For OSX Platforms, built using our dedicated OSX build server (Big Sur 11.6.1)
- **cwtch.aar** For Android Platforms, built using our own [Android/GoMobile Docker Image](https://git.openprivacy.ca/openprivacy/android-go-mobile)
These compiled libraries eventually make their way into Cwtch-based applications, like the Cwtch UI.
## Making libCwtch Reproducible
Docker containers alone aren't enough to guarantee reproducibility. On inspection of several builds of the same source tree, we noticed a few elements that were distinct to each build:
* **Go Build ID**: By default, Go includes a build ID as part of compiled binaries. When using CGO this build ID is non-deterministic and differs for every build. We made the decision to override this build ID for all outputs, setting it to the version of the code being built.
* **Build Paths and Go Environment Variables**: By default, Go includes full filesystem paths, and many Go-specific environment variables in the compiled binary ostensibly to aid with debugging. These can be removed using the `trimPath` option, which we now specify for all bindings builds.
### Linux Specific Considerations
After the general fixes for Go builds are applied, the main variable input that impacts reproducibility is the version of libc that the bindings are compiled against.
Our Drone/Docker build environments are based on [Debian Bullseye](https://www.debian.org/releases/bullseye/) which provides [libc6-dev version 2.31](https://packages.debian.org/bullseye/i386/libc6-dev). Other development setups will likely link libc-dev 2.34+.
libc6-dev 2.34 is notable [because it removed dependencies on libpthread and libdl](https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread) neither are used in libCwtch, but they are currently referenced which increases the number of sections (and thus the virtual addresses of those sections) defined in the produced ELF file.
This means that in order to reproduce libCwtch Linux bindings it is necessary to have a development environment that will link libc 2.31. We have provided a small, standalone environment which can be used for this purpose (see the section on [Next Steps](#next-steps) for more information).
### Windows Specific Considerations
The headers of PE files technically contain a timestamp field. In recent years an [effort has been made to use this field for other purposes](https://devblogs.microsoft.com/oldnewthing/20180103-00/?p=97705), but by default `go build` will still include the timestamp of the file when producing a DLL file (at least when using CGO).
Fortunately this field can be zeroed out through passing `-Xlinker no-insert-timestamp` into the `mingw32-gcc` process.
With that, and the universal Go fixes outlined above, Windows bindings are now reproducible using the same standalone Linux environment.
### Android Specific Considerations
With the above universal Go fixes, Android build artifacts become almost repeatable. And on certain setups they appear to be reproducible. However,achieving full reproducibility for Android builds requires a number of specific environment dependencies, and considerations:
* Cwtch makes use of [GoMobile](https://github.com/golang/mobile) for compiling Android libraries. We pin to a specific version `43a0384520996c8376bfb8637390f12b44773e65` in our Docker containers. Unlike `go build`, the `trimpPath` parameter passed to GoMobile does not strip all development environment paths. This means that the build environment needs consistent directory structures. We have noticed inconsistencies in the detail stripped between setups e.g. cwtch.aar files build by our Docker and Repliqate builds still contain randomized `/tmp/go-build*` references that developer builds do not. We are still in the process of tracking down how these inconsistencies are introduced.
* We still use [sdk-tools](https://developer.android.com/studio/releases/sdk-tools) instead of the new [commandline-tools](https://developer.android.com/studio/command-line). The latest version of sdk-tools is `4333796` and available from: [https://dl.google.com/android/repository/sdk-tools-linux-4333796.zip](https://dl.google.com/android/repository/sdk-tools-linux-4333796.zip). As part of our plans for Cwtch Stable we will be updating this dependency.
* Cwtch Android builds currently use OpenJDK 8, unchanged from the earliest prototypes when Android development required Java 8. There is no nice way of obtaining this JDK version anymore, our Docker Containers are based on the now deprecated `openjdk:8` image. As with sdk-tooks, as part of our plans for Cwtch Stable we will be updating this dependency.
All of the above mean that we cannot consider Android builds to be reproducible yet, but we believe this is an achievable goal within the next couple of release cycles.
### OSX Specific Considerations
Perhaps surprisingly, OSX builds present the biggest reproducibility challenge. Unlike Linux, Windows, and Android builds we do not have a Dockerized build environment for OSX builds - relying instead on a dedicated machine to perform the builds.
As with Linux above, the general fixes for setting Go build id and trimming paths are enough to ensure repeatability on the same machine.
In order to fully guarantee reproducibility, OSX libraries need to be built on the same version of OSX with the same version of Xcode. For reference our current build system uses: Big Sur 11.6.1 with Xcode version 13.2.1.
In an ideal world we would be able to cross-compile OSX libraries on Linux the same way we do for Windows and Android. While there are no technical limits, compiling for OSX is dependent on a [proprietary SDK](https://www.apple.com/legal/sla/docs/xcode.pdf). There is no way to trustfully obtain this SDK from anyone except Apple, and the license appears to strictly prohibit transferring the SDK to non-Apple hardware.
Because of these limitations we cannot yet offer a way to automatically verify OSX builds, in the same way that we can for Linux, Windows, and Android. We will continue to look for ways to bring OSX builds to the same level as the rest of our Windows and Linux distributions.
## Introducing Repliqate!
With all the above changes, **Cwtch Bindings for Linux and Windows are fully reproducible!**
That alone is great, but we also want to make it easier for **you** to check the reproducibility of our builds yourself! As we noted in the introduction, the whole point of reproducible builds is that you no longer have to trust binaries provided by the Cwtch Team.
To make this process accessible we are releasing a new tool called [repliqate](https://git.openprivacy.ca/openprivacy/repliqate).
Repliqate makes it easy to construct isolated build environments, powered by Qemu and a standard Debian Cloud Image distribution.
Repliqate runs [build-scripts](https://git.openprivacy.ca/openprivacy/repliqate#writing-a-build-script) to perform actions like downloading the specific versions of Go used in Cwtch official builds, grabbing a copy of the source code for Cwtch bindings, compiling the latest tagged version, and checking the hash against the same version that is available from [builds.openprivacy.ca](https://build.openprivacy.ca/files/).
We now provide [Repliqate build-scripts](https://git.openprivacy.ca/cwtch.im/repliqate-scripts) for reproducible both [Linux libCwtch.so builds](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/libcwtch.v1.10.2-linux.script), [Windows libCwtch.dll builds](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/libcwtch.v1.10.2-windows.script)!
We also have a partially repeatable [Android cwtch.aar build](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/libcwtch.v1.10.2-android.script) script that reproduces the official build environment, which we will be using to complete Android reproducible builds as detailed in the last section.
You can (and I want to highly encourage you to) perform all these steps yourself (either via Repliqate, or a setup with the same specifications) and report back. We want to know if there are any other barriers to reproducing Cwtch bindings, and anything that we can do to make the process easier.
## Next Steps
Reproducible bindings are a big achievement, but there is obviously much more to do. In the coming weeks we are committed to undertaking the same process with our Cwtch UI builds to determine what needs to be done to make this as reproducible as bindings.
As we go through this process we also expect to add additional functionality to Repliqate. If you have any feedback or would like to contribute to Repliqate development then please get in touch!
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,166 @@
---
title: Cwtch UI Platform Support
description: "This development log captures the current state of Cwtch platform support, and how we plan to make platform support decisions going forward are we move towards Cwtch Stable."
slug: cwtch-platform-support
tags:
- cwtch
- cwtch-stable
- support
image: /img/devlog4_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
One of the [tenets for Cwtch Stable is **Universal Availability and Cohesive Support**](https://docs.cwtch.im/blog/path-to-cwtch-stable#tenets-of-cwtch-stable):
> "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?
![](/img/devlog4.png)
<!--truncate-->
## Constraints on support
From CPU architecture, to app store policies, there are a large number of constraints that restrict what platforms Cwtch can target, and how usable Cwtch may be on those systems.
In this section we will highlight the restrictions that we are aware of, and provide a summary of the major external forces that impact our ability to support Cwtch across various platforms.
### Limitations on general-purpose computing
In order for Cwtch to work, and be useful, it needs the ability to launch and manage long-lived onion services (in addition to Tor connections to *other* onion services).
On desktop platforms this is usually a given, but the ability to do that kind of activity on mobile operating systems is severely limited or, in many cases, **blocked entirely**.
This is the core reason why Cwtch is not available on iOS, and the main reason why Android support often lags behind.
While we expect that [Arti](https://gitlab.torproject.org/tpo/core/arti) will improve the management of onion services and connections, there is no way around the need to have an active process managing such services.
As Appstore restrictions are tightened, and mobile operating systems are likewise restricted, we expect that Cwtch on mobile will have to move to a light-client model, requiring the aid of a companion desktop application to be usable.
We encourage you to support mobile operating system vendors who understand the value of general purpose computing, and who don't place restrictions on what you can do with your own device.
### Constraints introduced by the Flutter SDK
The Cwtch UI is based on Flutter, and as such we have some hard boundaries driven by [platforms that are supported by the Flutter SDK](https://docs.flutter.dev/development/tools/sdk/release-notes/supported-platforms).
To summarize, as of writing this document those platforms are:
- Android API 16 and above (arm, arm64, and amd64)
- Debian-based Linux Distributions (64-bit only)
- macOS El Capitan (10.11) and above
- Windows 7 & above (64-bit only)
To put it plainly, without porting Cwtch UI to a different UI platform **we cannot support a 32-bit desktop version**.
### Constraints introduced by Appstore Policy
As of writing, [Google is pushing applications to target API 31 or above](https://developer.android.com/google/play/requirements/target-sdk). This target API version is increased on a regular cadence and usually packaged with greater restrictions on what applications can do. To put it another way, even if our minimum theoretical supported Android version is 16, we are practically limited to a subset of tolerated functionality.
### CPU Architecture and Cwtch Bindings
We currently build the Cwtch UI and Cwtch Bindings for a wide variety of platform/architecture combinations (see the table below). Our ability to support a given architecture is driven primarily by the overlap of Go Compiler support, Flutter SDK support, and what architectures the underling operating system is available for.
It is worth noting that there is an explicit dependency between the Bindings and the UI. If we cannot build Cwtch Bindings for a given architecture (i.e. if the Go Compiler does not support a given architectures), then we also cannot offer the Cwtch UI for that architecture.
| Architecture / Platform | Windows | Linux | macOS | Android |
| ------------------------ | ------- | ----- | ----- | ------- |
| arm | ❌ | ❌ | ❌ | ✅️ |
| arm64 | ❌ | 🟡 | ✅ | ✅️ |
| x86-64 / amd64 | ✅ | ✅ | ✅️ | ✅️ |
"🟡" - indicates that support is possible, but not yet official e.g. arm64 linux (Raspberry Pi).
### Testing and official support
As a non-profit, and an open source software project, we are limited in the resources we have to invest. We rely on the [Cwtch Release Candidate Testers](https://docs.cwtch.im/docs/contribute/testing#join-the-cwtch-release-candidate-testers-group) to do much of the heavy lifting when it comes to Cwtch support on various platforms. This is especially true when it comes to Android variants where, even after testing across the spread of devices available to the Cwtch team, testers still encounter major issues.
We officially only perform full scale automated tests on Linux. With minimal platform regression tests on Windows, Android and OSX. Prior to Cwtch Stable we plan to have support for running automated regression tests across Linux, Windows and Android instances.
### End-of-life platforms
Operating Systems are never supported indefinitely. The Flutter SDK may allow support for Windows 7, but Microsoft no longer does. [Windows 7 fell out of support on January 14, 2020](https://www.microsoft.com/en-us/windows/end-of-support), Windows 8 followed early this month, on January 10th. 2023. Windows 10 will no longer be support after October 14, 2025.
Likewise, while the Flutter SDK official supports OSX versions back to El Capitan (version 10.11), the oldest OSX version currently supported by Apple is Big Sur (version 11). While it may be possible for us to build different versions of Cwtch targeting different OSX versions, we would be doing so against unsupported SDK versions - incurring not only a support cost, but a possible security one also.
The same fundamental restrictions also impact Linux based distributions. While Flutter supports Ubuntu 18.04, and the platform still receiving updates until April 2023, the Cwtch team does not, because of the outdated version of libc installed on the platform would require a distinct build process. [Cwtch currently requires libc 2.31+](https://docs.cwtch.im/blog/cwtch-bindings-reproducible#linux-specific-considerations).
Android versions prior to Android 10 are no longer officially support, and the requirement to target the most recent versions of Android for inclusion on the Google Playstore mean that long term support for Android versions is driven almost entirely by Google. While Flutter technically has support for Android 16 and above (and we target that as a minimum SDK version), because we have to target the most recent SDK for inclusion on Google Playstore, we cannot make guarantees that these SDKs are fully backwards compatible. We encourage volunteers interested in Cwtch Android to join our [Cwtch Release Candidate Testers groups](https://docs.cwtch.im/docs/contribute/testing#join-the-cwtch-release-candidate-testers-group) to help us understand the limitations of Android support across different API versions.
## How we decide to officially support a platform
To help make decisions on what platforms we target for official builds, the Cwtch team have developed four key tenets:
1. **The target platform needs to be officially supported by our development tools** - We do not have the resources to maintain forks of the Go compiler or the Flutter SDK that target other operating systems or architectures. The one exception to this rule are non-Debian Linux distributions which while not officially supported by Flutter, are unlikely to have major blockers to official support.
2. **The target operating system needs to be supported by the Vendor** - We cannot support a platform that is no longer receiving security updates. Nor do we have the resources to maintain distinct build environments that target out-of-support operating systems. While Cwtch may run on these platforms without additional assistance, we will not schedule work to fix broken support on such platforms. (We may, however, accept Pull Requests from volunteers).
3. **The target platform must be backwards compatible with the most recent version in general use** - Even if a system is technically supported by our development tools, and still receives security updates from the vendor, we may still be unbale to officially support it if doing so requires maintaining a separate build environment (because SDK or APIs of dependent libraries are no longer backwards compatible). Like above, Cwtch *may* run on these platforms without additional assistance, but we will not schedule work to fix broken support on such platforms. (we may, however, accept Pull Requests from volunteers).
4. **People want to use Cwtch on that platform** - We will generally only consider new platform support if people ask us about it. If Cwtch isn't available for a platform you want to use it on, then please get in touch and ask us about it!
## Summary of official support
The table below represents our current understanding of Cwtch support across various operating systems and architectures (as of Cwtch 1.10 and January 2023).
In many cases we are looking for testers to confirm that various functionality works. A version of this table will be [maintained as part of the Cwtch Handbook](/docs/getting-started/supported_platforms).
**Legend:**
- ✅: **Officially Supported**. Cwtch should work on these platforms without issue. Regressions are treated as high priority.
- 🟡: **Best Effort Support**. Cwtch should work on these platforms but there may be documented or unknown issues. Testing may be needed. Some features may require additional work. Volunteer effort is appreciated.
- ❌: **Not Supported**. Cwtch is unlikely to work on these systems. We will probably not accept bug reports for these systems.
| Platform | Official Cwtch Builds | Source Support | Notes |
| --------------------------- | --------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Windows 11 | ✅ | ✅ | 64-bit amd64 only. |
| Windows 10 | ✅ | ✅ | 64-bit amd64 only. Not officially supported, but official builds may work. |
| Windows 8 and below | ❌ | 🟡 | Not supported. Dedicated builds from source may work. Testing Needed. |
| OSX 10 and below | ❌ | 🟡 | 64-bit Only. Official builds have been reported to work on Catalina but not High Sierra |
| OSX 11 | ✅ | ✅ | 64-bit Only. Official builds supports both arm64 and x86 architectures. |
| OSX 12 | ✅ | ✅ | 64-bit Only. Official builds supports both arm64 and x86 architectures. |
| OSX 13 | ✅ | ✅ | 64-bit Only. Official builds supports both arm64 and x86 architectures. |
| Debian 11 | ✅ | ✅ | 64-bit amd64 Only. |
| Debian 10 | 🟡 | ✅ | 64-bit amd64 Only. |
| Debian 9 and below | 🟡 | ✅ | 64-bit amd64 Only. Builds from source should work, but official builds may be incompatible with installed dependencies. |
| Ubuntu 22.04 | ✅ | ✅ | 64-bit amd64 Only. |
| Other Ubuntu | 🟡 | ✅ | 64-bit Only. Testing needed. Builds from source should work, but official builds may be incompatible with installed dependencies. |
| CentOS | 🟡 | 🟡 | Testing Needed. |
| Gentoo | 🟡 | 🟡 | Testing Needed. |
| Arch | 🟡 | 🟡 | Testing Needed. |
| Whonix | 🟡 | 🟡 | [Known Issues. Specific changes to Cwtch are required for support. ](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/550) |
| Raspian (arm64) | 🟡 | ✅ | Builds from source work. |
| Other Linux Distributions | 🟡 | 🟡 | Testing Needed. |
| Android 9 and below | 🟡 | 🟡 | Official builds may work. |
| Android 10 | ✅ | ✅ | Official SDK supprts arm, arm64, and amd64 architectures. |
| Android 11 | ✅ | ✅ | Official SDK supprts arm, arm64, and amd64 architectures. |
| Android 12 | ✅ | ✅ | Official SDK supprts arm, arm64, and amd64 architectures. |
| Android 13 | ✅ | ✅ | Official SDK supprts arm, arm64, and amd64 architectures. |
| LineageOS | 🟡 | 🟡 | [Known Issues. Specific changes to Cwtch are required for support.](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/607) |
| Other Android Distributions | 🟡 | 🟡 | Testing Needed. |
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,88 @@
---
title: Notes on Cwtch UI Testing
description: "In this development log we provide an update on automated UI integration testing!"
slug: cwtch-testing-i
tags:
- cwtch
- cwtch-stable
- support
- testing
image: /img/devlog5_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
We first [introduced UI tests last January](https://openprivacy.ca/discreet-log/23-cucumber-testing/). 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](https://docs.cwtch.im/blog/path-to-cwtch-stable) 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.
![](/img/devlog5.png)
<!--truncate-->
## Current Limitations of Flutter Gherkin
The original [flutter_gherkin](https://pub.dev/packages/flutter_gherkin) is under semi-active development; however, the latest published versions don't support using it with `flutter test`.
- **Flutter Test** was originally intended to run single widget/unit tests for a Flutter project.
- **Flutter Drive** was originally intended to run integration tests *on a device or an emulator*.
However, in recent releases these lines have become blurred. The new [integration_test](https://docs.flutter.dev/testing/integration-tests) package that comes built into newer Flutter releases has support for both `flutter drive` and `flutter test`. This was a great change because it decreases the required overhead to run larger integration tests (`flutter drive` sets up a host-controller model that requires a dedicated control channel to be setup, whereas `flutter test` can take advantage of the knowledge that it is being run in the same process, and is noticeably faster - very important when the goal is to run tests as often as possible).
There is thankfully code in the `flutter_gherkin` repository that supports running tests with `flutter test`, however this code currently has a few issues:
- The test code generation produces code that doesn't compile without minor changes.
- Certain functionality like "take a screenshot" does not work on desktop.
Additionally, there are a few limitations in built-in flutter_gherkin steps that we noticed our tests running into:
- Certain tests that fail with async timeouts will cause Flutter exceptions instead of a failed test.
- Certain Flutter widgets like `DropdownButton` are not compatible with built-in steps like `tap` because they internally contain multiple copies of the same widget.
Because of the above issues we have chosen to [fork flutter_gherkin](https://git.openprivacy.ca/openprivacy/flutter_gherkin) to fix some of these issues, with the intent of contributing significant fixes upstream, while allowing us to iterate faster on Flutter UI testing.
## Integrating Tests into the Pipeline
One of the major limitations of `flutter test` is the lack of a headless mode. In order to successfully run tests in our pipeline we need a headless mode, as most of the containers we use do not have any kind of active display.
Thankfully it is possible to use [Xfvb](https://en.wikipedia.org/wiki/Xvfb) to create a virtual framebuffer, and set `DISPLAY` to render to that buffer:
export DISPLAY=:99
Xvfb -ac :99 -screen 0 1280x1024x24 > /dev/null 2>&1 &
This allows us to neutralize our main issue with `flutter test`, and efficiently run tests in our pipeline.
## Catching Bugs!
This small amount of integration work has already caught its first bug.
Once we had fixed most of the issues outlined above, we were still seeing failures on what should have been a very basic scenario. [02_save_load.feature](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/integration_test/features/01_general/02_save_load.feature) simply turns a set of experiments on and checks that the state is saved. This test runs perfectly fine on development environments, but when uploaded to our build pipeline it always failed in the same place - turning on the file sharing experiment.
The cause of this was an actual bug in Cwtch UI. The file sharing experiment failed to turn on if the directory `$USER_HOME/Downloads` didn't exist. This is rarely the case on most real world systems, but is the case in our build pipelines. We have since fixed this behaviour to allow file sharing to be turned on even if the usual Download directories are not available.
As we enable more of our UI tests in our pipeline, and across more platforms, we expect to catch more subtle issues like the above - a big win for people who use Cwtch!
## Next Steps
- **More automated tests:** We have a nice collection of pre-written tests that we can begin to automatically run within pipelines. We have already begun this work, and anticipate finishing it before Cwtch 1.11.
- **More platforms:** Right now UI tests only run on Linux. In order to fully take advantage of these tests we need to be able to run them across [our target platforms](https://docs.cwtch.im/docs/getting-started/supported_platforms). We expect to start this work soon; expect more news in a future Cwtch Testing update!
- **More steps:** One of our longer-term goals with UI testing was to produce a language around Cwtch testing that went beyond widgets. We had begun to explore this last year with the `expect to see the message` step. As we grow our test library we will be looking for opportunities to build out additional higher-level and Cwtch-specific constructs, e.g. `send a file` or `set profile picture`.
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,60 @@
---
title: Making Cwtch Android Bindings Reproducible
description: "In this devlog we revisit reproducible builds and make Cwtch Android bindings reproducible"
slug: cwtch-android-reproducibility
tags:
- cwtch
- cwtch-stable
- reproducible-builds
- bindings
- repliqate
image: /img/devlog6_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
In this development log, we continue our previous work on [reproducible Cwtch bindings](https://docs.cwtch.im/blog/cwtch-bindings-reproducible), uncovering the final few sources of variation between our [Repliqate](https://git.openprivacy.ca/openprivacy/repliqate) scripts and our docker/drone builds, leading to fully reproducible builds for Cwtch Android bindings!
![](/img/devlog6.png)
<!--truncate-->
## Changes Necessary for Reproducible Android Bindings
After a thorough investigation of the build artifacts produced by Repliqate and Drone we uncovered three additional sources of variation:
- **Insufficient path stripping introduced by Android NDK tools** - it turns out that Android builds using NDK versions below 22 are not reproducible as they produce randomized artifacts (through unstripped temporary directory paths appearing in compiled binares). NDK 22 [changed the binutils and default linker](https://github.com/android/ndk/wiki/Changelog-r22) to versions that correctly strip such paths from build artifacts. As such it was necessary for us to update the NDK version we used. We chose the technically outdated NDK 22 rather than the more modern NDK 25 to minimize Android OS compatibility changes during this switch. However, per our [long term support plan](https://docs.cwtch.im/blog/cwtch-platform-support), we will be moving towards adopting the latest NDK in the future.
- **Paths in DWARF entries** - while we have been unable to track down exactly where these are being introduced, we did track the final difference in the produced bindings to DWARF debug lines embedded in compiled ELF binaries. These entries encoded the actual location of the NDK on the disk of the build machine, instead of the symbolic link that we believed should have been followed. By physically placing the NDK at same location in repliqate as in our Docker container we were able to get these entries to be consistent - however there is still work to do to understand exactly why they are being introduced at all.
<figure>
[![](/img/aar-diff.png)](/img/aar-diff.png)
<figcaption>Vimdiff comparing the decoded (<code>readelf --debug-dump=line</code>) DWARF debug section of Drone-produced Android bindings v.s. Repliqate-produced. The difference in paths is highlighted.</figcaption>
</figure>
- **Go Compiler Acquisition** - our Docker container was compiling the Go compiler from source, while Repliqate was downloading a pre-compiled version. During debugging we changed the Dockerfile to also download the pre-compiled version in order to eliminate the difference as a potential reproducibility issue. Our tests indicated that there *was* a difference between artifacts produced by the precompiled compiler v.s. one built from source - this is likely explained by introduced environmental differences caused by the compilation of the compiler itself e.g. the contents/versions of modules in the Go package cache which we have seen as having an impact on other produced binaries.
## Repliqate Scripts
With those issues now fixed, Cwtch Android bindings are **officially reproducible!** The first version that officially met this requirement was 1.10.5, and you can find the Repliqate script under [cwtch-bindings-v1.10.5/libcwtch.v1.10.5-android.script](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/cwtch-bindings-v1.10.5/libcwtch.v1.10.5-android.script) in the [Cwtch Repliqate scripts repository](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/).
This is another big milestone towards our ultimate goal of full reproducibility for Cwtch releases.
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,71 @@
---
title: Notes on Cwtch UI Testing (II)
description: "In this development log we provide more updates on automated UI integration testing!"
slug: cwtch-testing-ii
tags:
- cwtch
- cwtch-stable
- support
- testing
image: /img/devlog7_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
In this development log, we investigate some text-based UI bugs encountered by [Fuzzbot](https://docs.cwtch.im/docs/contribute/testing#running-fuzzbot), add more [automated UI tests](/blog/cwtch-testing-i) to the pipeline, and announce a new release of the Cwtchbot library.
![](/img/devlog7.png)
<!--truncate-->
## Constraining Cwtch UI Fields
Fuzzbot identified a few bugs relating to UI layout and text clipping. Certain strings would violate the bounds of their containers and overlap with other UI elements. While this doesn't pose a safety issue, it is unsightly.
<figure>
[![](/img/dl7-before.png)](/img/dl7-before.png)
<figcaption>Screenshot demonstrating how certain strings would violate the bounds of their containers.</figcaption>
</figure>
These cases were fixed by parenting impacted elements in a `Container` with `clip: hardEdge` and `decoration:BoxDecoration()` (note that both of these are required as Container widgets in Flutter cannot set clipping logic without an associated decoration).
<figure>
[![](/img/dl7-after.png)](/img/dl7-after.png)
<figcaption>Now these clipped strings are tightly constrained to their container bounds.</figcaption>
</figure>
These fixes are available in the [latest Cwtch Nightly](/docs/contribute/testing#cwtch-nightlies), and will be officially released in Cwtch 1.11.
## More Automated UI Tests
We have added two new sets of automated UI tests to our pipeline:
- *02: Global Settings* - these tests check that certain global settings like languages, theme, unknown contacts blocking, and streamer mode work as expected. ([PR: 628](https://git.openprivacy.ca/cwtch.im/cwtch-ui/pulls/628))
- *04: Profile Management* - these tests check that creating, unlocking, and deleting a profile work as expected. ([PR: 632](https://git.openprivacy.ca/cwtch.im/cwtch-ui/pulls/632))
## New Release of Cwtchbot
[Cwtchbot](https://git.openprivacy.ca/sarah/cwtchbot) has been updated to use the latest Cwtch 0.18.10 API.
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,93 @@
---
title: Autogenerating Cwtch Bindings
description: "In this development log we describe a first-cut of a workflow to automatically generate Cwtch C and Java bindings from a high-level specification."
slug: autobindings
tags:
- cwtch
- cwtch-stable
- bindings
- autobindings
- libcwtch
image: /img/devlog8_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
The C-bindings for Cwtch evolved as part of Cwtch UI development. After two years of prototyping, development, new features, and revisiting first-implementations we have reached the point where we have a good understanding of what the bindings need to do, and how they should do it. To that end we have produced a first-cut of a workflow to **automatically generate** these bindings: [cwtch-autobindings](https://git.openprivacy.ca/cwtch.im/autobindings).
This this development log we will introduced autobindings, the motivation behind them, and how we plan to use them on the [path to Cwtch Stable](https://docs.cwtch.im/blog/path-to-cwtch-stable).
![](/img/devlog8.png)
<!--truncate-->
## A Brief History of Cwtch Bindings
Prior to the modern Flutter-based UI application, the first Cwtch UI prototype was based on Qt, with the bindings automatically generated by [therecipe/qt](https://github.com/therecipe/qt). However, after encountering numerous crash-bugs on the compiled Arm version for Android, and a few weeks of prototyping different approaches, we settled on Flutter as a replacement UI framework.
As part of early prototyping efforts for Flutter we built out a first version of [libCwtch-go](https://git.openprivacy.ca/cwtch.im/libcwtch-go), and over the two years of beta development we have evolved that prototype into a functional set of Cwtch bindings.
This approach has not been without side effects. There is still code from those early prototypes floating around in libCwtch-go, inconsistencies in how functions - in particular [experimental features](https://docs.cwtch.im/blog/cwtch-stable-api-design#the-cwtch-experiment-landscape) - handle settings, [duplication of logic between Cwtch and libCwtch-go](https://docs.cwtch.im/blog/cwtch-stable-api-design#bindings), and [special behaviour in libCwtch-go that better belongs in the core Cwtch library](https://docs.cwtch.im/blog/cwtch-stable-api-design#appendix-a-special-behaviour-defined-by-libcwtch-go).
As part of a broader effort to [refine the Cwtch API in preparation for Cwtch Stable](https://docs.cwtch.im/blog/cwtch-stable-api-design) we have taken the opportunity to fix many of these problems.
## Cwtch Autobindings
The current `lib.go` file that encapsulates the vast majority of libCwtch-go currently sits at 1500+ lines of code. However, much of that code is boilerplate calling conventions e.g. the `BlockContact` API implementation is:
//export c_BlockContact
func c_BlockContact(profilePtr *C.char, profileLen C.int, conversation_id C.int) {
BlockContact(C.GoStringN(profilePtr, profileLen), int(conversation_id))
}
func BlockContact(profileOnion string, conversationID int) {
profile := application.GetPeer(profileOnion)
if profile != nil {
profile.BlockConversation(conversationID)
}
}
All that code is doing is defining a C-compatible API, performing some basic checking of parameters, and passing the result into the core Cwtch library. The two functions themselves support the C-bindings and Java-bindings respectively.
In the new [cwtch-autobindings](https://git.openprivacy.ca/cwtch.im/autobindings) we reduce these multiple lines to [a single one](https://git.openprivacy.ca/cwtch.im/autobindings/src/branch/main/spec#L19):
profile BlockConversation conversation
Defining a `profile`-level function, called `BlockConversation` which takes in a single parameter of type `conversation`.
Using a similar boilerplate-reduction for the reset of `lib.go` yields [5-basic function prototypes](https://git.openprivacy.ca/cwtch.im/autobindings/src/branch/main/README.md#spec-file-format):
* Application-level functions e.g. `CreateProfile`
* Profile-level functions e.g. `BlockConversation`
* Profile-level functions that return data e.g. `GetMessage`
* Experimental Profile-level feature functions e.g. `DownloadFile`
* Experimental Profile-level feature functions that return data e.g. `ShareFile`
Once aggregated and itemized the full set of bindings for Cwtch applications, profile interactions, and experiments can be [described in fewer than 50 lines, including comments](https://git.openprivacy.ca/cwtch.im/autobindings/src/branch/main/spec). Even including the code necessary to generate the bindings from this specification file (~400 lines), and the code needed to initialize the bindings themselves (~300 lines). This cuts the amount of coded needed by 60%, and eliminates many classes of error and inconsistencies associated with maintaining bindings (e.g. regularizing function calls / checking experiment status / handling error conditions etc.).
## Next Steps
Cwtch autobindings work today, are API-compatible with the existing libCwtch-go implements, and can be fully integrated into an existing Cwtch application with minimal effort. However, there are a few areas which need to be addressed prior to a full rollout:
* **[Application-level experiments](https://docs.cwtch.im/blog/cwtch-stable-api-design#application-experiments)** (of which there is only one: Desktop Server Hosting) are not currently supported. This functionality is only tangentially related to the rest of the Cwtch bindings, and necessarily introduces additional dependencies (e.g. on `cwtch-server`). In the coming weeks we will allow optional application experiments to be enabled at compile time, to allow us to produce smaller bindings for platforms that don't support the experiment, and to allow us to build new kinds of platform-targeted experiments that can take advantage of platform specific features.
* **Dart Library generation**: since we now have a formal description of the bindings interface, we can move ahead with also autogenerating the [Dart-side](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/cwtch) of the bindings interface, giving a boost to UI integration of new features, and allowing us to generate tailored versions of the UI interface e.g. one compiled without experiment support. We can also extend the same logic to other downstream interfaces e.g. [libcwtch-rs](https://git.openprivacy.ca/cwtch.im/libcwtch-rs)
* **Documentation generation**: another benefit of a formal description of the bindings interface, we can easily generate documentation compatible with [docs.cwtch.im](https://cwtch.im).
* **Cwtch API**: This first cut of autobindings is based on an unreleased version of the core Cwtch library that implements much of the [Cwtch Stable API redesign](https://docs.cwtch.im/blog/cwtch-stable-api-design). In a short while we will be merging these features into Cwtch, in preparation for Cwtch 1.11, and beyond.
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,111 @@
---
title: Compile-time Optional Application Experiments (Autobindings)
description: "In this development log we document how we added compile-time optional application-level experiments to Cwtch autobindings."
slug: autobindings-ii
tags:
- cwtch
- cwtch-stable
- bindings
- autobindings
- libcwtch
image: /img/devlog8_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
[Last time we looked at autobindings](https://docs.cwtch.im/blog/autobindings) we mentioned that one of the next steps was introducing support for **[Application-level experiments](https://docs.cwtch.im/blog/cwtch-stable-api-design#application-experiments)**. In this development log we will explore what application-level experiments are (technically), and how we added (optional) autobindings support for them.
![](/img/devlog8.png)
<!--truncate-->
## The Structure of an Application Experiment
An application-level experiment consists of:
1. A set of top-level APIs, e.g. `CreateServer`, `LoadServer`, `DeleteServer` - these are the APIs that we want to expose to calling applications.
2. An encapsulating structure for the set of APIs, e.g. `ServersFunctionality` - it is much easy to manage a cohesive set of functionality if it is wrapped up in a single entity.
3. A global variable that exists at the top level of libCwtch, e.g. `var serverExperiment *servers.ServersFunctionality servers` - our single pointer to the underlying functionality.
4. A set of management-related APIs, e.g. `Init`, `UpdateSettings`, `OnACNEvent` - in the case of the server hosting experiment we need to perform specific actions when we start up (e.g. loading unencrypted hosted servers), and when settings are changed (e.g. if the server hosting experiment is disabled we need to tear down all active servers).
5. Management code within `_startCwtch` and `_reconnectCwtch` that calls the management APIs on the global variable.
From a code generation perspective we already have most of the functionality is place to support (1) - the one major difference being that we need to wrap function calls on the global variable associated with the experiment, instead of on `application` or a specific `profile`.
Most of the effort required to support optional experiments was focused on optionally weaving experiment management code within the template.
### New Required Management APIs
To achieve this weaving, we now require application-level experiments to implement an `EventHandlerInterface` interface and expose itself via an initialize constructor `Init(acn, appDir) -> EventHandlerInterface`, and `Enable(app, acn)`.
For now this interface is rather minimal, and has been mapped almost exactly to how the server hosting experiment already worked. If, or when, a new application experiment is required we will likely revisit this interface.
We can then generate, and optionally include blocks of code like:
<experimentGlobal> = <experimentPackage>.Init(&globalACN, appDir)
eventHandler.AddModule(<experimentGlobal>)
<experimentGlobal>.Enable(application, &globalACN)
and place them at specific points in the code. `EventHandler` has also been extended to maintain a collection of `modules` so that it can pass on interesting events.
### Adding Support for Application Experiments in the Spec File
We have introduced a new `!` operator which can be used to gate APIs behind a configured experiment. Along with a new templating option `exp` which will call the function on the configured experiment, and `global` to allow the setting up of a global functionality within the library.
# Server Hosting Experiment
!serverExperiment import "git.openprivacy.ca/cwtch.im/cwtch-autobindings/experiments/servers"
!serverExperiment global serverExperiment *servers.ServersFunctionality servers
!serverExperiment exp CreateServer application password string:description bool:autostart
!serverExperiment exp SetServerAttribute application string:handle string:key string:val
!serverExperiment exp LoadServers application acn password
!serverExperiment exp LaunchServers application acn
!serverExperiment exp LaunchServer application string:handle
!serverExperiment exp StopServer application string:handle
!serverExperiment exp StopServers application
!serverExperiment exp DestroyServers
!serverExperiment exp DeleteServer application string:handle password
### Generation-Time Inclusion
Without any arguments provided `generate-bindings` will not generate code for any experiments.
In order to determine what experimental code to generate, `generate-bindings` now interprets arguments as enabled compile time experiments, e.g. `generate-bindings serverExperiment` will turn on generation of server hosting code, per the spec file above.
### Cwtch UI Integration
The UI, and other downstream applications, can now check for support for server hosting by simply checking if the loaded library provides the expected symbols, e.g. `c_LoadServers` - if it doesn't then the UI is safe to assume the feature is not available.
<figure>
![](/img/dev9-host-disabled.png)
<figcaption>A screenshot of the Cwtch UI Settings Pane demonstrating how the Server Hosting experiment option looks when the UI is pointed to a libCwtch compiled without server hosting support.</figcaption>
</figure>
## Nightlies & Next Steps
We are now publishing [nightlies](https://build.openprivacy.ca/files/libCwtch-autobindings-v0.0.2/) of autobinding derived libCwtch-go, along with [Repliqate scripts](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/cwtch-autobindings-v0.0.2) for reproducibility.
With application experiments supported, this phase of autobindings comes to a close. The immediate next steps involve extensive testing and release candidates proving out the new bindings to ensure that no bugs have been introduced in the migration from libCwtch-go. These candidates will form the basis for Cwtch Beta 1.11.
However, there is still more work to do, and we expect to make progress on a few areas over the next few months, including:
* **Dart Library generation**: since we now have a formal description of the bindings interface, we can move ahead with also autogenerating the [Dart side](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/cwtch) of the bindings interface, giving a boost to UI integration of new features, and allowing us to generate tailored versions of the UI interface, e.g. one compiled without experiment support. We can also extend the same logic to other downstream interfaces, e.g. [libcwtch-rs](https://git.openprivacy.ca/cwtch.im/libcwtch-rs).
* **Documentation generation**: as another benefit of a formal description of the bindings interface, we can easily generate documentation compatible with [docs.cwtch.im](https://cwtch.im).
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,61 @@
---
title: Updates zur Cwtch-Dokumentation
description: "In diesem Entwicklungsprotokoll werden wir einige der wichtigsten Dokumentationsaktualisierungen der letzten Wochen hervorheben."
slug: cwtch-Dokumentation
tags:
- cwtch
- cwtch-stable
- Dokumentation
- Sicherheitshandbuch
image: /img/devlog9_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
Einer der wichtigsten Arbeitsströme auf dem Weg bis zum Cwtch Stable war die Verbesserung aller Aspekte der Cwtch Dokumentation. In diesem Entwicklungsprotokoll werden wir einige der wichtigsten Updates der letzten Wochen hervorheben.
![](/img/devlog9.png)
<!--truncate-->
## Cwtch Handbuch für sichere Entwicklung
Eines der frühesten Kompendien der Cwtch-Dokumentation war das Cwtch Handbuch für sichere Entwicklung. Dieses Handbuch bot einen Überblick über die verschiedenen Teile des Cwtch-Ökosystems, die bekannten Risiken und alle bestehenden Eindämmungen. Das Handbuch wurde als Leitfaden für Entwickler konzipiert, die Cwtch bauen oder erweitern und im Laufe der Jahre diente es auch als festes Zuhause für die Dokumentation von langjährigen Designentscheidungen.
Wir haben nun [das Handbuch zu dieser Dokumentations-Website portiert](/security/intro) und dabei Teile des Inhaltes aktualisiert. In den nächsten Monaten werden wir diesen Abschnitt um neue Abschnitte zu Fuzzing, Plugins und Client-Implementierung erweitern.
## Entwicklung Freiwilliger
Wir haben einen Aufschwung bei der Anzahl der Menschen festgestellt, die sich für die Entwicklung von Cwtch interessieren. Um den Leuten zu helfen, sich an unseren Entwicklungsfluss zu gewöhnen, haben wir einen neuen Abschnitt auf der Dokumentationsseite mit dem Namen [Cwtch Entwicklung ](/docs/contribute/developing) erstellt - dort findest du eine Sammlung nützlicher Links und Informationen, wie man mit der Cwtch Entwicklung beginnen kann. welche Bibliotheken und Werkzeuge wir verwenden, wie Pull-Requests validiert und überprüft werden und wie ein Problem ausgewählt wird, an dem gearbeitet werden soll.
Wir haben auch unsere Anleitungen zu [Cwtch übersetzen](/docs/contribute/translate) und [Cwtch testen](/docs/contribute/testing) aktualisiert.
Wenn du Interesse an der Entwicklung von Cwtch hast, dann schaue dir das an und wende dich an `team@cwtch. m` (oder öffne ein issue) mit allen Fragen. Alle Arten von Beiträgen [sind berechtigt für Aufkleber](/docs/contribute/stickers).
## Nächste Schritte
Wir haben noch mehr Arbeit an der Dokumentationsfront zu tun:
* Sicherstellung, dass alle Seiten [den neuen Dokumentationsstil-Leitfaden](/docs/contribute/documentation)implementieren und entsprechende Screenshots und Beschreibungen enthalten.
* Erweitern des Sicherheitshandbuchs, um Informationen über [reproduzierbare Builds zu liefern,](/blog/cwtch-bindings-reproducible), [die neue Cwtch Stable API](/blog/cwtch-stable-api-design) und kommende Verbesserungen rund um Fuzz Tests.
* Erstellung neuer Dokumentationsabschnitte auf der [libCwtch Autobindings API](/blog/autobindings) und Erstellung neuer Anwendungen auf Cwtch.
Da diese Änderungen vorgenommen wurden und diese Ziele erreicht wurden, werden wir sie hier veröffentlichen! Abonniere unseren [RSS-Feed](/blog/rss.xml), [Atom-Feed](/blog/atom.xml), oder [JSON-Feed](/blog/feed.json), um auf dem Laufenden zu bleiben und die aktuellsten Aspekte der Cwtch-Entwicklung zu erhalten.
## Hilf uns, weiter zu gehen!
Wir könnten nicht das tun, was wir tun ohne die wunderbare Unterstützung der Gemeinschaft, die wir erhalten, von [einmalige Spenden](https://openprivacy.ca/donate) bis [wiederkehrende Unterstützung über Patreon](https://www.patreon.com/openprivacy).
Wenn du sehen möchtest, dass wir uns bei einigen dieser Ziele schneller bewegen und in der Lage sind, bitte [spende](https://openprivacy.ca/donate). Wenn du zufällig bei einem Unternehmen bist, das mehr für die Community tun will und sich dies passt, erwäge bitte, einen Entwickler zu spenden oder zu sponsern.
Spenden in Höhe von **$5 oder mehr** können sich entscheiden, Aufkleber als Dankeschön zu erhalten!
Für weitere Informationen über die Spende an Open Privacy und das Einfordern eines Dankeschön Geschenkes [besuche bitte die Open Privacy Spenden-Seite](https://openprivacy.ca/donate/).
![Ein Foto von Cwtch-Aufklebern](/img/stickers-new.jpg)

View File

@ -0,0 +1,85 @@
---
title: Cwtch Beta 1.11
description: "Cwtch Beta 1.11 is now available for download"
slug: cwtch-nightly-1-11
tags:
- cwtch
- cwtch-stable
- release
image: /img/devlog12_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
[Cwtch 1.11 is now available for download](https://cwtch.im/download)!
Cwtch 1.11 is the culmination of the last few months of effort by the Cwtch team, and includes many foundational changes that pave the way for [Cwtch Stable](/blog/path-to-cwtch-stable) including new [reproducible](https://docs.cwtch.im/blog/cwtch-bindings-reproducible) and [automatically generated](https://docs.cwtch.im/blog/autobindings) bindings, as well as support for two new languages (Slovak and Korean), in addition to several performance improvements and bug fixes.
![](/img/devlog12.png)
<!--truncate-->
## In This Release
<figure>
[![](/img/picnic.png)](/img/picnic.png)
<figcaption>A screenshot of Cwtch 1.11</figcaption>
</figure>
A special thanks to the [amazing volunteer translators](https://docs.cwtch.im/docs/contribute/translate) and [testers](https://docs.cwtch.im/docs/contribute/testing) who made this release possible.
- **New Features:**
- **Based on new Reproducible Cwtch Stable Autobuilds** - this is the first release of cwtch based on [reproducible Cwtch bindings](https://docs.cwtch.im/blog/cwtch-bindings-reproducible) in addition to our new [automatically generated](https://docs.cwtch.im/blog/autobindings)
- **Two New Supported Localizations**: **Slovak** and **Korean**
- **Bug Fixes / Improvements:**
- When preserving a message draft, quoted messages are now also saved
- Layout issues caused by pathological unicode are now prevented
- Improved performance of message row rendering
- Clickable Links: Links in replies are now selectable
- Clickable Links: Fixed error when highlighting certain URIs
- File Downloading: Fixes for file downloading and exporting on 32bit Android devices
- Server Hosting: Fixes for several layout issues
- Build pipeline now runs automated UI tests
- Fix issues caused by scrollbar controller overriding
- Initial support for the Blodeuwedd Assistant (currently compile-time disabled)
- Cwtch Library:
- [New Stable Cwtch Peer API](/blog/cwtch-stable-api-design)
- Ported File Downloading and Image Previews experiments into Cwtch
- **Accessibility / UX:**
- Full translations for **Brazilian Portuguese**, **Dutch**, **French**, **German**, **Italian**, **Russian**, **Polish**, **Spanish**, **Turkish**, and **Welsh**
- Core translations for **Danish** (75%), **Norwegian** (76%), and **Romanian** (75%)
- Partial translations for **Luxembourgish** (22%), **Greek** (16%), and **Portuguese** (6%)
## Reproducible Bindings
Cwtch 1.11 is based on libCwtch version `2023-03-16-15-07-v0.0.3-1-g50c853a`. The [repliqate scripts](https://docs.cwtch.im/blog/cwtch-bindings-reproducible#introducing-repliqate) to reproduce these bindings from source can be found at [https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/cwtch-autobindings-v0.0.3-1-g50c853a](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/cwtch-autobindings-v0.0.3-1-g50c853a)
## Download the New Version
You can download Cwtch from [https://cwtch.im/download](https://cwtch.im/download).
Subscribe to our [RSS feed](/blog/rss.xml), [Atom feed](/blog/atom.xml), or [JSON feed](/blog/feed.json) to stay up to date, and get the latest on, all aspects of Cwtch development.
Alternatively we also provide a [releases-only RSS feed](https://cwtch.im/releases/index.xml).
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,104 @@
---
title: Cwtch Stable Roadmap Update
description: "Back in january we outlined several goals that we would have to hit on our way to Cwtch Stable, and the timelines to hit them. In this post we revisit those and announce some more"
slug: cwtch-stable-roadmap-update
tags:
- cwtch
- cwtch-stable
- planning
image: /img/devlog1_small.jpg
hide_table_of_contents: false
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
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. We have been working hard towards that goal over the last few months.
This post [revisits the Cwtch Stable roadmap](/blog/path-to-cwtch-stable) we introduced at the start of the year, and provides an overview of the next steps on our journey towards Cwtch Stable.
![](/img/devlog1.png)
<!--truncate-->
## Update on the January Roadmap
Back in January we outlined several goals that we would have to hit on our way to Cwtch Stable, and the timelines for achieving them. Now that we have reached target date of the last of these goals, we can look back and see how we did:
(✅ means complete, 🟡 means in-progress, ❌ not started.)
- By **1st February 2023**, the Cwtch team will have reviewed all existing Cwtch issues in line with this document, and established a timeline for including them in upcoming releases (or specifically commit to not including them in upcoming releases). ✅
- By **1st February 2023**, the Cwtch team will have [finalized a feature set that defines Cwtch Stable](/blog/cwtch-stable-api-design) and established a timeline for including these features in upcoming Cwtch Beta releases. ✅
- By **1st February 2023**, the Cwtch team will have expanded the Cwtch Documentation website to include a section for:
- [Security and Design Documents](/security/intro) ✅
- Infrastructure and [Support](/docs/getting-started/supported_platforms) 🟡
- in addition to a new development blog. ✅
- By **31st March 2023**, the Cwtch team will have created:
- a [style guide for documentation](/docs/contribute/documentation), and ✅
- have used it to ensure that all Cwtch features have consistent documentation available, 🟡
- with at least one screenshot (where applicable). 🟡
- By **31st March 2023** the Cwtch team will have published:
- a Cwtch [Interface Specification Document](/blog/cwtch-stable-api-design) ✅
- a Cwtch Release Process Document 🟡
- a Cwtch [Support Plan document](/blog/cwtch-platform-support) ✅
- a Cwtch Packaging Document 🟡
- a document describing the [Reproducible Builds Process](/blog/cwtch-bindings-reproducible) ✅
- These documents will be available on the newly expanded Cwtch Documentation website 🟡
- By **31st March 2023** the Cwtch team will have integrated automated UI tests into the build pipeline for the cwtch-ui repository. ✅
- By **31st March 2023** the Cwtch team will have integrated automated fuzzing into the build pipeline for all Cwtch dependencies maintained by the Cwtch team ❌
- By **31st March 2023** the Cwtch team will have committed to a date, timeline, and roadmap for launching Cwtch Stable ✅ (this post!)
While we didn't hit all of our goals, we did make progress on nearly all of them, and in addition also made progress in a few other key areas:
* [Cwtch Autobindings](/blog/autobindings) with [compile-time optional experiments](/blog/autobindings-ii)
* [Cwtch 1.11](/blog/cwtch-nightly-1-11) - with support for reproducible bindings, two new localizations (Slovak and Korean), in addition to a myriad of bug fixes and performance improvements.
* [Repliqate](https://git.openprivacy.ca/openprivacy/repliqate) - a tool for testing and confirming reproducible builds processes based on Qemu, and a Debian Cloud image.
## A Timeline for Cwtch Stable
Now for the big news, we plan on releasing a candidate Cwtch Stable release during **Summer 2023**. Here is our plan for getting there:
- By **30th April 2023** the Cwtch team will have written the remaining outstanding documentation from the January roadmap including:
- A Cwtch Release Process Document
- A Cwtch Packaging Document
- Completion of documentation of existing Cwtch features, including relevant screenshots.
- By **30th April 2023** the Cwtch team will have also released developer-centric documentation including:
- A guide to building Cwtch-apps using official libraries
- Automatically generated API documentation for libCwtch
- By **30th June 2023** the Cwtch team will have released new Cwtch Beta releases (1.12+) featuring:
- An implementation of [Conversation Search](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/129)
- [Profile statuses](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/27) and other associated information
- An update to the network handling code to allow for [better Protocol Engine management](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/593)
- By **31st July 2023** the Cwtch team will have completed several infrastructure upgrades including:
- Extended reproducible builds to cover the Cwtch UI, or document where the blockers to achieving this exist.
- Integration of automated fuzzing into the build pipeline for all Cwtch dependencies maintained by the Cwtch team
- New testing environments for F-droid, Whonix, Raspberry Pi and other [partially supported systems](/docs/getting-started/supported_platforms)
- By **31st August 2023** the Cwtch team will have a released Cwtch Stable Release Candidate:
- At this point we expect that the Cwtch application and existing documentation will be robust and complete enough to be labelled as stable.
- Along with this label comes a higher standard for how we consider all aspects of Cwtch development. The work we have done up to this point reflects a much stronger development pipeline, and an ongoing commitment to security.
- **This does not mark an end to Cwtch development**, or new Cwtch features. But it does denote the point at which we consider Cwtch to be appropriate for wider use.
This is not all we have planned for the upcoming months. Subscribe to our [RSS feed](/blog/rss.xml), [Atom feed](/blog/atom.xml), or [JSON feed](/blog/feed.json) to stay up to date, and get the latest on, all aspects of Cwtch development.
## Get Involved
We have noticed an uptick in the number of people reaching out interested in contributing to Cwtch development. In order to help people get acclimated to our development flow we have created a new section on the main documentation site called [Developing Cwtch](/docs/contribute/developing) - there you will find a collection of useful links and information about how to get started with Cwtch development, what libraries and tools we use, how pull requests are validated and verified, and how to choose an issue to work on.
We also also updated our guides on [Translating Cwtch](/docs/contribute/translate) and [Testing Cwtch](/docs/contribute/testing).
If you are interested in getting started with Cwtch development then please check it out, and feel free to reach out to `team@cwtch.im` (or open an issue) with any questions. All types of contributions [are eligible for stickers](/docs/contribute/stickers).
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,75 @@
---
title: Availability Status and Profile Attributes
description: "Two new Cwtch features are now available to test in nightly: Availability Status and Profile Information."
slug: availability-status-profile-attributes
tags:
- cwtch
- cwtch-stable
- nightly
image: /img/devlog1_small.jpg
hide_table_of_contents: false
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
Two new Cwtch features are now available to test in nightly: [Availability Status](/docs/profiles/availability-status) and [Profile Information](/docs/profiles/profile-info).
Additionally, we have also published draft guidance on [running Cwtch on Tails](/docs/platforms/tails) that we would like volunteers to test and report back on.
The Open Privacy Research Society have [also announced they are want to raise $60,000 in 2023](https://openprivacy.ca/discreet-log/38-march-2023/) to help move forward projects like Cwtch. Please help support projects like ours with a [one-off donations](https://openprivacy.ca/donate) or [recurring support via Patreon](https://www.patreon.com/openprivacy).
<!--truncate-->
## Availability Status
New in this nightly is the ability to notify your conversations that you are "Away" or "Busy".
<figure>
[![](/img/profiles/status-tooltip-busy-set.png)](/img/profiles/status-tooltip-busy-set.png)
<figcaption></figcaption>
</figure>
Read more: [Availability Status](/docs/profiles/availability-status)
## Profile Attributes
Also new is the ability to augment your profile with a few small pieces of **public** information.
<figure>
[![](/img/profiles/attributes-set.png)](/img/profiles/attributes-set.png)
<figcaption></figcaption>
</figure>
Read more: [Profile Information](/docs/profiles/profile-info)
## Downloading the Nightly
[Nightly builds](https://docs.cwtch.im/docs/contribute/testing#cwtch-nightlies) are available from our build server. Download links for **2023-04-05-18-28-v1.11.0-7-g0290** are available below.
* Windows: [https://build.openprivacy.ca/files/flwtch-win-2023-04-05-18-28-v1.11.0-7-g0290/](https://build.openprivacy.ca/files/flwtch-win-2023-04-05-18-28-v1.11.0-7-g0290/)
* Linux: [https://build.openprivacy.ca/files/flwtch-2023-04-05-18-27-v1.11.0-7-g0290/](https://build.openprivacy.ca/files/flwtch-2023-04-05-18-27-v1.11.0-7-g0290/)
* Mac: [https://build.openprivacy.ca/files/flwtch-macos-2023-04-05-14-27-v1.11.0-7-g0290/](https://build.openprivacy.ca/files/flwtch-macos-2023-04-05-14-27-v1.11.0-7-g0290/)
* Android: [https://build.openprivacy.ca/files/flwtch-2023-04-05-18-27-v1.11.0-7-g0290/](https://build.openprivacy.ca/files/flwtch-2023-04-05-18-27-v1.11.0-7-g0290/)
Please see the contribution documentation for advice on [submitting feedback](/docs/contribute/testing#submitting-feedback)
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,68 @@
---
title: Cwtch Developer Documentation, Cwtchbot v0.1.0 and New Nightly.
description: "In this development log we take a look at the new Cwtch developer docs!"
slug: cwtch-developer-documentation
tags:
- cwtch
- cwtch-stable
- developer-documentation
image: /img/devlog9_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
One of the larger remaining goals outlined in our [Cwtch Stable roadmap update](/blog/cwtch-stable-roadmap-update) is comprehensive developer documentation. We have recently spent some time writing the foundation for these documents.
In this devlog we will introduce some of them, and outline the next steps. We also have a new nightly Cwtch release available for testing!
We are very interested in getting feedback on these documents, and we encourage anyone who is excited to build a Cwtch Bot, or even an alternative UI, to read them over and reach out to us with comments, questions, and suggestions!
As a reminder, the Open Privacy Research Society have [also announced they are want to raise $60,000 in 2023](https://openprivacy.ca/discreet-log/38-march-2023/) to help move forward projects like Cwtch. Please help support projects like ours with a [one-off donations](https://openprivacy.ca/donate) or [recurring support via Patreon](https://www.patreon.com/openprivacy).
![](/img/devlog9.png)
<!--truncate-->
## Cwtch Development Handbook
We have created a new documentation section, [the developers handbook](/developing/intro). This new section is targeted towards to people working on Cwtch projects (e.g. the official Cwtch library or the Cwtch UI), as well as people who want to build new Cwtch applications (e.g. chat bots or custom clients).
### Release and Packaging Process
The new handbook features a breakdown of [Cwtch release processes](/developing/release) - describing what, and how, build artifacts are created; the difference between nightly and official builds; how the official release process works; and how reproducible build scripts are created.
### Cwtch Application Development and Cwtchbot v0.1.0!
For the first time ever we now have [comprehensive documentation on how to build a Cwtch Application](/developing/category/building-a-cwtch-app). This section of the development handbook covers everything from [choosing a Cwtch library](/developing/building-a-cwtch-app/intro#choosing-a-cwtch-library), to [building your first application](/developing/building-a-cwtch-app/building-an-echobot).
Together with this new documentation we have also [released version 0.1 of the Cwtchbot framework](https://git.openprivacy.ca/sarah/cwtchbot), updating calls to use the [new Cwtch Stable API](/blog/cwtch-stable-api-design).
### New Nightly
There is a [new Nightly build](https://docs.cwtch.im/docs/contribute/testing#cwtch-nightlies) are available from our build server. The latest nightly we recommend testing is [2023-04-26-20-57-v1.11.0-33-gb4371](https://build.openprivacy.ca/files/flwtch-2023-04-26-20-57-v1.11.0-33-gb4371/).
This version has a number of fixes and updates to the file sharing and image previews/profile pictures experiment, and an update to the [in-development Tails support](/docs/platforms/tails).
In addition, this nightly also includes a number of performance improvements that should fix reported rendering issues on less powerful devices.
Please see the contribution documentation for advice on [submitting feedback](/docs/contribute/testing#submitting-feedback)
Subscribe to our [RSS feed](/blog/rss.xml), [Atom feed](/blog/atom.xml), or [JSON feed](/blog/feed.json) to stay up to date, and get the latest on, all aspects of Cwtch development.
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,60 @@
---
title: New Cwtch Nightly (v1.11.0-74-g0406)
description: "In this development log we take a look at the new Cwtch Nightly"
slug: cwtch-nightly-v.11-74
tags:
- cwtch
- cwtch-stable
- developer-documentation
image: /img/devlog10_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
We are getting close to a 1.12 release. This week we are drawing attention to the latest Cwtch Nightly (2023-06-05-17-36-v1.11.0-74-g0406) that is now available for wider testing.
As a reminder, the Open Privacy Research Society have [also announced they are want to raise $60,000 in 2023](https://openprivacy.ca/discreet-log/38-march-2023/) to help move forward projects like Cwtch. Please help support projects like ours with a [one-off donations](https://openprivacy.ca/donate) or [recurring support via Patreon](https://www.patreon.com/openprivacy).
![](/img/devlog10.png)
<!--truncate-->
### New Nightly
There is a [new Nightly build](https://docs.cwtch.im/docs/contribute/testing#cwtch-nightlies) are available from our build server. The latest nightly we recommend testing is [2023-06-05-17-36-v1.11.0-74-g0406](https://build.openprivacy.ca/files/flwtch-2023-06-05-17-36-v1.11.0-74-g0406/).
This version has a large number of improvements and bug fixes including:
* A new Font Scaling setting
* Several networking and connection management improvements including automatic detection and response to network changes, and several bug fixes that impacted time-to-connection after a resetting Tor.
* Updated UI font styles
* Dependency updates, including a new base of Flutter 3.10.
* A fix for stuck file downloading notifications on Android
* A fix for missing profile images in certain edge cases on Android
* Japanese, Swedish, and Swahili translation options
* A new retry peer connection button for prompting Cwtch to prioritize specific connections
* [Tails support](/docs/platforms/tails)
In addition, this nightly also includes a number of performance improvements that should fix reported rendering issues on less powerful devices.
Please see the contribution documentation for advice on [submitting feedback](/docs/contribute/testing#submitting-feedback)
Subscribe to our [RSS feed](/blog/rss.xml), [Atom feed](/blog/atom.xml), or [JSON feed](/blog/feed.json) to stay up to date, and get the latest on, all aspects of Cwtch development.
## Help us go further!
We couldn't do what we do without all the wonderful community support we get, from [one-off donations](https://openprivacy.ca/donate) to [recurring support via Patreon](https://www.patreon.com/openprivacy).
If you want to see us move faster on some of these goals and are in a position to, please [donate](https://openprivacy.ca/donate). If you happen to be at a company that wants to do more for the community and this aligns, please consider donating or sponsoring a developer.
Donations of **$5 or more** can opt to receive stickers as a thank-you gift!
For more information about donating to Open Privacy and claiming a thank you gift [please visit the Open Privacy Donate page](https://openprivacy.ca/donate/).
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

View File

@ -0,0 +1,84 @@
---
title: Cwtch Beta 1.12
description: "Cwtch Beta 1.12 is now available for download"
slug: cwtch-nightly-1-12
tags:
- cwtch
- cwtch-stable
- release
image: /img/devlog13_small.png
hide_table_of_contents: false
toc_max_heading_level: 4
authors:
-
name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
[Cwtch 1.12 is now available for download](https://cwtch.im/download)!
Cwtch 1.12 is the culmination of the last few months of effort by the Cwtch team, and includes many foundational changes that pave the way for [Cwtch Stable](/blog/path-to-cwtch-stable) including new features like [profile attributes](https://docs.cwtch.im/docs/profiles/profile-info), support for new platforms like [Tails](https://docs.cwtch.im/docs/platforms/tails), and multiple improvements to performance and stability.
![](/img/devlog13.png)
<!--truncate-->
## In This Release
<figure>
[![](/img/picnic1.12.png)](/img/picnic1.12.png)
<figcaption>A screenshot of Cwtch 1.12</figcaption>
</figure>
A special thanks to the [amazing volunteer translators](https://docs.cwtch.im/docs/contribute/translate) and [testers](https://docs.cwtch.im/docs/contribute/testing) who made this release possible.