cwtch.im
/
docs.cwtch.im
4
0
Fork 3
Code Issues 2 Pull Requests Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
i18n/de/docusaurus-plugin-content-blog/2023-01-06-path-to-cwtch-stable.md Normal file
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 doesn’t 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 don’t 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)

234
i18n/de/docusaurus-plugin-content-blog/2023-01-13-cwtch-stable-api-design.md Normal file
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 haven’t 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 doesn’t belong in Cwtchlib – as it would necessarily introduce unrelated dependencies into the core library.
This functionality also doesn’t 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.)

129
i18n/de/docusaurus-plugin-content-blog/2023-01-20-reproducible-builds-bindings.md Normal file
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)

166
i18n/de/docusaurus-plugin-content-blog/2023-01-27-platform-support.md Normal file
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)

88
i18n/de/docusaurus-plugin-content-blog/2023-02-03-cwtch-testing-i.md Normal file
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)

60
i18n/de/docusaurus-plugin-content-blog/2023-02-10-android-reproducibility.md Normal file
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)

71
i18n/de/docusaurus-plugin-content-blog/2023-02-17-cwtch-testing-ii.md Normal file
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)

93
i18n/de/docusaurus-plugin-content-blog/2023-02-24-autogenerating-cwtch-bindings.md Normal file
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)

111
i18n/de/docusaurus-plugin-content-blog/2023-03-03-autobindings-optional-experiments.md Normal file
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)

61
i18n/de/docusaurus-plugin-content-blog/2023-03-10-cwtch-documentation.md Normal file
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)

85
i18n/de/docusaurus-plugin-content-blog/2023-03-29-cwtch-1.11.md Normal file
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)

104
i18n/de/docusaurus-plugin-content-blog/2023-03-31-cwtch-stable-roadmap-update.md Normal file
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)

75
i18n/de/docusaurus-plugin-content-blog/2023-04-06-availability-and-profile-attributes.md Normal file
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)

68
i18n/de/docusaurus-plugin-content-blog/2023-04-28-developer-docs.md Normal file
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)

60
i18n/de/docusaurus-plugin-content-blog/2023-06-07-new-nightly.md Normal file
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)

84
i18n/de/docusaurus-plugin-content-blog/2023-06-16-cwtch-1.12.md Normal file
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.
- **New Features:**
- **Profile Attributes** - profiles can now be augmented with [additional public information](https://docs.cwtch.im/docs/profiles/profile-info)
- **Availability Status** - you can now notify contacts that you [are **away** or **busy**](https://docs.cwtch.im/docs/profiles/availability-status)
- **Five New Supported Localizations**: **Japanese**, **Korean**, **Slovak**, **Swahili** and **Swedish**
- **Support for Tails** - adds an [OnionGrater](https://docs.cwtch.im/docs/platforms/tails) configuration and a new `CWTCH_TAILS` environment variable that enables special Tor behaviour.
- **Bug Fixes / Improvements:**
- Based on Flutter 3.10
- Inter is now the main UI font
- New Font Scaling setting
- New Network Management code to better manage Tor on unstable networks
- File Sharing Experiment Fixes
- Fix performance issues for file bubble
- Allow restarting of file shares that have timed out
- Fix NPE in FileBubble caused by deleting the underlying file
- Move from RetVal to UpdateConversationAttributes to minimze UI thread issues
- Updates to Linux install scripts to support more distributions
- Add a Retry Peer connection to prioritize connection attempts for certain conversations
- Updates to `_FlDartProject` to allow custom setting of Flutter asset paths
- **Accessibility / UX:**
- Full translations for **Brazilian Portuguese**, **Dutch**, **French**, **German**, **Italian**, **Russian**, **Polish**, **Slovak**, **Spanish**, **Swahili**, **Swedish**, **Turkish**, and **Welsh**
- Core translations for **Danish** (75%), **Norwegian** (76%), and **Romanian** (75%)
- Partial translations for **Japanese** (29%), **Korean** (23%), **Luxembourgish** (22%), **Greek** (16%), and **Portuguese** (6%)
## Reproducible Bindings
Cwtch 1.12 is based on libCwtch version `libCwtch-autobindings-2023-06-13-10-50-v0.0.5`. 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.5](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/cwtch-autobindings-v0.0.5)
## 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)

86
i18n/de/docusaurus-plugin-content-blog/2023-07-05-cwtch-stable-roadmap-update.md Normal file
View File

@ -0,0 +1,86 @@
---
title: Cwtch Stable Roadmap Update
description: "Back in March we provided an update on several goals that we would have to hit on our way to Cwtch Stable, and the timelines to hit them. In this post we provide a new update on those goals"
slug: cwtch-stable-roadmap-update-june
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 update](/blog/cwtch-stable-roadmap-update) we provided back in March, and provides an overview of the next steps on our journey towards Cwtch Stable.
![](/img/devlog1.png)
<!--truncate-->
## Update on the Cwtch Stable Roadmap
Back in March we extended and updated several goals from [our January roadmap](https://docs.cwtch.im/blog/path-to-cwtch-stable) 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 many of these goals, we can look back and see how work is progressing.
(✅ means complete, 🟡 means in-progress, 🕒 reprioritized)
- By **30th April 2023** the Cwtch team will have written the remaining outstanding documentation from the January roadmap including:
- A Cwtch Release Process Document ✅ - [Release Process](https://docs.cwtch.im/developing/release/#official-releases)
- A Cwtch Packaging Document ✅ - [Packaging Documentation](https://docs.cwtch.im/developing/release/)
- Completion of documentation of existing Cwtch features, including relevant screenshots. 🟡 - new features are documented to the standards outlined in new [documentation style guide](/docs/contribute/documentation), and many older feature documentation features have been updated to that standard. Work is ongoing to refine the standard.
- By **30th April 2023** the Cwtch team will have also released developer-centric documentation including:
- A guide to building Cwtch-apps using official libraries ✅ - [Building a Cwtch App](https://docs.cwtch.im/developing/category/building-a-cwtch-app)
- Automatically generated API documentation for libCwtch 🕒 - this effort has been delayed pending other higher priority work.
- 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) 🟡 - currently in [active development](https://git.openprivacy.ca/cwtch.im/cwtch/pulls/518)
- [Profile statuses](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/27) and other associated information ✅ - released in [Cwtch Beta 1.12](https://docs.cwtch.im/blog/cwtch-nightly-1-12)
- An update to the network handling code to allow for [better Protocol Engine management](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/593) 🟡🕒 - new Network Management code was released in [Cwtch Beta 1.12](https://docs.cwtch.im/blog/cwtch-nightly-1-12). We now believe these changes will be complete in Cwtch Beta 1.13.
- 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. 🟡 - we have recently made a few updates to [Repliqate](https://git.openprivacy.ca/openprivacy/repliqate) to support this work, and expect to begin in-depth examination of build artifacts in the next couple of weeks.
- Integration of automated fuzzing into the build pipeline for all Cwtch dependencies maintained by the Cwtch team 🕒 - after some initial explorations into new Go fuzzing tools we reached the conclusion that it would be better to replace this effort with other assurance work (see below).
- New testing environments for F-droid, Whonix, Raspberry Pi and other [partially supported systems](/docs/getting-started/supported_platforms) 🟡 - we have already launched an environment for testing [Tails](/docs/platforms/tails). Other platforms are underway.
- 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 labeled 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.
## Next Steps, Refinements, Additional Work
As you may have noticed above we have reprioritized some work after initial investigations forced us to reevaluate the expected cost/benefit trade-off. This has allowed us to move up timelines for tasks e.g. reproducible UI builds and testing environments.
Other work has been reprioritized due to developer availability. Documentation work in particular has not progressed as fast as we would like.
However, [Cwtch Beta 1.12](https://docs.cwtch.im/blog/cwtch-nightly-1-12) featured many new features alongside improved performance, more robust packaging, and several fixes impacting experimental features like file sharing.
The work that we have done on reproducible and automatically generated bindings has considerably reduced the maintenance burden associated with updates and adding new features, and has allowed us to also tackle long standing issues related to Tor process managements and Cwtch startup.
We are still on track for releasing a Cwtch Stable release candidate in August 2023, with an official Cwtch Stable release expected shortly afterwards.
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)

94
i18n/de/docusaurus-plugin-content-blog/2023-07-14-cwtch-ui-reproducible-builds.md Normal file
View File

@ -0,0 +1,94 @@
---
title: Progress Towards Reproducible UI Builds
description: ""
slug: cwtch-ui-reproducible-builds-linux
tags:
- cwtch
- cwtch-stable
- reproducible-builds
- bindings
- repliqate
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
---
Earlier this year we talked about the changes we have made to make [Cwtch Bindings Reproducible](https://docs.cwtch.im/blog/cwtch-bindings-reproducible).
In this devlog we will talk about how the Cwtch UI are currently built, the changes we have made to Cwtch UI 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 UI builds specifically, and to anyone who wants to start implementing reproducible builds in their own project.
![](/img/devlog1.png)
<!--truncate-->
## Building the Cwtch UI
The official Cwtch UI project uses the FLutter framework. The Cwtch UI deliberately tracks the `stable` channel.
All builds are conducted through the `flutter` tool e.g. `flutter build`. We inject two build flags as part of the official build `VERSION` and `COMMIT_DATE`:
flutter build linux --dart-define BUILD_VER=`cat VERSION` --dart-define BUILD_DATE=`cat COMMIT_DATE`
These flags are defined to be identical to Cwtch Bindings. `VERSION` is the latest git tag: `git describe --tags --abbrev=1` and `COMMIT_DATE` is the date of the latest commit on the branch ``echo `git log -1 --format=%cd --date=format:%G-%m-%d-%H-%M` > COMMIT_DATE``
All Cwtch UI builds also depend on two external dependencies not managed directly by the flutter project: Tor (implicit as part of the fetchTor scripts) and libCwtch (defined in `LIBCWTCH-GO.version`, and fetched via the fetch-libcwtch scripts).
The binaries are downloaded via their respective scripts prior to the build, and managed via a separate update process.
## Changes we made for reproducible builds
For reproducible linux builds we had to modify the generated `linux/CMakeLists.txt` file to include the following compiler and linker flags:
* `-fno-ident` - suppresses compiler identifying information from compiled artifacts. Without this small changes in compiler versions will result in different binaries.
* `--hash-style=gnu` - asserts a standard hashing scheme to use across all compiled artifacts. Without this compilers that have been compiled with different default schemes will produce different artifacts
* `--build-id=none` - suppresses build id generation. Without this each compiled artifact will have a section of effectively randomized data.
We have also defined a new [linker script](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/commit/3148a8e0642e51bc59d9eb00ca2b319a7097285a/elf_x86_64.x) that differs from the default by removing all `.comment` sections from object files. We do this because the linking process links in non-project artifacts like `crtbeginS.o` which, in most systems, us compiled with a `.comment` section (the default linking script already removes the `.note.gnu*` sections.
### Tar Archives
Finally, following the [guide at reproducible-builds.org](https://reproducible-builds.org/docs/archives/) we have defined standard metadata for the generated Tar archives to make them also reproducible.
## Limitations and Next Steps
The above changes mean that official linux builds of the same commit will now result in identical artifacts.
The next step is to roll these changes into [repliqate](https://docs.cwtch.im/blog/cwtch-bindings-reproducible#introducing-repliqate) as we have done with our bindings builds.
However, because Repliqate is based on Debian images and our official UI builds are based on an Ubuntu distribution the resulting archives differ by a single instruction at the start of a few sections - introduced because Ubuntu compiles and provides C Runtime (CRT) artifacts (e.g. `crti.o` with full branch protection enabled. On 64-bit systems this results in an `endcr64` instruction being inserted at the start of the `.init` and `.fini` sections, among others.
In order to allow people to fully repliqate Cwtch builds in an isolated environment like repliqate, as we do for Cwtch Bindings, it will be necessary to provide instructions for setting up a hardened image that can work the same way in repliqate.
### Pinned Dependencies
Additionally, while our repliqate scripts pin several major dependencies like flutter and go, and the dependencies managed by these systems are locked to specific versions, there are still a few dependencies within the ecosystems that are not strictly pinned.
The major one is libc. Operating systems rarely make big changes to packaged libc versions for a specific distribution (typically because doing so in a non-breaking way would be a major undertaking).
However this does mean that Cwtch reproduciblility is implicitly tied to operating system practices - this is something we would like to begin decoupling ourselves from going forward.
## Stay up to date!
We expect to make additional progress on this in the coming weeks and 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.
## 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)

66
i18n/de/docusaurus-plugin-content-blog/2023-07-26-cwtch-stable-call-for-credits.md Normal file
View File

@ -0,0 +1,66 @@
---
title: Cwtch-Aufruf Anerkennungen für Mitwirkende
description: "Da wir immer näher an einen Cwtch Stable Kandidaten herankommen, möchten wir diese Gelegenheit nutzen, um sicherzustellen, dass diejenigen, die im Laufe der Jahre an Cwtch mitgewirkt haben, die Möglichkeit haben, die Anerkennung zu erhalten."
slug: cwtch-stable-call-for-credits
tags:
- cwtch
- cwtch-stable
- Mitwirkende
- Community
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
---
Da wir immer näher an einen Cwtch Stable Kandidaten herankommen, möchten wir diese Gelegenheit nutzen, um sicherzustellen, dass diejenigen, die im Laufe der Jahre an Cwtch mitgewirkt haben, die Möglichkeit haben, die Anerkennung zu erhalten.
Wenn du in irgendeiner Weise am Entwicklungsprozess teilgenommen hast, z.B. beim Protokoll-Design, Code-Design, UI-Design, das Schreiben von Tests, Tests von Release-Kandidaten, Berichtsprobleme, Übersetzung der Anwendung oder der Dokumentation, die Förderung von metadatenresistenten Anwendungen oder irgendwelchen anderen sinnvollen Beitrag zum Cwtch-Ökosystem, dann möchten wir dir die Möglichkeit bieten, deinen Namen oder dein Handle sowohl im Quellcode-Repository als auch in der Anwendung selbst zu haben.
![](/img/devlog1.png)
<!--truncate-->
## Eine Geschichte von Cwtch Beiträgen und Anonmymität
In den ersten Tagen von Cwtch haben wir uns ausdrücklich dazu entschlossen, die Anerkennungen nirgends in der Applikation aufzunehmen und Beiträge anonym über eine Vielzahl von Kanälen zu akzeptieren, einschließlich Cwtch selbst.
Aufgrund der Art der Applikation und des Privatsphäre und Metadaten resistenten Raumes im Allgemeinen haben wir immer eine Richtlinie gehabt, die Beiträge basierend auf Leistung und nicht auf Identität bewertet. Dieser Ansatz bedeutet, dass wir zwar Mitwirkende haben, deren Identität in irgendeiner Weise bekannt ist, aber wir haben auch viele, die wir nur durch Schreibstil, Beitragstyp oder Cwtch Adresse kennen.
Wir verstehen, dass es viele Menschen diese Weise bevorzugen und keinen Wunsch haben, eine Identität zu haben, die mit dem Cwtch Projekt verbunden ist. Bei diesen Menschen bedanken wir uns sehr herzlich. Vielen Dank. Du hast Cwtch zu dem gemacht, was er ist. (Und wenn du jemals Cwtch Sticker möchtest - lass es uns bitte wissen!)
Es wäre jedoch nicht richtig von uns, Cwtch Stable ohne ein endgültiges Angebot an alle Mitwirkenden freizugeben. Wenn du möchtest, dass für deine Beiträge an Cwtch eine Anerkennung haben möchtest, dann sprich uns bitte an und teile uns mit, wie wir entsprechend die Anerkennung zuteil werden können.
## Kontaktiere uns
Du kannst per E-Mail um Anerkennung bitten (team@cwtch.im) oder über Cwtch (entweder öffentlich über die [Cwtch Release Candidate Tester Gruppen](https://docs.cwtch.im/docs/contribute/testing#join-the-cwtch-release-candidate-testers-group), oder privat in einer Nachricht an Sarah: `icyt7rvdsdci42h6si2ibtwucdmjrlcb2ezkecuagtquiiflbkxf2cqd`).
Du kannst auch [ein issue](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/new) erstellen.
Bitte gib in deiner Anfrage einen Namen oder ein Handle an und, wenn gewünscht, eine grobe Beschreibung des Beitrags an (z.B. Entwicklung, Design, Dokumentation, Übersetzung, Finanzierung). Jeder, der keine Beschreibung angibt, wird mit in einem allgemeinen Dankesbereich zusammengefasst.
Dies ist ein offenes Angebot. Wenn du zu irgendeinem Zeitpunkt deine Meinung änderst und möchtest, dass Anerkennung hinzugefügt (oder entfernt wird), dann lass es uns bitte wissen.
Ich möchte noch eine weitere Gelegenheit nutzen dir zu sagen, unabhängig davon ob du für deine Arbeit bei Cwtch öffentlich Anerkennung haben möchtest oder nicht: **Vielen Dank**.
## Bleib auf dem Laufenden!
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 dies passt, erwäge bitte, einen Entwickler zu spenden oder zu sponsern.
Spenden in Höhe von **$5 oder mehr** berechtigen dazu, 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)

7
i18n/de/docusaurus-plugin-content-docs-docs-developer/current/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Entwicklerhandbuch",
"position": 10,
"link": {
"type": "generierter Index"
}
}

7
i18n/de/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Eine Cwtch App erstellen",
"position": 10,
"link": {
"type": "generierter Index"
}
}

123
i18n/de/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/building-an-echobot.md Normal file
View File

@ -0,0 +1,123 @@
---
sidebar_position: 3
---
# Einen Cwtch Echobot erstellen
In diesem Tutorial werden wir durch den Aufbau einer einfachen Cwtch Echobot gehen. Ein Bot, der einfach mit der Nachricht antwortet, die an ihn gesendet wurde.
Zur Vollständigkeit, wir werden einen Echobot in verschiedenen Cwtch Frameworks erstellen, um ein Gefühl für die verschiedenen Funktionsebenen zu bekommen, die jede Bibliothek oder jedes Framework bietet.
## CwtchBot (Go) verwenden
:::info CwtchBot Framework
Dieses Tutorial verwendet das CwtchBot Framework.
:::
Beginne mit dem Erstellen eines neuen Go-Projekts und einer Datei `main.go`. In der `main` Funktion:
```go
package main
import (
"cwtch.im/cwtch/event"
"cwtch.im/cwtch/model"
"cwtch.im/cwtch/model/attr"
"cwtch.im/cwtch/model/constants"
"fmt"
"git.openprivacy.ca/sarah/cwtchbot"
_ "github.com/mutecomm/go-sqlcipher/v4"
"os/user"
"path"
)
func main() {
user, _ := user.Current()
cwtchbot := bot.NewCwtchBot(path.Join(user.HomeDir, "/.echobot/"), "echobot")
cwtchbot.Launch()
// Set Some Profile Information
cwtchbot.Peer.SetScopedZonedAttribute(attr.PublicScope, attr.ProfileZone, constants.Name, "echobot2")
cwtchbot.Peer.SetScopedZonedAttribute(attr.PublicScope, attr.ProfileZone, constants.ProfileAttribute1, "A Cwtchbot Echobot")
fmt.Printf("echobot address: %v\n", cwtchbot.Peer.GetOnion())
for {
message := cwtchbot.Queue.Next()
cid, _ := cwtchbot.Peer.FetchConversationInfo(message.Data[event.RemotePeer])
switch message.EventType {
case event.NewMessageFromPeer:
msg := cwtchbot.UnpackMessage(message.Data[event.Data])
fmt.Printf("Message: %v\n", msg)
reply := string(cwtchbot.PackMessage(msg.Overlay, msg.Data))
cwtchbot.Peer.SendMessage(cid.ID, reply)
case event.ContactCreated:
fmt.Printf("Auto approving stranger %v %v\n", cid, message.Data[event.RemotePeer])
// accept the stranger as a new contact
cwtchbot.Peer.AcceptConversation(cid.ID)
// Send Hello...
reply := string(cwtchbot.PackMessage(model.OverlayChat, "Hello!"))
cwtchbot.Peer.SendMessage(cid.ID, reply)
}
}
}
```
## Imp (Rost) verwenden
:::info Imp (Rost) Bot Framework
Dieses Tutorial verwendet das Imp Cwtch Bot Framework (Rust). Dieses Framework ist derzeit in Bearbeitung und das API-Design kann sich ändern. IMP basiert auch auf libcwtch-rs, die derzeit auf einer älteren pre-stable API-Version von Cwtch basiert. Wir planen die Aktualisierung der libcwtch-rs im Sommer 2023.
:::
```go
use std::borrow::BorrowMut;
use std::thread;
use chrono::{DateTime, FixedOffset};
use libcwtch;
use libcwtch::CwtchLib;
use libcwtch::structs::*;
use libcwtch::event::*;
use cwtch_imp::imp;
use cwtch_imp::behaviour::*;
use cwtch_imp::imp::Imp;
const BOT_HOME: &str = "~/.cwtch/bots/echobot";
const BOT_NAME: &str = "echobot";
struct Echobot {}
fn main() {
let behaviour: Behaviour = BehaviourBuilder::new().name(BOT_NAME.to_string()).new_contact_policy(NewContactPolicy::Accept).build();
let event_loop_handle = thread::spawn(move || {
let mut echobot = Echobot {};
let mut bot = Imp::spawn(behaviour,String::new(), BOT_HOME.to_string());
bot.event_loop::<Echobot>(echobot.borrow_mut());
});
event_loop_handle.join().expect("Error running event loop");
}
impl imp::EventHandler for Echobot {
fn on_new_message_from_contact(&self, cwtch: &dyn libcwtch::CwtchLib, profile: &Profile, conversation_id: ConversationID, handle: String, timestamp_received: DateTime<FixedOffset>, message: Message) {
let response = Message {
o: MessageType::TextMessage,
d: message.d,
};
cwtch.send_message(&profile.profile_id, conversation_id, &response);
}
fn handle(&mut self, cwtch: &dyn CwtchLib, profile_opt: Option<&Profile>, event: &Event) {
match event {
Event::NewPeer { profile_id, tag, created, name, default_picture, picture, online, profile_data } => {
println!(
"\n***** {} at {} *****\n",
name, profile_id.as_str()
);
}
_ => (),
};
}
}
```

29
i18n/de/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/core-concepts.md Normal file
View File

@ -0,0 +1,29 @@
---
sidebar_position: 2
---
# Kernkonzepte
Diese Seite dokumentiert die Kernkonzepte, denen du als Cwtch App-Entwickler ziemlich häufig begegnen wirst.
## Cwtch Anwendungsverzeichnis
Oft als `$CWTCH_HOME`bezeichnet, ist das Cwtch Anwendungsverzeichnis der Ort, an dem Cwtch alle Informationen aus einer Cwtch Anwendung speichert.
## Profile
Cwtch Profile werden als verschlüsselte sqlite3 Datenbanken gespeichert. Du musst selten/nie direkt mit der Datenbank interagieren. Stattdessen bietet jede Bibliothek eine Reihe von Schnittstellen, um mit der Cwtch App zu interagieren, Profile zu erstellen, Profile zu verwalten und Konversationen zu führen.
## Der Eventbus
Unabhängig davon, welche Bibliothek du am Ende wählst, ist der Eventbus die einzige ständige Schnittstelle, an die du dich gewöhnen musst. Cwtch übernimmt alle asynchronen Aufgaben (z.B. das Empfangen einer Nachricht von einem Teilnehmer) automatisch, indem er eine Nachricht auf den EventBus legt. Die Anwendung kann bestimmte Arten von Nachrichten abonnieren, z.B. `NewMessageFromPeer` und einen Ereignishandler konfigurieren, um Code als Antwort auf eine solche Nachricht auszuführen.
Für ein Beispiel schau in das Echo Bot Tutorial.
## Einstellungen
Die meisten Cwtch-Einstellungen (mit Ausnahme von Experimenten) sind für nachgeschaltete grafische Benutzeroberflächen konzipiert, wie z.B. Themes / Spaltenlayouts - insbesondere das Cwtch UI. Als solche werden diese Einstellungen von Cwtch Bibliotheken überhaupt nicht verwendet und sind nur als bequemer Speicherplatz für die UI-Konfiguration gedacht.
### Experimentelle Funktionen
Bestimmte Cwtch-Funktionen sind [hinter den Experimenten](/docs/category/experiments) eingebunden. Diese Experimente müssen aktiviert sein, bevor die damit verbundenen Funktionen aktiviert werden. Verschiedene Bibliotheken können verschiedene Experimente enthüllen, und einige Bibliotheken unterstützen bestimmte Experimente möglicherweise überhaupt nicht.

23
i18n/de/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/intro.md Normal file
View File

@ -0,0 +1,23 @@
---
sidebar_position: 1
---
# Erste Schritte
## Auswahl einer Cwtch-Bibliothek
### Cwtch Go Lib
Die offizielle Cwtch-Bibliothek ist in Go geschrieben und kann unter [https://git.openprivacy.ca/cwtch.im/cwtch](https://git.openprivacy.ca/cwtch.im/cwtch) gefunden werden. Diese Bibliothek ermöglicht den Zugriff auf alle Cwtch-Funktionen.
### CwtchBot
Wir bieten auch ein spezialisiertes Cwtch Bot Framework in Go an, dass einen leichteren und maßgeschneiderten Ansatz für den Bau von Chat-Bots bietet. Für eine Einführung in das Erstellen von Chatbots mit dem CwtchBot Framework schau dir das [an und baue ein echobot Tutorial](/developing/building-a-cwtch-app/building-an-echobot#using-cwtchbot-go).
### Autobindings (C-bindings)
Die [offiziellen c-bindigs für Cwtch](https://git.openprivacy.ca/cwtch.im/autobindings) werden automatisch aus der Cwtch Go Library generiert. Die API ist im Vergleich zum direkten Zugriff auf die Cwtch Go Library beschränkt und ist explizit auf den Aufbau der Cwtch UI zugeschnitten.
### libCwtch-rs (Rust)
Eine experimentelle rust-fied Version von Cwtch Autobindings ist in [libCwtch-rs](https://crates.io/crates/libcwtch) verfügbar. Während wir in Zukunft Pläne haben, Rust bindings zu anzunehmen, hinkt die Unterstützung von Rust dem Rest des Ökosystems Cwtch hinterher.

20
i18n/de/docusaurus-plugin-content-docs-docs-developer/current/intro.md Normal file
View File

@ -0,0 +1,20 @@
---
sidebar_position: 1
---
# Einführung in die Cwtch Entwicklung
- [Kernkonzepte](/developing/building-a-cwtch-app/core-concepts)
- [Sicherheitshandbuch](/security/intro)
## Beitrag zum Cwtch-Kern
- [Freigabe und Pack Prozess](/developing/release)
## Cwtch Bots erstellen
- [Auswahl einer Bibliothek](/developing/building-a-cwtch-app/intro#choosing-a-cwtch-library)
- [Echobot Tutorial](/developing/building-a-cwtch-app/building-an-echobot)

62
i18n/de/docusaurus-plugin-content-docs-docs-developer/current/release.md Normal file
View File

@ -0,0 +1,62 @@
---
sidebar_position: 1
---
# Freigabe und Pack Prozess
Cwtch-Builds werden automatisch über Drone erstellt. Um gebaut zu werden, müssen die Aufgaben von einem Projektteammitglied genehmigt werden.
## Automatisiertes Testen
Drone führt eine Reihe automatisierter Tests in verschiedenen Phasen der Release-Pipeline durch.
| Test-Suite | Repository | Anmerkungen |
| --------------------------- | ----------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| Integrationstests | cwtch.im/cwtch | Eine vollständige Übung von Peer-to-Peer und Gruppen-Nachrichten |
| Dateifreigabe Test | cwtch.im/cwtch | Prüft, ob Dateifreigabe und das Herunterladen von Bildern wie erwartet funktioniert |
| Automatischer Download Test | cwtch.im/cwtch | Tests die überprüfen, ob das automatische Herunterladen von Bildern (z.B. Profilbilder) wie erwartet funktioniert |
| UI-Integrationstest | cwtch.im/cwtch-ui | Eine Reihe von Gherkin Tests um verschiedene UI-Ströme wie Erstellen / Löschen von Profilen und Ändern von Einstellungen zu üben |
## Cwtch Autobindings
Drone erzeugt die folgenden Build-Artefakte für alle Cwtch-Autobinding-Builds.
| Erstelle Artefakt | Plattform | Anmerkungen |
| -------------------------- | --------- | ----------------------------------------------------------- |
| android/cwtch-sources.jar | Android | gomobile Quellcode für die Android Cwtch-Bibliothek |
| android/cwtch.aar | Android | Android Cwtch-Bibliothek. Unterstützt arm, arm64 und amd64. |
| linux/libCwtch.h | Linux | C-Header-Datei |
| linux/libCwtch.so | Linux | x64 geteilte Bibliothek |
| windows/libCwtch.h | Windows | C-Header-Datei |
| windows/libCwtch.dll | Windows | x64 geteilte Bibliothek |
| macos/libCwtch.arm64.dylib | MacOS | Arm64 geteilte Bibliothek |
| macos/libCwtch.x64.dylib | MacOS | x64 geteilte Bibliothek |
## UI Nightly Builds
Wir stellen unveröffentlichte Versionen von Cwtch zum Testen als [Cwtch Nightlies](/docs/contribute/testing#cwtch-nightlies) zur Verfügung.
Jeder nächtliche Build-Ordner enthält eine Sammlung von Build-Artefakten z.B. (APK-Dateien für Android, Installer-ausführbare Dateien für Android) in einem komfortablen Ordner. Eine vollständige Liste der derzeit erzeugten Build Artefakte lautet wie folgt:
| Build-Artefakt | Plattform | Anmerkungen |
| --------------------------- | --------- | ---------------------------------------------------------------------------------------------------------- |
| cwtch-VERSION.apk | Android | Unterstützt arm, arm64 und amd64. Kann über sideload geladen werden. |
| cwtch-VERSION.aab | Android | Android App Bundle für Veröffentlichung in Appstores |
| Cwtch-VERSION.dmg | MacOS | |
| cwtch-VERSION.tar.gz | Linux | Enthält den Code, Bibliotheken und Assets zusätzlich zu den Installations-Skripten für verschiedene Geräte |
| cwtch-VERSION.zip | Windows | |
| cwtch-installer-VERSION.exe | Windows | NSIS basierter Installationsassistent |
Nächtliche Builds werden regelmäßig vom System entfernt
## Offizielle Releases
Das Cwtch Team trifft sich regelmäßig und erzielt einen Konsens auf der Grundlage von Test Feedback der nächtlichen Builds und der Projekt Roadmap.
Wenn die Entscheidung getroffen wird, eine Release-Version zu erstellen, wird eine nächtliche Version mit einem neuen git Tag gebaut, der die Release-Version widerspiegelt., `v.1.12.0`. Die Build-Artefakte werden dann auf die Cwtch-Release-Website in einen dedizierten Versionsordner kopiert.
### Reproduzierbare Builds
Wir verwenden [repliqate](https://git.openprivacy.ca/openprivacy/repliqate) um [reproduzierbare Build-Skripte für Cwtch](https://git.openprivacy.ca/cwtch.im/repliqate-scripts) bereitzustellen.
Wir aktualisieren das Repository `repliqate-scripts` mit Skripten für alle offiziellen Releases. Derzeit sind nur Cwtch-Bindings reproduzierbar

94
i18n/es/docusaurus-plugin-content-blog/2023-01-06-path-to-cwtch-stable.md Normal file
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 doesn’t 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 don’t 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)

234
i18n/es/docusaurus-plugin-content-blog/2023-01-13-cwtch-stable-api-design.md Normal file
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 haven’t 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 doesn’t belong in Cwtchlib – as it would necessarily introduce unrelated dependencies into the core library.
This functionality also doesn’t 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.)

129
i18n/es/docusaurus-plugin-content-blog/2023-01-20-reproducible-builds-bindings.md Normal file
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)

166
i18n/es/docusaurus-plugin-content-blog/2023-01-27-platform-support.md Normal file
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)

88
i18n/es/docusaurus-plugin-content-blog/2023-02-03-cwtch-testing-i.md Normal file
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)

60
i18n/es/docusaurus-plugin-content-blog/2023-02-10-android-reproducibility.md Normal file
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)

71
i18n/es/docusaurus-plugin-content-blog/2023-02-17-cwtch-testing-ii.md Normal file
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)

93
i18n/es/docusaurus-plugin-content-blog/2023-02-24-autogenerating-cwtch-bindings.md Normal file
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)

111
i18n/es/docusaurus-plugin-content-blog/2023-03-03-autobindings-optional-experiments.md Normal file
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)

61
i18n/es/docusaurus-plugin-content-blog/2023-03-10-cwtch-documentation.md Normal file
View File

@ -0,0 +1,61 @@
---
title: Updates to Cwtch Documentation
description: "In this development log we will highlight some of the major documentation updates over the last few weeks."
slug: cwtch-documentation
tags:
- cwtch
- cwtch-stable
- documentation
- security-handbook
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 main streams of work in the lead up to Cwtch Stable has been improving all aspects of Cwtch Documentation. In this development log we will highlight some of the major updates over the last few weeks.
![](/img/devlog9.png)
<!--truncate-->
## Cwtch Secure Development Handbook
One of the earliest compendiums of Cwtch documentation was the Cwtch Secure Development Handbook. This handbook provided an overview of the various parts of the Cwtch ecosystem, the known risks, and any existing mitigations. The handbook was designed to serve as a guide to developers who were building or extending Cwtch, and over the years it also served as a permanent home for documenting long-standing design decisions.
We have [now ported the the handbook to this documentation site](/security/intro), along with updating some of the contents. Over the next few months we will be expanding this section to include new sections on fuzzing, plugins, and client implementation.
## Volunteer Development
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).
## Next Steps
We still have more work to do on the documentation front:
* Ensuring all pages [implement the new documentation style guide](/docs/contribute/documentation), and include appropriate screenshots and descriptions.
* Expanding the security handbook to provide information on [reproducible builds](/blog/cwtch-bindings-reproducible), [the new Cwtch Stable API](/blog/cwtch-stable-api-design) and upcoming improvements around fuzz testing.
* Creating new documentation sections on the [libCwtch autobindings API](/blog/autobindings) and building applications on top of Cwtch.
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 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)

85
i18n/es/docusaurus-plugin-content-blog/2023-03-29-cwtch-1.11.md Normal file
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)

104
i18n/es/docusaurus-plugin-content-blog/2023-03-31-cwtch-stable-roadmap-update.md Normal file
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)

75
i18n/es/docusaurus-plugin-content-blog/2023-04-06-availability-and-profile-attributes.md Normal file
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)

68
i18n/es/docusaurus-plugin-content-blog/2023-04-28-developer-docs.md Normal file
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)

60
i18n/es/docusaurus-plugin-content-blog/2023-06-07-new-nightly.md Normal file
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)

84
i18n/es/docusaurus-plugin-content-blog/2023-06-16-cwtch-1.12.md Normal file
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.
- **New Features:**
- **Profile Attributes** - profiles can now be augmented with [additional public information](https://docs.cwtch.im/docs/profiles/profile-info)
- **Availability Status** - you can now notify contacts that you [are **away** or **busy**](https://docs.cwtch.im/docs/profiles/availability-status)
- **Five New Supported Localizations**: **Japanese**, **Korean**, **Slovak**, **Swahili** and **Swedish**
- **Support for Tails** - adds an [OnionGrater](https://docs.cwtch.im/docs/platforms/tails) configuration and a new `CWTCH_TAILS` environment variable that enables special Tor behaviour.
- **Bug Fixes / Improvements:**
- Based on Flutter 3.10
- Inter is now the main UI font
- New Font Scaling setting
- New Network Management code to better manage Tor on unstable networks
- File Sharing Experiment Fixes
- Fix performance issues for file bubble
- Allow restarting of file shares that have timed out
- Fix NPE in FileBubble caused by deleting the underlying file
- Move from RetVal to UpdateConversationAttributes to minimze UI thread issues
- Updates to Linux install scripts to support more distributions
- Add a Retry Peer connection to prioritize connection attempts for certain conversations
- Updates to `_FlDartProject` to allow custom setting of Flutter asset paths
- **Accessibility / UX:**
- Full translations for **Brazilian Portuguese**, **Dutch**, **French**, **German**, **Italian**, **Russian**, **Polish**, **Slovak**, **Spanish**, **Swahili**, **Swedish**, **Turkish**, and **Welsh**
- Core translations for **Danish** (75%), **Norwegian** (76%), and **Romanian** (75%)
- Partial translations for **Japanese** (29%), **Korean** (23%), **Luxembourgish** (22%), **Greek** (16%), and **Portuguese** (6%)
## Reproducible Bindings
Cwtch 1.12 is based on libCwtch version `libCwtch-autobindings-2023-06-13-10-50-v0.0.5`. 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.5](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/cwtch-autobindings-v0.0.5)
## 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)

86
i18n/es/docusaurus-plugin-content-blog/2023-07-05-cwtch-stable-roadmap-update.md Normal file
View File

@ -0,0 +1,86 @@
---
title: Cwtch Stable Roadmap Update
description: "Back in March we provided an update on several goals that we would have to hit on our way to Cwtch Stable, and the timelines to hit them. In this post we provide a new update on those goals"
slug: cwtch-stable-roadmap-update-june
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 update](/blog/cwtch-stable-roadmap-update) we provided back in March, and provides an overview of the next steps on our journey towards Cwtch Stable.
![](/img/devlog1.png)
<!--truncate-->
## Update on the Cwtch Stable Roadmap
Back in March we extended and updated several goals from [our January roadmap](https://docs.cwtch.im/blog/path-to-cwtch-stable) 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 many of these goals, we can look back and see how work is progressing.
(✅ means complete, 🟡 means in-progress, 🕒 reprioritized)
- By **30th April 2023** the Cwtch team will have written the remaining outstanding documentation from the January roadmap including:
- A Cwtch Release Process Document ✅ - [Release Process](https://docs.cwtch.im/developing/release/#official-releases)
- A Cwtch Packaging Document ✅ - [Packaging Documentation](https://docs.cwtch.im/developing/release/)
- Completion of documentation of existing Cwtch features, including relevant screenshots. 🟡 - new features are documented to the standards outlined in new [documentation style guide](/docs/contribute/documentation), and many older feature documentation features have been updated to that standard. Work is ongoing to refine the standard.
- By **30th April 2023** the Cwtch team will have also released developer-centric documentation including:
- A guide to building Cwtch-apps using official libraries ✅ - [Building a Cwtch App](https://docs.cwtch.im/developing/category/building-a-cwtch-app)
- Automatically generated API documentation for libCwtch 🕒 - this effort has been delayed pending other higher priority work.
- 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) 🟡 - currently in [active development](https://git.openprivacy.ca/cwtch.im/cwtch/pulls/518)
- [Profile statuses](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/27) and other associated information ✅ - released in [Cwtch Beta 1.12](https://docs.cwtch.im/blog/cwtch-nightly-1-12)
- An update to the network handling code to allow for [better Protocol Engine management](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/593) 🟡🕒 - new Network Management code was released in [Cwtch Beta 1.12](https://docs.cwtch.im/blog/cwtch-nightly-1-12). We now believe these changes will be complete in Cwtch Beta 1.13.
- 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. 🟡 - we have recently made a few updates to [Repliqate](https://git.openprivacy.ca/openprivacy/repliqate) to support this work, and expect to begin in-depth examination of build artifacts in the next couple of weeks.
- Integration of automated fuzzing into the build pipeline for all Cwtch dependencies maintained by the Cwtch team 🕒 - after some initial explorations into new Go fuzzing tools we reached the conclusion that it would be better to replace this effort with other assurance work (see below).
- New testing environments for F-droid, Whonix, Raspberry Pi and other [partially supported systems](/docs/getting-started/supported_platforms) 🟡 - we have already launched an environment for testing [Tails](/docs/platforms/tails). Other platforms are underway.
- 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 labeled 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.
## Next Steps, Refinements, Additional Work
As you may have noticed above we have reprioritized some work after initial investigations forced us to reevaluate the expected cost/benefit trade-off. This has allowed us to move up timelines for tasks e.g. reproducible UI builds and testing environments.
Other work has been reprioritized due to developer availability. Documentation work in particular has not progressed as fast as we would like.
However, [Cwtch Beta 1.12](https://docs.cwtch.im/blog/cwtch-nightly-1-12) featured many new features alongside improved performance, more robust packaging, and several fixes impacting experimental features like file sharing.
The work that we have done on reproducible and automatically generated bindings has considerably reduced the maintenance burden associated with updates and adding new features, and has allowed us to also tackle long standing issues related to Tor process managements and Cwtch startup.
We are still on track for releasing a Cwtch Stable release candidate in August 2023, with an official Cwtch Stable release expected shortly afterwards.
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)

94
i18n/es/docusaurus-plugin-content-blog/2023-07-14-cwtch-ui-reproducible-builds.md Normal file
View File

@ -0,0 +1,94 @@
---
title: Progress Towards Reproducible UI Builds
description: ""
slug: cwtch-ui-reproducible-builds-linux
tags:
- cwtch
- cwtch-stable
- reproducible-builds
- bindings
- repliqate
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
---
Earlier this year we talked about the changes we have made to make [Cwtch Bindings Reproducible](https://docs.cwtch.im/blog/cwtch-bindings-reproducible).
In this devlog we will talk about how the Cwtch UI are currently built, the changes we have made to Cwtch UI 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 UI builds specifically, and to anyone who wants to start implementing reproducible builds in their own project.
![](/img/devlog1.png)
<!--truncate-->
## Building the Cwtch UI
The official Cwtch UI project uses the FLutter framework. The Cwtch UI deliberately tracks the `stable` channel.
All builds are conducted through the `flutter` tool e.g. `flutter build`. We inject two build flags as part of the official build `VERSION` and `COMMIT_DATE`:
flutter build linux --dart-define BUILD_VER=`cat VERSION` --dart-define BUILD_DATE=`cat COMMIT_DATE`
These flags are defined to be identical to Cwtch Bindings. `VERSION` is the latest git tag: `git describe --tags --abbrev=1` and `COMMIT_DATE` is the date of the latest commit on the branch ``echo `git log -1 --format=%cd --date=format:%G-%m-%d-%H-%M` > COMMIT_DATE``
All Cwtch UI builds also depend on two external dependencies not managed directly by the flutter project: Tor (implicit as part of the fetchTor scripts) and libCwtch (defined in `LIBCWTCH-GO.version`, and fetched via the fetch-libcwtch scripts).
The binaries are downloaded via their respective scripts prior to the build, and managed via a separate update process.
## Changes we made for reproducible builds
For reproducible linux builds we had to modify the generated `linux/CMakeLists.txt` file to include the following compiler and linker flags:
* `-fno-ident` - suppresses compiler identifying information from compiled artifacts. Without this small changes in compiler versions will result in different binaries.
* `--hash-style=gnu` - asserts a standard hashing scheme to use across all compiled artifacts. Without this compilers that have been compiled with different default schemes will produce different artifacts
* `--build-id=none` - suppresses build id generation. Without this each compiled artifact will have a section of effectively randomized data.
We have also defined a new [linker script](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/commit/3148a8e0642e51bc59d9eb00ca2b319a7097285a/elf_x86_64.x) that differs from the default by removing all `.comment` sections from object files. We do this because the linking process links in non-project artifacts like `crtbeginS.o` which, in most systems, us compiled with a `.comment` section (the default linking script already removes the `.note.gnu*` sections.
### Tar Archives
Finally, following the [guide at reproducible-builds.org](https://reproducible-builds.org/docs/archives/) we have defined standard metadata for the generated Tar archives to make them also reproducible.
## Limitations and Next Steps
The above changes mean that official linux builds of the same commit will now result in identical artifacts.
The next step is to roll these changes into [repliqate](https://docs.cwtch.im/blog/cwtch-bindings-reproducible#introducing-repliqate) as we have done with our bindings builds.
However, because Repliqate is based on Debian images and our official UI builds are based on an Ubuntu distribution the resulting archives differ by a single instruction at the start of a few sections - introduced because Ubuntu compiles and provides C Runtime (CRT) artifacts (e.g. `crti.o` with full branch protection enabled. On 64-bit systems this results in an `endcr64` instruction being inserted at the start of the `.init` and `.fini` sections, among others.
In order to allow people to fully repliqate Cwtch builds in an isolated environment like repliqate, as we do for Cwtch Bindings, it will be necessary to provide instructions for setting up a hardened image that can work the same way in repliqate.
### Pinned Dependencies
Additionally, while our repliqate scripts pin several major dependencies like flutter and go, and the dependencies managed by these systems are locked to specific versions, there are still a few dependencies within the ecosystems that are not strictly pinned.
The major one is libc. Operating systems rarely make big changes to packaged libc versions for a specific distribution (typically because doing so in a non-breaking way would be a major undertaking).
However this does mean that Cwtch reproduciblility is implicitly tied to operating system practices - this is something we would like to begin decoupling ourselves from going forward.
## Stay up to date!
We expect to make additional progress on this in the coming weeks and 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.
## 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)

66
i18n/es/docusaurus-plugin-content-blog/2023-07-26-cwtch-stable-call-for-credits.md Normal file
View File

@ -0,0 +1,66 @@
---
title: Cwtch Call for Contributor Credits
description: "As we journey ever closer to a Cwtch Stable candidate we would like to take this opportunity to ensure that those who have contributed to Cwtch over the years have the optiont to be credited."
slug: cwtch-stable-call-for-credits
tags:
- cwtch
- cwtch-stable
- contributors
- community
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 we journey ever closer to a Cwtch Stable candidate we would like to take this opportunity to ensure that those who have contributed to Cwtch over the years have the option to be credited in some way.
If you have participated in the development process in any way e.g. protocol design, writing code, UI design, writing tests, testing release candidates, reporting issues, translating the application or documentation, promoting metadata resistant applications or any other meaningful contribution to the Cwtch ecosystem we want to offer you the option to have your name or handle credited in both the source code repository and the application itself.
![](/img/devlog1.png)
<!--truncate-->
## A History of Cwtch Contibutions and Anonmymity
In the early days of Cwtch we made the explicit decision to not include credits anywhere in the application, and to accept contributions anonymously over a variety of channels, including Cwtch itself.
Due to the nature of the application, and the privacy and metadata resistant space in general, we have always had a policy of evaluating contributions based on merit, and not on identity. This approach means that, while we do have contributors whose identity is known to us in some way, we have many who we know only by writing style, contribution type, or cwtch address.
We understand that many people much prefer it this way, and have no desire to have any identity linked to the Cwtch project. To those people we offer our deep gratitude. Thank you. You have made Cwtch what it is. (And if you ever want Cwtch Stickers - please let us know!)
However, it would not be right of us to release Cwtch Stable without at least one final offer to all contributors. If you want to be credited for your contributions to Cwtch then, please, reach out to us and let us know of a way to appropriately credit you.
## Getting in Touch
You can ask for credit via email (team@cwtch.im), or via Cwtch (either publicly via the [Cwtch Release Candidate Testers groups](https://docs.cwtch.im/docs/contribute/testing#join-the-cwtch-release-candidate-testers-group), or privately in a message to Sarah: `icyt7rvdsdci42h6si2ibtwucdmjrlcb2ezkecuagtquiiflbkxf2cqd`).
You can also [open an issue](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/new).
When asking, please provide a name or handle, and if desired, a rough description of the contribution (e.g. development, design, documentation, translating, funding). Anyone who does not provide a description will be grouped under a general thanks section.
This is an open offer. If at any time you change your mind and wish to have credit added (or removed) please let us know.
I want to take another opporunity to say, regardless of whether you wish to be publicly credited for your work on Cwtch, **thank you**.
## Stay up to date!
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)

7
i18n/es/docusaurus-plugin-content-docs-docs-developer/current/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Developers Handbook",
"position": 10,
"link": {
"type": "generated-index"
}
}

7
i18n/es/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Building a Cwtch App",
"position": 10,
"link": {
"type": "generated-index"
}
}

123
i18n/es/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/building-an-echobot.md Normal file
View File

@ -0,0 +1,123 @@
---
sidebar_position: 3
---
# Building a Cwtch Echobot
In this tutorial we will walk through building a simple Cwtch Echobot. A bot that, when messaged, simply responds with the message it was sent.
For completeness, we will build an Echobot in multiple difference Cwtch frameworks to get a feel for the different levels of functionality offered by each library or framework.
## Using CwtchBot (Go)
:::info CwtchBot Framework
This tutorial uses the CwtchBot framework.
:::
Start by creating a new Go project, and a file `main.go`. In the `main` function:
```go
package main
import (
"cwtch.im/cwtch/event"
"cwtch.im/cwtch/model"
"cwtch.im/cwtch/model/attr"
"cwtch.im/cwtch/model/constants"
"fmt"
"git.openprivacy.ca/sarah/cwtchbot"
_ "github.com/mutecomm/go-sqlcipher/v4"
"os/user"
"path"
)
func main() {
user, _ := user.Current()
cwtchbot := bot.NewCwtchBot(path.Join(user.HomeDir, "/.echobot/"), "echobot")
cwtchbot.Launch()
// Set Some Profile Information
cwtchbot.Peer.SetScopedZonedAttribute(attr.PublicScope, attr.ProfileZone, constants.Name, "echobot2")
cwtchbot.Peer.SetScopedZonedAttribute(attr.PublicScope, attr.ProfileZone, constants.ProfileAttribute1, "A Cwtchbot Echobot")
fmt.Printf("echobot address: %v\n", cwtchbot.Peer.GetOnion())
for {
message := cwtchbot.Queue.Next()
cid, _ := cwtchbot.Peer.FetchConversationInfo(message.Data[event.RemotePeer])
switch message.EventType {
case event.NewMessageFromPeer:
msg := cwtchbot.UnpackMessage(message.Data[event.Data])
fmt.Printf("Message: %v\n", msg)
reply := string(cwtchbot.PackMessage(msg.Overlay, msg.Data))
cwtchbot.Peer.SendMessage(cid.ID, reply)
case event.ContactCreated:
fmt.Printf("Auto approving stranger %v %v\n", cid, message.Data[event.RemotePeer])
// accept the stranger as a new contact
cwtchbot.Peer.AcceptConversation(cid.ID)
// Send Hello...
reply := string(cwtchbot.PackMessage(model.OverlayChat, "Hello!"))
cwtchbot.Peer.SendMessage(cid.ID, reply)
}
}
}
```
## Using Imp (Rust)
:::info Imp (Rust) Bot Framework
This tutorial uses the Imp Cwtch Bot framework (Rust). This framework is currently a work-in-progress and the API design is subject to change. IMP is also based on libcwtch-rs which is currently based on an older pre-stable API version of Cwtch. We are planning in updating libcwtch-rs in Summer 2023.
:::
```go
use std::borrow::BorrowMut;
use std::thread;
use chrono::{DateTime, FixedOffset};
use libcwtch;
use libcwtch::CwtchLib;
use libcwtch::structs::*;
use libcwtch::event::*;
use cwtch_imp::imp;
use cwtch_imp::behaviour::*;
use cwtch_imp::imp::Imp;
const BOT_HOME: &str = "~/.cwtch/bots/echobot";
const BOT_NAME: &str = "echobot";
struct Echobot {}
fn main() {
let behaviour: Behaviour = BehaviourBuilder::new().name(BOT_NAME.to_string()).new_contact_policy(NewContactPolicy::Accept).build();
let event_loop_handle = thread::spawn(move || {
let mut echobot = Echobot {};
let mut bot = Imp::spawn(behaviour,String::new(), BOT_HOME.to_string());
bot.event_loop::<Echobot>(echobot.borrow_mut());
});
event_loop_handle.join().expect("Error running event loop");
}
impl imp::EventHandler for Echobot {
fn on_new_message_from_contact(&self, cwtch: &dyn libcwtch::CwtchLib, profile: &Profile, conversation_id: ConversationID, handle: String, timestamp_received: DateTime<FixedOffset>, message: Message) {
let response = Message {
o: MessageType::TextMessage,
d: message.d,
};
cwtch.send_message(&profile.profile_id, conversation_id, &response);
}
fn handle(&mut self, cwtch: &dyn CwtchLib, profile_opt: Option<&Profile>, event: &Event) {
match event {
Event::NewPeer { profile_id, tag, created, name, default_picture, picture, online, profile_data } => {
println!(
"\n***** {} at {} *****\n",
name, profile_id.as_str()
);
}
_ => (),
};
}
}
```

29
i18n/es/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/core-concepts.md Normal file
View File

@ -0,0 +1,29 @@
---
sidebar_position: 2
---
# Core Concepts
This page documents the core concepts that you, as a Cwtch App Developer, will encounter fairly frequently.
## Cwtch Home Directory
Often referred to as `$CWTCH_HOME`, the Cwtch application home directory is the location where Cwtch stores all information from a Cwtch application.
## Profiles
Cwtch profiles are saved as encrypted sqlite3 databases. You will rarely/never have to interact directly with the database. Instead each library provides a set of interfaces to interact with the Cwtch App, create profiles, manage profiles, and engage in conversations.
## The Event Bus
Regardless of which library you end up choosing, the one constant interface you will have to get used to is the EventBus. Cwtch handles all asynchronous tasks (e.g. receiving a message from a peer) automatically, eventually placing a message on the EventBus. Application can subscribe to certain kinds of messages e.g. `NewMessageFromPeer` and setup an event handler to run code in response to such a message.
For an example see the Echo Bot tutorial.
## Settings
Most Cwtch settings (with the exception of experiments) are designed for downstream graphical user interfaces e.g. themes / column layouts - in particular the Cwtch UI. As such these settings are not used at all by Cwtch libraries, and are only intended as a convenient storage place for UI configuration.
### Experiments
Certain Cwtch features are [gated behind experiments](/docs/category/experiments). These experiments need to be enabled before functionality related to them will activate. Different libraries may expose different experiments, and some libraries may not support certain experiments at all.

23
i18n/es/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/intro.md Normal file
View File

@ -0,0 +1,23 @@
---
sidebar_position: 1
---
# Getting Started
## Choosing A Cwtch Library
### Cwtch Go Lib
The official Cwtch library is written in Go and can be found at [https://git.openprivacy.ca/cwtch.im/cwtch](https://git.openprivacy.ca/cwtch.im/cwtch). This library allows access to all Cwtch functionality.
### CwtchBot
We also provide a specialized Cwtch Bot framework in Go that provides a more lightweight and tailored approach to building chat bots. For an introduction to building chatbots with the CwtchBot framework check out the [building an echobot tutorial](/developing/building-a-cwtch-app/building-an-echobot#using-cwtchbot-go).
### Autobindings (C-bindings)
The [official c-bindings for Cwtch](https://git.openprivacy.ca/cwtch.im/autobindings) are automatically generated from the Cwtch Go Library. The API is limited compared to accessing the Cwtch Go Library directly, and is explicitly tailored towards building the Cwtch UI.
### libCwtch-rs (Rust)
An experimental rust-fied version of Cwtch Autobindings is available in [libCwtch-rs](https://crates.io/crates/libcwtch). While we have plans to officially adopt rust bindings in the future, right now Rust support lags behind the rest of the Cwtch ecosystem.

20
i18n/es/docusaurus-plugin-content-docs-docs-developer/current/intro.md Normal file
View File

@ -0,0 +1,20 @@
---
sidebar_position: 1
---
# Introduction to Cwtch Development
- [Core Concepts](/developing/building-a-cwtch-app/core-concepts)
- [Security Handbook](/security/intro)
## Contributing to Cwtch Core
- [Release and Packaging Process](/developing/release)
## Building Cwtch Bots
- [Choosing a Library](/developing/building-a-cwtch-app/intro#choosing-a-cwtch-library)
- [Echobot Tutorial](/developing/building-a-cwtch-app/building-an-echobot)

62
i18n/es/docusaurus-plugin-content-docs-docs-developer/current/release.md Normal file
View File

@ -0,0 +1,62 @@
---
sidebar_position: 1
---
# Release and Packaging Process
Cwtch builds are automatically constructed via Drone. In order to be built the tasks must be approved by a project team member.
## Automated Testing
Drone carries out a suite of automated tests at various stages of the release pipeline.
| Test Suite | Repository | Notes |
| ----------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------- |
| Integration Test | cwtch.im/cwtch | A full exercise of peer-to-peer and group messaging |
| File Sharing Test | cwtch.im/cwtch | Tests that file sharing and image downloading work as expected |
| Automated Download Test | cwtch.im/cwtch | Tests that automated image downloading (e.g. profile pictures) work as expected |
| UI Integration Test | cwtch.im/cwtch-ui | A suite of Gherkin tests to exercise various UI flows like Creating / Deleting profiles and changing settings |
## Cwtch Autobindings
Drone produces the following build artifacts for all Cwtch autobindings builds.
| Build Artifact | Platform | Notes |
| -------------------------- | -------- | ---------------------------------------------------------- |
| android/cwtch-sources.jar | Android | gomobile derived source code for the Android Cwtch library |
| android/cwtch.aar | Android | Android Cwtch library. Supports arm, arm64, and amd64. |
| linux/libCwtch.h | Linux | C header file |
| linux/libCwtch.so | Linux | x64 shared library |
| windows/libCwtch.h | Windows | C header file |
| windows/libCwtch.dll | Windows | x64 bit shared library |
| macos/libCwtch.arm64.dylib | MacOS | Arm64 shared library |
| macos/libCwtch.x64.dylib | MacOS | x64 shared library |
## UI Nightly Builds
We make unreleased versions of Cwtch available for testing as [Cwtch Nightlies](/docs/contribute/testing#cwtch-nightlies).
Each nightly build folder contains a collection of build artifacts e.g. (APK files for Android, installer executables for Android) in single convenient folder. A full list of build artifacts currently produced is as follows:
| Build Artifact | Platform | Notes |
| --------------------------- | -------- | -------------------------------------------------------------------------------------- |
| cwtch-VERSION.apk | Android | Supports arm, arm64, and amd64. Can be sideloaded. |
| cwtch-VERSION.aab | Android | Android App Bundle for publishing to appstores |
| Cwtch-VERSION.dmg | MacOS | |
| cwtch-VERSION.tar.gz | Linux | Contains the code, libs, and assets in addition to install scripts for various devices |
| cwtch-VERSION.zip | Windows | |
| cwtch-installer-VERSION.exe | Windows | NSIS powered installation wizard |
Nightly builds are regularly purged from the system
## Official Releases
The Cwtch Team meets on a regular basis and reaches consensus based on nightly testing feedback and project roadmaps.
When the decision is made to cut a release build, a nightly version is built with a new git tag reflecting the release version e.g. `v.1.12.0`. The build artifacts are then copied to the Cwtch release website to a dedicated versioned folder.
### Reproducible Builds
We use [repliqate](https://git.openprivacy.ca/openprivacy/repliqate) to provide [reproducible build scripts for Cwtch](https://git.openprivacy.ca/cwtch.im/repliqate-scripts).
We update the `repliqate-scripts` repository with scripts for all official releases. Currently only Cwtch bindings are reproducible

94
i18n/it/docusaurus-plugin-content-blog/2023-01-06-path-to-cwtch-stable.md Normal file
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 doesn’t 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 don’t 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)

234
i18n/it/docusaurus-plugin-content-blog/2023-01-13-cwtch-stable-api-design.md Normal file
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 haven’t 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 doesn’t belong in Cwtchlib – as it would necessarily introduce unrelated dependencies into the core library.
This functionality also doesn’t 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.)

129
i18n/it/docusaurus-plugin-content-blog/2023-01-20-reproducible-builds-bindings.md Normal file
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)

166
i18n/it/docusaurus-plugin-content-blog/2023-01-27-platform-support.md Normal file
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)

88
i18n/it/docusaurus-plugin-content-blog/2023-02-03-cwtch-testing-i.md Normal file
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)

60
i18n/it/docusaurus-plugin-content-blog/2023-02-10-android-reproducibility.md Normal file
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)

71
i18n/it/docusaurus-plugin-content-blog/2023-02-17-cwtch-testing-ii.md Normal file
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)

93
i18n/it/docusaurus-plugin-content-blog/2023-02-24-autogenerating-cwtch-bindings.md Normal file
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)

111
i18n/it/docusaurus-plugin-content-blog/2023-03-03-autobindings-optional-experiments.md Normal file
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)

61
i18n/it/docusaurus-plugin-content-blog/2023-03-10-cwtch-documentation.md Normal file
View File

@ -0,0 +1,61 @@
---
title: Updates to Cwtch Documentation
description: "In this development log we will highlight some of the major documentation updates over the last few weeks."
slug: cwtch-documentation
tags:
- cwtch
- cwtch-stable
- documentation
- security-handbook
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 main streams of work in the lead up to Cwtch Stable has been improving all aspects of Cwtch Documentation. In this development log we will highlight some of the major updates over the last few weeks.
![](/img/devlog9.png)
<!--truncate-->
## Cwtch Secure Development Handbook
One of the earliest compendiums of Cwtch documentation was the Cwtch Secure Development Handbook. This handbook provided an overview of the various parts of the Cwtch ecosystem, the known risks, and any existing mitigations. The handbook was designed to serve as a guide to developers who were building or extending Cwtch, and over the years it also served as a permanent home for documenting long-standing design decisions.
We have [now ported the the handbook to this documentation site](/security/intro), along with updating some of the contents. Over the next few months we will be expanding this section to include new sections on fuzzing, plugins, and client implementation.
## Volunteer Development
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).
## Next Steps
We still have more work to do on the documentation front:
* Ensuring all pages [implement the new documentation style guide](/docs/contribute/documentation), and include appropriate screenshots and descriptions.
* Expanding the security handbook to provide information on [reproducible builds](/blog/cwtch-bindings-reproducible), [the new Cwtch Stable API](/blog/cwtch-stable-api-design) and upcoming improvements around fuzz testing.
* Creating new documentation sections on the [libCwtch autobindings API](/blog/autobindings) and building applications on top of Cwtch.
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 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)

85
i18n/it/docusaurus-plugin-content-blog/2023-03-29-cwtch-1.11.md Normal file
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)

104
i18n/it/docusaurus-plugin-content-blog/2023-03-31-cwtch-stable-roadmap-update.md Normal file
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)

75
i18n/it/docusaurus-plugin-content-blog/2023-04-06-availability-and-profile-attributes.md Normal file
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)

68
i18n/it/docusaurus-plugin-content-blog/2023-04-28-developer-docs.md Normal file
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)

60
i18n/it/docusaurus-plugin-content-blog/2023-06-07-new-nightly.md Normal file
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)

84
i18n/it/docusaurus-plugin-content-blog/2023-06-16-cwtch-1.12.md Normal file
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.
- **New Features:**
- **Profile Attributes** - profiles can now be augmented with [additional public information](https://docs.cwtch.im/docs/profiles/profile-info)
- **Availability Status** - you can now notify contacts that you [are **away** or **busy**](https://docs.cwtch.im/docs/profiles/availability-status)
- **Five New Supported Localizations**: **Japanese**, **Korean**, **Slovak**, **Swahili** and **Swedish**
- **Support for Tails** - adds an [OnionGrater](https://docs.cwtch.im/docs/platforms/tails) configuration and a new `CWTCH_TAILS` environment variable that enables special Tor behaviour.
- **Bug Fixes / Improvements:**
- Based on Flutter 3.10
- Inter is now the main UI font
- New Font Scaling setting
- New Network Management code to better manage Tor on unstable networks
- File Sharing Experiment Fixes
- Fix performance issues for file bubble
- Allow restarting of file shares that have timed out
- Fix NPE in FileBubble caused by deleting the underlying file
- Move from RetVal to UpdateConversationAttributes to minimze UI thread issues
- Updates to Linux install scripts to support more distributions
- Add a Retry Peer connection to prioritize connection attempts for certain conversations
- Updates to `_FlDartProject` to allow custom setting of Flutter asset paths
- **Accessibility / UX:**
- Full translations for **Brazilian Portuguese**, **Dutch**, **French**, **German**, **Italian**, **Russian**, **Polish**, **Slovak**, **Spanish**, **Swahili**, **Swedish**, **Turkish**, and **Welsh**
- Core translations for **Danish** (75%), **Norwegian** (76%), and **Romanian** (75%)
- Partial translations for **Japanese** (29%), **Korean** (23%), **Luxembourgish** (22%), **Greek** (16%), and **Portuguese** (6%)
## Reproducible Bindings
Cwtch 1.12 is based on libCwtch version `libCwtch-autobindings-2023-06-13-10-50-v0.0.5`. 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.5](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/cwtch-autobindings-v0.0.5)
## 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)

86
i18n/it/docusaurus-plugin-content-blog/2023-07-05-cwtch-stable-roadmap-update.md Normal file
View File

@ -0,0 +1,86 @@
---
title: Cwtch Stable Roadmap Update
description: "Back in March we provided an update on several goals that we would have to hit on our way to Cwtch Stable, and the timelines to hit them. In this post we provide a new update on those goals"
slug: cwtch-stable-roadmap-update-june
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 update](/blog/cwtch-stable-roadmap-update) we provided back in March, and provides an overview of the next steps on our journey towards Cwtch Stable.
![](/img/devlog1.png)
<!--truncate-->
## Update on the Cwtch Stable Roadmap
Back in March we extended and updated several goals from [our January roadmap](https://docs.cwtch.im/blog/path-to-cwtch-stable) 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 many of these goals, we can look back and see how work is progressing.
(✅ means complete, 🟡 means in-progress, 🕒 reprioritized)
- By **30th April 2023** the Cwtch team will have written the remaining outstanding documentation from the January roadmap including:
- A Cwtch Release Process Document ✅ - [Release Process](https://docs.cwtch.im/developing/release/#official-releases)
- A Cwtch Packaging Document ✅ - [Packaging Documentation](https://docs.cwtch.im/developing/release/)
- Completion of documentation of existing Cwtch features, including relevant screenshots. 🟡 - new features are documented to the standards outlined in new [documentation style guide](/docs/contribute/documentation), and many older feature documentation features have been updated to that standard. Work is ongoing to refine the standard.
- By **30th April 2023** the Cwtch team will have also released developer-centric documentation including:
- A guide to building Cwtch-apps using official libraries ✅ - [Building a Cwtch App](https://docs.cwtch.im/developing/category/building-a-cwtch-app)
- Automatically generated API documentation for libCwtch 🕒 - this effort has been delayed pending other higher priority work.
- 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) 🟡 - currently in [active development](https://git.openprivacy.ca/cwtch.im/cwtch/pulls/518)
- [Profile statuses](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/27) and other associated information ✅ - released in [Cwtch Beta 1.12](https://docs.cwtch.im/blog/cwtch-nightly-1-12)
- An update to the network handling code to allow for [better Protocol Engine management](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/593) 🟡🕒 - new Network Management code was released in [Cwtch Beta 1.12](https://docs.cwtch.im/blog/cwtch-nightly-1-12). We now believe these changes will be complete in Cwtch Beta 1.13.
- 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. 🟡 - we have recently made a few updates to [Repliqate](https://git.openprivacy.ca/openprivacy/repliqate) to support this work, and expect to begin in-depth examination of build artifacts in the next couple of weeks.
- Integration of automated fuzzing into the build pipeline for all Cwtch dependencies maintained by the Cwtch team 🕒 - after some initial explorations into new Go fuzzing tools we reached the conclusion that it would be better to replace this effort with other assurance work (see below).
- New testing environments for F-droid, Whonix, Raspberry Pi and other [partially supported systems](/docs/getting-started/supported_platforms) 🟡 - we have already launched an environment for testing [Tails](/docs/platforms/tails). Other platforms are underway.
- 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 labeled 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.
## Next Steps, Refinements, Additional Work
As you may have noticed above we have reprioritized some work after initial investigations forced us to reevaluate the expected cost/benefit trade-off. This has allowed us to move up timelines for tasks e.g. reproducible UI builds and testing environments.
Other work has been reprioritized due to developer availability. Documentation work in particular has not progressed as fast as we would like.
However, [Cwtch Beta 1.12](https://docs.cwtch.im/blog/cwtch-nightly-1-12) featured many new features alongside improved performance, more robust packaging, and several fixes impacting experimental features like file sharing.
The work that we have done on reproducible and automatically generated bindings has considerably reduced the maintenance burden associated with updates and adding new features, and has allowed us to also tackle long standing issues related to Tor process managements and Cwtch startup.
We are still on track for releasing a Cwtch Stable release candidate in August 2023, with an official Cwtch Stable release expected shortly afterwards.
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)

94
i18n/it/docusaurus-plugin-content-blog/2023-07-14-cwtch-ui-reproducible-builds.md Normal file
View File

@ -0,0 +1,94 @@
---
title: Progress Towards Reproducible UI Builds
description: ""
slug: cwtch-ui-reproducible-builds-linux
tags:
- cwtch
- cwtch-stable
- reproducible-builds
- bindings
- repliqate
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
---
Earlier this year we talked about the changes we have made to make [Cwtch Bindings Reproducible](https://docs.cwtch.im/blog/cwtch-bindings-reproducible).
In this devlog we will talk about how the Cwtch UI are currently built, the changes we have made to Cwtch UI 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 UI builds specifically, and to anyone who wants to start implementing reproducible builds in their own project.
![](/img/devlog1.png)
<!--truncate-->
## Building the Cwtch UI
The official Cwtch UI project uses the FLutter framework. The Cwtch UI deliberately tracks the `stable` channel.
All builds are conducted through the `flutter` tool e.g. `flutter build`. We inject two build flags as part of the official build `VERSION` and `COMMIT_DATE`:
flutter build linux --dart-define BUILD_VER=`cat VERSION` --dart-define BUILD_DATE=`cat COMMIT_DATE`
These flags are defined to be identical to Cwtch Bindings. `VERSION` is the latest git tag: `git describe --tags --abbrev=1` and `COMMIT_DATE` is the date of the latest commit on the branch ``echo `git log -1 --format=%cd --date=format:%G-%m-%d-%H-%M` > COMMIT_DATE``
All Cwtch UI builds also depend on two external dependencies not managed directly by the flutter project: Tor (implicit as part of the fetchTor scripts) and libCwtch (defined in `LIBCWTCH-GO.version`, and fetched via the fetch-libcwtch scripts).
The binaries are downloaded via their respective scripts prior to the build, and managed via a separate update process.
## Changes we made for reproducible builds
For reproducible linux builds we had to modify the generated `linux/CMakeLists.txt` file to include the following compiler and linker flags:
* `-fno-ident` - suppresses compiler identifying information from compiled artifacts. Without this small changes in compiler versions will result in different binaries.
* `--hash-style=gnu` - asserts a standard hashing scheme to use across all compiled artifacts. Without this compilers that have been compiled with different default schemes will produce different artifacts
* `--build-id=none` - suppresses build id generation. Without this each compiled artifact will have a section of effectively randomized data.
We have also defined a new [linker script](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/commit/3148a8e0642e51bc59d9eb00ca2b319a7097285a/elf_x86_64.x) that differs from the default by removing all `.comment` sections from object files. We do this because the linking process links in non-project artifacts like `crtbeginS.o` which, in most systems, us compiled with a `.comment` section (the default linking script already removes the `.note.gnu*` sections.
### Tar Archives
Finally, following the [guide at reproducible-builds.org](https://reproducible-builds.org/docs/archives/) we have defined standard metadata for the generated Tar archives to make them also reproducible.
## Limitations and Next Steps
The above changes mean that official linux builds of the same commit will now result in identical artifacts.
The next step is to roll these changes into [repliqate](https://docs.cwtch.im/blog/cwtch-bindings-reproducible#introducing-repliqate) as we have done with our bindings builds.
However, because Repliqate is based on Debian images and our official UI builds are based on an Ubuntu distribution the resulting archives differ by a single instruction at the start of a few sections - introduced because Ubuntu compiles and provides C Runtime (CRT) artifacts (e.g. `crti.o` with full branch protection enabled. On 64-bit systems this results in an `endcr64` instruction being inserted at the start of the `.init` and `.fini` sections, among others.
In order to allow people to fully repliqate Cwtch builds in an isolated environment like repliqate, as we do for Cwtch Bindings, it will be necessary to provide instructions for setting up a hardened image that can work the same way in repliqate.
### Pinned Dependencies
Additionally, while our repliqate scripts pin several major dependencies like flutter and go, and the dependencies managed by these systems are locked to specific versions, there are still a few dependencies within the ecosystems that are not strictly pinned.
The major one is libc. Operating systems rarely make big changes to packaged libc versions for a specific distribution (typically because doing so in a non-breaking way would be a major undertaking).
However this does mean that Cwtch reproduciblility is implicitly tied to operating system practices - this is something we would like to begin decoupling ourselves from going forward.
## Stay up to date!
We expect to make additional progress on this in the coming weeks and 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.
## 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)

66
i18n/it/docusaurus-plugin-content-blog/2023-07-26-cwtch-stable-call-for-credits.md Normal file
View File

@ -0,0 +1,66 @@
---
title: Cwtch Call for Contributor Credits
description: "As we journey ever closer to a Cwtch Stable candidate we would like to take this opportunity to ensure that those who have contributed to Cwtch over the years have the optiont to be credited."
slug: cwtch-stable-call-for-credits
tags:
- cwtch
- cwtch-stable
- contributors
- community
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 we journey ever closer to a Cwtch Stable candidate we would like to take this opportunity to ensure that those who have contributed to Cwtch over the years have the option to be credited in some way.
If you have participated in the development process in any way e.g. protocol design, writing code, UI design, writing tests, testing release candidates, reporting issues, translating the application or documentation, promoting metadata resistant applications or any other meaningful contribution to the Cwtch ecosystem we want to offer you the option to have your name or handle credited in both the source code repository and the application itself.
![](/img/devlog1.png)
<!--truncate-->
## A History of Cwtch Contibutions and Anonmymity
In the early days of Cwtch we made the explicit decision to not include credits anywhere in the application, and to accept contributions anonymously over a variety of channels, including Cwtch itself.
Due to the nature of the application, and the privacy and metadata resistant space in general, we have always had a policy of evaluating contributions based on merit, and not on identity. This approach means that, while we do have contributors whose identity is known to us in some way, we have many who we know only by writing style, contribution type, or cwtch address.
We understand that many people much prefer it this way, and have no desire to have any identity linked to the Cwtch project. To those people we offer our deep gratitude. Thank you. You have made Cwtch what it is. (And if you ever want Cwtch Stickers - please let us know!)
However, it would not be right of us to release Cwtch Stable without at least one final offer to all contributors. If you want to be credited for your contributions to Cwtch then, please, reach out to us and let us know of a way to appropriately credit you.
## Getting in Touch
You can ask for credit via email (team@cwtch.im), or via Cwtch (either publicly via the [Cwtch Release Candidate Testers groups](https://docs.cwtch.im/docs/contribute/testing#join-the-cwtch-release-candidate-testers-group), or privately in a message to Sarah: `icyt7rvdsdci42h6si2ibtwucdmjrlcb2ezkecuagtquiiflbkxf2cqd`).
You can also [open an issue](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/new).
When asking, please provide a name or handle, and if desired, a rough description of the contribution (e.g. development, design, documentation, translating, funding). Anyone who does not provide a description will be grouped under a general thanks section.
This is an open offer. If at any time you change your mind and wish to have credit added (or removed) please let us know.
I want to take another opporunity to say, regardless of whether you wish to be publicly credited for your work on Cwtch, **thank you**.
## Stay up to date!
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)

7
i18n/it/docusaurus-plugin-content-docs-docs-developer/current/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Developers Handbook",
"position": 10,
"link": {
"type": "generated-index"
}
}

7
i18n/it/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Building a Cwtch App",
"position": 10,
"link": {
"type": "generated-index"
}
}

123
i18n/it/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/building-an-echobot.md Normal file
View File

@ -0,0 +1,123 @@
---
sidebar_position: 3
---
# Building a Cwtch Echobot
In this tutorial we will walk through building a simple Cwtch Echobot. A bot that, when messaged, simply responds with the message it was sent.
For completeness, we will build an Echobot in multiple difference Cwtch frameworks to get a feel for the different levels of functionality offered by each library or framework.
## Using CwtchBot (Go)
:::info CwtchBot Framework
This tutorial uses the CwtchBot framework.
:::
Start by creating a new Go project, and a file `main.go`. In the `main` function:
```go
package main
import (
"cwtch.im/cwtch/event"
"cwtch.im/cwtch/model"
"cwtch.im/cwtch/model/attr"
"cwtch.im/cwtch/model/constants"
"fmt"
"git.openprivacy.ca/sarah/cwtchbot"
_ "github.com/mutecomm/go-sqlcipher/v4"
"os/user"
"path"
)
func main() {
user, _ := user.Current()
cwtchbot := bot.NewCwtchBot(path.Join(user.HomeDir, "/.echobot/"), "echobot")
cwtchbot.Launch()
// Set Some Profile Information
cwtchbot.Peer.SetScopedZonedAttribute(attr.PublicScope, attr.ProfileZone, constants.Name, "echobot2")
cwtchbot.Peer.SetScopedZonedAttribute(attr.PublicScope, attr.ProfileZone, constants.ProfileAttribute1, "A Cwtchbot Echobot")
fmt.Printf("echobot address: %v\n", cwtchbot.Peer.GetOnion())
for {
message := cwtchbot.Queue.Next()
cid, _ := cwtchbot.Peer.FetchConversationInfo(message.Data[event.RemotePeer])
switch message.EventType {
case event.NewMessageFromPeer:
msg := cwtchbot.UnpackMessage(message.Data[event.Data])
fmt.Printf("Message: %v\n", msg)
reply := string(cwtchbot.PackMessage(msg.Overlay, msg.Data))
cwtchbot.Peer.SendMessage(cid.ID, reply)
case event.ContactCreated:
fmt.Printf("Auto approving stranger %v %v\n", cid, message.Data[event.RemotePeer])
// accept the stranger as a new contact
cwtchbot.Peer.AcceptConversation(cid.ID)
// Send Hello...
reply := string(cwtchbot.PackMessage(model.OverlayChat, "Hello!"))
cwtchbot.Peer.SendMessage(cid.ID, reply)
}
}
}
```
## Using Imp (Rust)
:::info Imp (Rust) Bot Framework
This tutorial uses the Imp Cwtch Bot framework (Rust). This framework is currently a work-in-progress and the API design is subject to change. IMP is also based on libcwtch-rs which is currently based on an older pre-stable API version of Cwtch. We are planning in updating libcwtch-rs in Summer 2023.
:::
```go
use std::borrow::BorrowMut;
use std::thread;
use chrono::{DateTime, FixedOffset};
use libcwtch;
use libcwtch::CwtchLib;
use libcwtch::structs::*;
use libcwtch::event::*;
use cwtch_imp::imp;
use cwtch_imp::behaviour::*;
use cwtch_imp::imp::Imp;
const BOT_HOME: &str = "~/.cwtch/bots/echobot";
const BOT_NAME: &str = "echobot";
struct Echobot {}
fn main() {
let behaviour: Behaviour = BehaviourBuilder::new().name(BOT_NAME.to_string()).new_contact_policy(NewContactPolicy::Accept).build();
let event_loop_handle = thread::spawn(move || {
let mut echobot = Echobot {};
let mut bot = Imp::spawn(behaviour,String::new(), BOT_HOME.to_string());
bot.event_loop::<Echobot>(echobot.borrow_mut());
});
event_loop_handle.join().expect("Error running event loop");
}
impl imp::EventHandler for Echobot {
fn on_new_message_from_contact(&self, cwtch: &dyn libcwtch::CwtchLib, profile: &Profile, conversation_id: ConversationID, handle: String, timestamp_received: DateTime<FixedOffset>, message: Message) {
let response = Message {
o: MessageType::TextMessage,
d: message.d,
};
cwtch.send_message(&profile.profile_id, conversation_id, &response);
}
fn handle(&mut self, cwtch: &dyn CwtchLib, profile_opt: Option<&Profile>, event: &Event) {
match event {
Event::NewPeer { profile_id, tag, created, name, default_picture, picture, online, profile_data } => {
println!(
"\n***** {} at {} *****\n",
name, profile_id.as_str()
);
}
_ => (),
};
}
}
```

29
i18n/it/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/core-concepts.md Normal file
View File

@ -0,0 +1,29 @@
---
sidebar_position: 2
---
# Core Concepts
This page documents the core concepts that you, as a Cwtch App Developer, will encounter fairly frequently.
## Cwtch Home Directory
Often referred to as `$CWTCH_HOME`, the Cwtch application home directory is the location where Cwtch stores all information from a Cwtch application.
## Profiles
Cwtch profiles are saved as encrypted sqlite3 databases. You will rarely/never have to interact directly with the database. Instead each library provides a set of interfaces to interact with the Cwtch App, create profiles, manage profiles, and engage in conversations.
## The Event Bus
Regardless of which library you end up choosing, the one constant interface you will have to get used to is the EventBus. Cwtch handles all asynchronous tasks (e.g. receiving a message from a peer) automatically, eventually placing a message on the EventBus. Application can subscribe to certain kinds of messages e.g. `NewMessageFromPeer` and setup an event handler to run code in response to such a message.
For an example see the Echo Bot tutorial.
## Settings
Most Cwtch settings (with the exception of experiments) are designed for downstream graphical user interfaces e.g. themes / column layouts - in particular the Cwtch UI. As such these settings are not used at all by Cwtch libraries, and are only intended as a convenient storage place for UI configuration.
### Experiments
Certain Cwtch features are [gated behind experiments](/docs/category/experiments). These experiments need to be enabled before functionality related to them will activate. Different libraries may expose different experiments, and some libraries may not support certain experiments at all.

23
i18n/it/docusaurus-plugin-content-docs-docs-developer/current/building-a-cwtch-app/intro.md Normal file
View File

@ -0,0 +1,23 @@
---
sidebar_position: 1
---
# Getting Started
## Choosing A Cwtch Library
### Cwtch Go Lib
The official Cwtch library is written in Go and can be found at [https://git.openprivacy.ca/cwtch.im/cwtch](https://git.openprivacy.ca/cwtch.im/cwtch). This library allows access to all Cwtch functionality.
### CwtchBot
We also provide a specialized Cwtch Bot framework in Go that provides a more lightweight and tailored approach to building chat bots. For an introduction to building chatbots with the CwtchBot framework check out the [building an echobot tutorial](/developing/building-a-cwtch-app/building-an-echobot#using-cwtchbot-go).
### Autobindings (C-bindings)
The [official c-bindings for Cwtch](https://git.openprivacy.ca/cwtch.im/autobindings) are automatically generated from the Cwtch Go Library. The API is limited compared to accessing the Cwtch Go Library directly, and is explicitly tailored towards building the Cwtch UI.
### libCwtch-rs (Rust)
An experimental rust-fied version of Cwtch Autobindings is available in [libCwtch-rs](https://crates.io/crates/libcwtch). While we have plans to officially adopt rust bindings in the future, right now Rust support lags behind the rest of the Cwtch ecosystem.

20
i18n/it/docusaurus-plugin-content-docs-docs-developer/current/intro.md Normal file
View File

@ -0,0 +1,20 @@
---
sidebar_position: 1
---
# Introduction to Cwtch Development
- [Core Concepts](/developing/building-a-cwtch-app/core-concepts)
- [Security Handbook](/security/intro)
## Contributing to Cwtch Core
- [Release and Packaging Process](/developing/release)
## Building Cwtch Bots
- [Choosing a Library](/developing/building-a-cwtch-app/intro#choosing-a-cwtch-library)
- [Echobot Tutorial](/developing/building-a-cwtch-app/building-an-echobot)

62
i18n/it/docusaurus-plugin-content-docs-docs-developer/current/release.md Normal file
View File

@ -0,0 +1,62 @@
---
sidebar_position: 1
---
# Release and Packaging Process
Cwtch builds are automatically constructed via Drone. In order to be built the tasks must be approved by a project team member.
## Automated Testing
Drone carries out a suite of automated tests at various stages of the release pipeline.
| Test Suite | Repository | Notes |
| ----------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------- |
| Integration Test | cwtch.im/cwtch | A full exercise of peer-to-peer and group messaging |
| File Sharing Test | cwtch.im/cwtch | Tests that file sharing and image downloading work as expected |
| Automated Download Test | cwtch.im/cwtch | Tests that automated image downloading (e.g. profile pictures) work as expected |
| UI Integration Test | cwtch.im/cwtch-ui | A suite of Gherkin tests to exercise various UI flows like Creating / Deleting profiles and changing settings |
## Cwtch Autobindings
Drone produces the following build artifacts for all Cwtch autobindings builds.
| Build Artifact | Platform | Notes |
| -------------------------- | -------- | ---------------------------------------------------------- |
| android/cwtch-sources.jar | Android | gomobile derived source code for the Android Cwtch library |
| android/cwtch.aar | Android | Android Cwtch library. Supports arm, arm64, and amd64. |
| linux/libCwtch.h | Linux | C header file |
| linux/libCwtch.so | Linux | x64 shared library |
| windows/libCwtch.h | Windows | C header file |
| windows/libCwtch.dll | Windows | x64 bit shared library |
| macos/libCwtch.arm64.dylib | MacOS | Arm64 shared library |
| macos/libCwtch.x64.dylib | MacOS | x64 shared library |
## UI Nightly Builds
We make unreleased versions of Cwtch available for testing as [Cwtch Nightlies](/docs/contribute/testing#cwtch-nightlies).
Each nightly build folder contains a collection of build artifacts e.g. (APK files for Android, installer executables for Android) in single convenient folder. A full list of build artifacts currently produced is as follows:
| Build Artifact | Platform | Notes |
| --------------------------- | -------- | -------------------------------------------------------------------------------------- |
| cwtch-VERSION.apk | Android | Supports arm, arm64, and amd64. Can be sideloaded. |
| cwtch-VERSION.aab | Android | Android App Bundle for publishing to appstores |
| Cwtch-VERSION.dmg | MacOS | |
| cwtch-VERSION.tar.gz | Linux | Contains the code, libs, and assets in addition to install scripts for various devices |
| cwtch-VERSION.zip | Windows | |
| cwtch-installer-VERSION.exe | Windows | NSIS powered installation wizard |
Nightly builds are regularly purged from the system
## Official Releases
The Cwtch Team meets on a regular basis and reaches consensus based on nightly testing feedback and project roadmaps.
When the decision is made to cut a release build, a nightly version is built with a new git tag reflecting the release version e.g. `v.1.12.0`. The build artifacts are then copied to the Cwtch release website to a dedicated versioned folder.
### Reproducible Builds
We use [repliqate](https://git.openprivacy.ca/openprivacy/repliqate) to provide [reproducible build scripts for Cwtch](https://git.openprivacy.ca/cwtch.im/repliqate-scripts).
We update the `repliqate-scripts` repository with scripts for all official releases. Currently only Cwtch bindings are reproducible