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

Compare commits

base: cwtch.im:staging
Branches Tags
cwtch.im:staging
cwtch.im:main
cwtch.im:de12
cwtch.im:sarah_notes
Guido:main
Guido:de12
Guido:sarah_notes
..
compare: Guido:main
Branches Tags
Guido:main
Guido:de12
Guido:sarah_notes
cwtch.im:staging
cwtch.im:main
cwtch.im:de12
cwtch.im:sarah_notes

1 Commits
staging ... main

Author SHA1 Message Date
Guido Drehsen 5b25d27409 Merge pull request 'main' (#1) from cwtch.im/docs.cwtch.im:main into main 
Reviewed-on: Guido/docs.cwtch.im#1
 2023-04-16 14:27:12 +00:00
4283 changed files with 7608 additions and 109444 deletions
Show Stats Expand all files Collapse all files

7
.gitignore vendored
View File

@ -20,10 +20,3 @@ yarn-debug.log*
yarn-error.log*
.idea
.yarn
.pnp.cjs
.pnp.loader.mjs
yarn.lock
#build-staging/
staging/

3
.yarnrc.yml
View File

@ -1,3 +0,0 @@
nodeLinker: node-modules
yarnPath: .yarn/releases/yarn-1.22.19.cjs

15
README.md
View File

@ -1,4 +1,4 @@
# Cwtch Website
# Website
This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
@ -47,18 +47,11 @@ $ npm run build
This command generates static content into the `build` directory and can be served using any static contents hosting service.
### Deployment to Stable
### Deployment
Using git.openprivacy.ca to manage but deployment by push is to a separate docs server. Add your key to the docusaurus account's .ssh/authorized_keys and then
Using git.openprivacy.ca to manage but deployment by push is to a seperate docs server. Add your key to the docusaurus account's .ssh/authorized_keys and then
```
$ git remote add docs docusaurus@docs.cwtch.im:/home/docusaurus/git/docs.cwtch.im
$ git push docs staging
$ git push docs main
```
### Deployment to Prod
The staging website must be manually promoted to prod. This can be done by logging into the docs server as `docusarus` and running:
`rsync -a --delete staging/ prod/`

90
blog/2023-01-06-path-to-cwtch-stable.md
View File

@ -1,90 +0,0 @@
---
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)

229
blog/2023-01-13-cwtch-stable-api-design.md
View File

@ -1,229 +0,0 @@
---
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.)

123
blog/2023-01-20-reproducible-builds-bindings.md
View File

@ -1,123 +0,0 @@
---
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)

162
blog/2023-01-27-platform-support.md
View File

@ -1,162 +0,0 @@
---
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)

84
blog/2023-02-03-cwtch-testing-i.md
View File

@ -1,84 +0,0 @@
---
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)

54
blog/2023-02-10-android-reproducibility.md
View File

@ -1,54 +0,0 @@
---
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)

68
blog/2023-02-17-cwtch-testing-ii.md
View File

@ -1,68 +0,0 @@
---
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)

89
blog/2023-02-24-autogenerating-cwtch-bindings.md
View File

@ -1,89 +0,0 @@
---
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)

116
blog/2023-03-03-autobindings-optional-experiments.md
View File

@ -1,116 +0,0 @@
---
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)

56
blog/2023-03-10-cwtch-documentation.md
View File

@ -1,56 +0,0 @@
---
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)

81
blog/2023-03-29-cwtch-1.11.md
View File

@ -1,81 +0,0 @@
---
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)

100
blog/2023-03-31-cwtch-stable-roadmap-update.md
View File

@ -1,100 +0,0 @@
---
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)

72
blog/2023-04-06-availability-and-profile-attributes.md
View File

@ -1,72 +0,0 @@
---
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)

64
blog/2023-04-28-developer-docs.md
View File

@ -1,64 +0,0 @@
---
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)

56
blog/2023-06-07-new-nightly.md
View File

@ -1,56 +0,0 @@
---
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, nightly]
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)

80
blog/2023-06-16-cwtch-1.12.md
View File

@ -1,80 +0,0 @@
---
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/devlog1_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/devlog1.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)

82
blog/2023-07-05-cwtch-stable-roadmap-update.md
View File

@ -1,82 +0,0 @@
---
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)

88
blog/2023-07-14-cwtch-ui-reproducible-builds.md
View File

@ -1,88 +0,0 @@
---
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)

72
blog/2023-07-26-cwtch-stable-call-for-credits.md
View File

@ -1,72 +0,0 @@
---
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)

43
blog/2023-08-03-nightly-preview-conversation-search.md
View File

@ -1,43 +0,0 @@
---
title: "Nightly Preview: Conversation Search"
description: "A new Cwtch Nightly contains a first cut of Conversation Search."
slug: cwtch-nightly-preview-conversation-search
tags: [cwtch, cwtch-stable, nightly, search, preview]
image: /img/devlog10_small.jpg
hide_table_of_contents: false
authors:
- name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
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-08-02-20-24-v1.12.0-19-g75b7](https://build.openprivacy.ca/files/flwtch-2023-08-02-20-24-v1.12.0-19-g75b7/).
This nightly contains a first cut of Conversation Search, in addition to several bug fixes impacting effectiveness of the contact retry plugin when combined with a large contact list, and an unstable network
connection. Finally we have made a few tweaks to the font scaling based on feedback.
Please see the contribution documentation for advice on [submitting feedback](/docs/contribute/testing#submitting-feedback)
![](/img/search-nightly.png)
<!--truncate-->
## 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)

43
blog/2023-08-18-whonix-nightly-preview.md
View File

@ -1,43 +0,0 @@
---
title: "Nightly Preview: Whonix Support, Default Save History, Bug Fixes"
description: "A new Cwtch Nightly contains a first cut of support for Whonix, Default Save History, Bug Fixes"
slug: cwtch-nightly-preview-whonix-save-history
tags: [cwtch, cwtch-stable, nightly, whonix, preview]
image: /img/devlog10_small.png
hide_table_of_contents: false
authors:
- name: Sarah Jamie Lewis
title: Executive Director, Open Privacy Research Society
image_url: /img/sarah.jpg
---
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-08-22-23-27-v1.12.0-25-ge019f](https://build.openprivacy.ca/files/flwtch-2023-08-22-23-27-v1.12.0-25-ge019f/).
This nightly contains a first cut of [support for Whonix](https://docs.cwtch.im/docs/platforms/whonix), a new global setting for managing how conversation
history is preserved, in addition to several bug fixes reported in the last nightly.
Please see the contribution documentation for advice on [submitting feedback](/docs/contribute/testing#submitting-feedback)
![](/img/devlog10.png)
<!--truncate-->
## 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)

74
blog/2023-09-06-cwtch-stable-roadmap-update.md
View File

@ -1,74 +0,0 @@
---
title: September Cwtch Stable Roadmap Update
description: "Back in July 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-sept
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 year.
Today, as we approach the release of Cwtch Stable we would like to provide another update on the ongoing work, and the remaining blockers to certifying a Cwtch Stable release. We also have a new nightly to
test out!
![](/img/devlog1.png)
<!--truncate-->
## Stable Blocker and Timelines
Back in January we set the ambitious goal of launching a Cwtch Stable in the Summer of 2023. We had planned to finish all of the work
prior to the end of August. The vast majority of that work has now been completed - what remains is captured in [Stable Blockers](https://git.openprivacy.ca/cwtch.im/cwtch-ui/projects/15) project which tracks the current state
of work that we have marked as being critical to a Cwtch Stable release.
Despite there being a large number of remaining issues, many of the outstanding work is inter-related, relies on common implementations or
are tightly coupled together.
In summary the final few areas of concern are:
- The ability to delete or purge group conversation history. (For historical reasons storing group history was once considered necessary
but this is no longer the case. We plan on enabling this feature in the coming weeks)
- Appropriate handling of less common system configurations. Cwtch current emits non-fatal exceptions if certain services are not available
e.g. dbus. This is related to former 3rd party code for managing networking and notification.
- A final UI pass. We have designs for better ways to convey certain information and functionality. We would like to implement these
prior to a stable release.
Because of this, we have set a goal of labelling a Cwtch Stable Release Candidate by **30th September 2023**.
## A New Nightly
There is a [new nightly version of Cwtch available for testing (2023-09-06-21-25-v1.12.0-33-g05b1)](https://build.openprivacy.ca/files/flwtch-2023-09-06-21-25-v1.12.0-33-g05b1/). This version contains a few bug fixes related to file share management,
in addition to a significant improvement in the connection management code.
Additionally, thanks to volunteer testers [and contributors](https://git.openprivacy.ca/cwtch.im/cwtch-ui/pulls/715) the installation instructions
and packaged configurations for Whonix have been much improved. See [running Cwtch on Whonix](https://docs.cwtch.im/docs/platforms/whonix) for more information.
## Get Involved
Staff and volunteer shortages have slightly extended our original estimates. In particular we are bottle-necked on review effort for new code. This is
why we would like to encourage people to test out the latest nightlies and report any bugs/issues/improvements.
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)

127
blog/2023-09-27-cwtch-1.13-nightly.md
View File

@ -1,127 +0,0 @@
---
title: Cwtch 1.13 Stable Release Candidate
description: "Cwtch 1.13 (Stable Release Candidate)"
slug: cwtch-1-13
tags: [cwtch, cwtch-stable, release]
image: /img/picnic1.13.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.13 is now available for download](https://cwtch.im/download)!
Cwtch is a communication application (and associated libraries) that uses Tor v3 Onion Services to establish surveillance resistant channels between people. Cwtch has been designed to be
secure, private, and resilient.
Cwtch 1.13 is the culmination of the last few years of effort by the Cwtch team, and is the first release that meets our bar to be labelled a [Cwtch Stable](/blog/path-to-cwtch-stable) candidate.
While much more work remains, we are now very confident in the state of the Cwtch library, and the Cwtch UI. We are prepared to make certain commitments regarding peer-to-peer messaging, the UI,
and experimental interfaces. In this post we will chart the journey that got us to this point, highlight what is in this new release, and talk about our next steps.
![](/img/devlog14.png)
<!--truncate-->
## Cwtch Stable and Beyond!
Over five years ago, on the 28th June 2018, we published the first official announcement of Cwtch. Throughout 2019 we published various Alpha releases of Cwtch. The original plan was to release a Cwtch Beta in 2020.
Like so many other projects in 2020, Cwtch Beta was delayed, and towards the end of 2020 it became clear that our original approach to a cross-platform UI was not sustainable long term.
Finally, in June 2021 we launched Cwtch Beta 1.0. We have spent the years since refining beta, adding features, and responding to feedback.
We have now reached a pivotal moment in Cwtch, one that the team has been working towards for many years. We now believe that Cwtch has reached a point where people can use core features, and enable
experimental features, with a confidence that any risks are well understood and appropriately mitigated. As such we are dropping the "beta" label.
Some features, like automatically downloading and displaying images, will always carry some risk - as such these will always remain off-by-default in Cwtch.
However, if approporate precautions are taken (like never accepting conversations from untrusted entities) then these features can be turned on and used without additional considerable risk.
Further, we believe that the API presented by libCwtch has reached a point where its core design is unlikely to require changes - and as such are prepared to make additional committements to the stability
of that API going forward. Any new functionality will be provided by new interfaces, or otherwise be handled behind the scenes.
This is certainly not the end of Cwtch development. We have big plans for the future including the long-anticipated Hybrid Groups
implementation, a light client for restricted mobile operating systems, a return of the bulletin boards overlay, and much more.
We want to extend a huge thank you to everyone who helped Cwtch get this far. We could not have done it without you. If you
have helped in any way and would like to be listed in the contributor credits [please reach out](https://docs.cwtch.im/blog/cwtch-stable-call-for-credits).
## A Big Thank You
On a personal note, as Executive Director of Open Privacy, and lead of the Cwtch project. I want to take this opportunity to thank the Cwtch core team across time: Dan Ballard, Erinn Atwater and Marcia Díaz Agudelo - this work isn’t glamorous, and doesn’t pay well,
there is no profit to be made in decentralizing power. A lack of funding means we don't all work together any more, but you all still contribute so much to this project.
It takes a special kind of person to be willing to spend a significant fraction of their lives devoted to working on something for the benefit of other people.
Thank you for believing in this mission.
I also want to say thank you to all the people who tested Cwtch over the years and provided invaluable feedback, bug reports and critique.
You have made Cwtch what it is today, and I am sure you will be making it even better in the coming weeks, months, and years.
Last, but certainly not least, I want to extend a big thank you to all of the supporters of Open Privacy around the world - without your donations
and continued enthusiasm for the work that we do, none of this would be possible.
## Download Cwtch 1.13
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).
## In This Release
<figure>
[![](/img/picnic1.13.png)](/img/picnic1.13.png)
<figcaption>A screenshot of Cwtch 1.13</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:**
- **Conversation Search** - Cwtch can now find messages based on their content.
- **Appear Offline Mode** - in this mode Cwtch does not launch a listening service for inbound contacts, and allows a profile to be more selective in the contacts they connect to.
- **Whonix Support** - new runtime flags make changes that allow Cwtch to [run on Whonix](https://docs.cwtch.im/docs/platforms/whonix)
- **Save History Global Setting** - by default Cwtch deletes all messages on shutdown unless a conversation is otherwise configured. This change allows a user to change this default behaviour.
- **Bug Fixes / Improvements:**
- Based on Flutter 3.13.4
- Updated Android Target to 33
- Profile Status Menu now has many more options, including offline status, edit profile and enabling/disabling profile
- File Sharing Bug Fixes
- Manage shared files now supports re-enabling older file shares
- Improvements towards [UI Reproducible Builds](https://docs.cwtch.im/blog/cwtch-ui-reproducible-builds-linux)
- Server Info now propagates to the UI consistently
- Prevent DBus Exceptions on platforms where it is unsupported
- Packaged Emoji Font
- Fixes to retry manager which have greater improved (re)connection efficacy
- Allow deleting server info in Manage Servers
- **Accessibility / UX:**
- Core translations for **Brazilian Portuguese**, **Danish** , **Dutch**, **French**, **German**, **Italian**, **Norwegian** , **Romanian** , **Russian**, **Polish**, **Slovak**, **Spanish**, **Swahili**, **Swedish**, **Turkish**, and **Welsh**
- Partial translations for **Korean** (37%), **Japanese** (27%), , **Luxembourgish** (20%), **Greek** (15%), **Uzbek** (10%), and **Portuguese** (5%)
- Font Scaling improvements on several screens
## Reproducible Bindings
Cwtch 1.13 is based on libCwtch version `libCwtch-autobindings-2023-09-26-13-15-v0.0.10`.
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.10](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/cwtch-autobindings-v0.0.10)
## 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)

113
blog/2024-01-05-path-to-hybrid-groups.md
View File

@ -1,113 +0,0 @@
---
title: "Path to Hybrid Groups"
description: "A look at how we plan on implementing the next generation of Cwtch multi-party messaging"
slug: path-to-hybrid-groups
tags: [cwtch, hybrid-groups]
image: /img/hybridgroups.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
---
Back in [September 2023 we released Cwtch 1.13](/blog/cwtch-1-13), the first version of Cwtch to be labelled as **stable**,
and a major milestone in Cwtch development.
With the Cwtch interface now stable, we are in a position to begin a new phase in Cwtch development: a Path towards
**Hybrid Groups**.
![](/img/hybridgroups.png)
<!--truncate-->
## The Problem with Cwtch Groups
One of the unique features of Cwtch is that [groups](/docs/groups/introduction) are dependent on [untrusted infrastructure](/security/components/cwtch/server).
Because of this, at their most basic, a Cwtch group is simply an agreement between a set of peers on a common
cryptographic key, and a common (set of) untrusted server(s).
This provides Cwtch Groups with very nice properties such as anonymity to anyone not in the group, but it does mean
that certain other nice properties like member flexibility, and credential rotation are difficult to achieve.
We want to allow people to make the right trade-off when it comes to their own risk models, i.e. to be able to trade
efficiency for trust when that decision makes sense.
To do that we need to introduce a new class of group into Cwtch, something we are calling **Hybrid Groups**.
## What Are Hybrid Groups?
The goal of hybrid groups is to balance the security properties of Cwtch peer-to-peer communication with the
properties of untrusted infrastructure.
This is done by augmenting existing Cwtch Groups with an additional layer of peer-to-peer communication in order to provide
efficient participant management, key rotation, and other useful features.
### Levels of Hybrid Groups
In practice, we imagine there will be a few different levels of Hybrid Group, reflecting different trade-offs between inter-peer trust,
communication efficiency, and group security.
There are **Traditional Groups**, these have similar properties to the existing Cwtch Groups. Highly inefficient, but essentially
require zero-trust on behalf of participants other than an expectation that the key is kept secret.
We plan to introduce **Managed Groups**: A new kind of group where all participants explicitly trust a given always-online peer (e.g. a bot) with group operations. These
will be highly efficient, at the cost of that explicit trust (if that peer behaves maliciously then certain properties are broken). Managed groups will
be the first Cwtch groups to allow **Contractable** and **Expandable** groups, and more efficient **Key Rotation**.
To start with this *trusted peer* will take the form of an external bot (powered by [a cwtch bot framework](/developing/building-a-cwtch-app/building-an-echobot)) however we
eventually plan to expose this capability as part of the Cwtch UI.
And finally a category of **Augmented Groups**: An extension of Managed Groups that places configurable restrictions of the trust given to
the peer e.g. by requiring participants to take part in a meta-protocol that confirms certain actions before they are carried out (preventing
the trusted-peer from harming properties like **Participant Consistency**.
## Group Messaging Metadata
As with the rest of Cwtch, our ultimate goal is that no metadata (and specifically as part of this work, no group metadata e.g. membership, message timing) be
available to a party outside of the group.
Traditional Cwtch Groups take this to the extreme, and the expense of long syncing times, and a high possibility of disruption. Managed Groups
and Augmented groups will allow communities to make the right trade-offs allowing for greater resilience and faster syncing.
## A Rough Timeline (Q1: Week 0 - Week 10 2024)
- **Week 0** - Planning Q1 Cwtch Timeline (this devlog), minor bug fixes and other small UI-focused work originating from reports and feedback
from [Cwtch testers](/docs/contribute/testing).
- **Week 1** - Work begins on exposing **Enhanced Permissions** in the Cwtch library. These are essential to implementing many of the aspects
of the new group design, as well as improving other parts of contact management. (Expect more about this in a future devlog). Also, a formal model for Managed Groups will be created and documented.
This will form the basis of the implementation.
- **Week 2** - At this point we should be able to begin designing the Managed Group Extension to Cwtch. This will use the Cwtch Event Hooks API
to respond to Peer events to manage groups. During this work, we also expect to migrate the legacy group code into it's own similar extension to make
best use of the APIs.
- **Week 3** - Towards the end of January we expect to have a complete formal model of Managed Groups and to be able to start integrating the new extensions into the
Cwtch-UI. We also expect to be in the process of releasing a new 1.14 version of Cwtch that supports Enhanced Permissions.
- **Weeks 4 - Week 6** - February marks the 6th anniversary of the founding of [Open Privacy Research Society](https://openprivacy.ca), and our organizational year end. During this
time core members of the Cwtch team are often involved in administrative tasks that need to be done during this time, as such we are not planning to make too much progress on Cwtch during this time.
- **Weeks 7 - Week 10** - As we approach March, we will be formally integrating Managed Groups in Cwtch, and planning a Cwtch 1.15 release which will feature the new group type. During this time we will also be updating
Cwtch [Group Documentation](https://docs.cwtch.im/docs/category/groups) .
Once Managed Groups have been rolled out, we will assess what we have learned and proceed with similar steps for
Augmented Groups in Q2 (more on that in a later devlog!).
## Stay up to date!
As always, we will be regularly updating this devlog [and other channels](https://fosstodon.org/@cwtch) as we continue to make progress towards
surveillance resistant infrastructure!
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)

107
blog/2024-01-12-enhanced-permissions.md
View File

@ -1,107 +0,0 @@
---
title: "Enhanced Permissions"
description: "An introduction to the new fine-grained permissions API exposed in libCwtch"
slug: enhanced-permissions
tags: [cwtch, hybrid-groups, acl]
image: /img/enhancedpermissions.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 week](/blog/path-to-hybrid-groups), we mentioned that **enhanced permissions** are essential to implementing many of the aspects
of the new **hybrid groups** design.
In this post we will introduce the new enhanced permissions api in libCwtch, explain why it is needed, and how future releases of Cwtch will manage
conversation-level permissions.
![](/img/enhancedpermissions.png)
<!--truncate-->
## How do conversation-level permissions work in Cwtch right now?
Underneath the libCwtch API, all conversations maintain an access control list. For peer-to-peer conversations this list has a single entry, keyed by
the handle of the contact.
Currently, this access control list only maintains the `Blocked`-state of the contact. If a user blocks another, then this is where the flag is stored. While
there are other fields in this list, they have been unused, until now.
Additionally, each conversation also stored an `Accepted` flag, indicating if the user has approved a contact request. The `Accepted` flag has many different
effects including whether certain features (like file sharing) are accessible, or whether connection attempts with the contact are tried automatically.
## What Are Enhanced Permissions?
The current approach has several issues; the major issue being that profiles have minimal control over how they interact with contacts. Ideally, you should be able to
automatically attempt to connect with a given cwtch user, but not allow file shares, for example.
This is the initial driving use case behind Enhanced Permissions. Exposing this underlying ACL and augmenting it with additional flags like `ShareFiles`,
`RenderImages`, and `AutoConnect`.
## The API
Enhanced permissions will be available through a new set of low level libCwtch APIs i.e.:
```
UpdateConversationAccessControlList(id int, acl model.AccessControlList) error
EnhancedUpdateConversationAccessControlList(conversation int, serialized_acl string) error
GetConversationAccessControlList(conversation int) (model.AccessControlList, error)
EnhancedGetConversationAccessControlList(conversation int) (string, error)
```
As with other libCwtch APIs the `Enhanced` functions speak JSON and be suitable for integration with UIs and other clients that cannot speak the
Go model.
`AccessControlList` maintains it's current structure, while `AccessControl` itself has been augmented with the fields
described in the previous section.
Existing access-control APIs e.g. `AcceptConversation`, `BlockConversation` and `UnblockConversation` have been updated
internally to use the augmented `AccessControl` model, and will be able to be safely used by existing and future clients.
However, the `Accepted` field in the `Conversation` model is now considered deprecated, and will be removed in a future Cwtch version.
## How will Migration Work?
To simplify migration newer versions of Cwtch will detect if Enhanced Permissions have been enabled, and if they haven't will automatically turn on
all new flags for `Accepted` conversations. This will maintain behaviour between versions, and should minimize any potential confusion.
You will then be able to modify this ACL on a per-conversation level in the Cwtch UI.
## When will Enhanced Permissions be Available?
We are aiming to roll out a nightly with Enhanced Permissions in the coming weeks. We will then spend some time iterating
on the UI to ensure that the new permissions are understandable and usable.
## How does this fit into Hybrid Groups?
That is not the end of the story as far as Enhanced Permissions go. As I mentioned above for peer-to-peer conversations the
ACL has a single entry.
For Hybrid Groups, this list will have multiple entries, for each member of the group. This will allow group admins to
control who can post to a group, and what kinds of messages they can post.
How this list will be maintained, propagated, and authenticated by group members will be a topic of a future development log.
## Stay up to date!
As always, we will be regularly updating this devlog [and other channels](https://fosstodon.org/@cwtch) as we continue to make progress towards
surveillance resistant infrastructure!
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)

77
blog/2024-02-14-cwtch-1.14.md
View File

@ -1,77 +0,0 @@
---
title: Cwtch 1.14
description: "Cwtch 1.14 is now available to download"
slug: cwtch-1-14
tags: [cwtch, cwtch-stable, release]
image: /img/Themes_collage.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.14 is now available for download](https://cwtch.im/download)!
Cwtch is a communication application (and associated libraries) that uses Tor v3 Onion Services to establish surveillance resistant channels between people. Cwtch has been designed to be
secure, private, and resilient.
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).
## In This Release
<figure>
[![](/img/Themes_collage.png)](/img/Themes_collage.png)
<figcaption>We have made many changes to Cwtch themeing in 1.14, including new Custom Themes</figcaption>
</figure>
<!--truncate-->
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:**
- **Custom Themes** - You can now load [custom themes](https://docs.cwtch.im/docs/contribute/themes) into Cwtch.
- **Message View Backgrounds** - This release contains the first support for (optional) background images in the message view. Future releases will allow per-conversation images.
- **Bug Fixes / Improvements:**
- Fixed tor connectivity in newer Tails releases
- Fixes in the Retry Plugin for better managing of a large number of contacts
- Several UX improvements for font scaling, and styling
- Fixed Android File Sharing Bug which prevent downloads of [non-previewed files](https://docs.cwtch.im/docs/settings/experiments/image-previews-and-profile-pictures).
- Fixed Android File Sharing Bug that resulted in a UI reset triggered by a rate race condition between reconnection and new message arriving
- Split Settings Pane into multiple tabs for easier navigation of options
- Fixed contact row date time/localization inconsistency
- Fixed contact row issue where `LANG` wasn't set on some linux systems
- libCwtch now support older Mac releases (min 10.12)
- Updates images and descriptions in the Windows Installer
- **Accessibility / UX:**
- Core translations for **Brazilian Portuguese**, **Danish** , **Dutch**, **French**, **German**, **Italian**, **Norwegian** , **Romanian** , **Russian**, **Polish**, **Slovak**, **Spanish**, **Swahili**, **Swedish**, **Turkish**, and **Welsh**
- Partial translations for **Korean** (41%), **Japanese** (26%), , **Luxembourgish** (19%), **Greek** (15%), **Uzbek** (9%), and **Portuguese** (5%)
- **Theme Refresh** - Many small adjustments to existing themes to make them more accessible
## Reproducible Bindings
Cwtch 1.14 is based on libCwtch version `libCwtch-autobindings-2024-02-12-11-04-v0.0.12`.
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.12](https://git.openprivacy.ca/cwtch.im/repliqate-scripts/src/branch/main/cwtch-autobindings-v0.0.12)
<hr/>
## 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)

0
build-staging/.nojekyll
View File

21
build-staging/404.html
View File

File diff suppressed because one or more lines are too long

2
build-staging/assets/css/styles.0f79f894.css
View File

File diff suppressed because one or more lines are too long

BIN
build-staging/assets/files/Themes_collage-ac81d091a47194dcfc2093f45987a300.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 821 KiB

BIN
build-staging/assets/files/aar-diff-cefdff70043215f9b9244cbc0a179078.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 45 KiB

BIN
build-staging/assets/files/attributes-contact-4ba7fccff01d2995a47b45098a47ef93.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 28 KiB

BIN
build-staging/assets/files/attributes-empty-3df496b84657bd88e590c245671de191.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 39 KiB

BIN
build-staging/assets/files/attributes-set-c412ff3d1c5116b11f01cbc56fe1f972.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 36 KiB

BIN
build-staging/assets/files/dl7-after-452769c3b44432627b4533b37b3e9053.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 9.4 KiB

BIN
build-staging/assets/files/dl7-before-38cd04ba78b67745560d72a1872e4443.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 11 KiB

BIN
build-staging/assets/files/picnic-96d07251e7d3691f4f5bd88eecb87e77.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 148 KiB

BIN
build-staging/assets/files/picnic1.12-a06a0594d75387abb048bc8009f595b2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 162 KiB

BIN
build-staging/assets/files/picnic1.13-726725011e7a5b02acf80130b7901db5.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 141 KiB

BIN
build-staging/assets/files/settings-138ef72c7beda06bcdba55491d3f7c26.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 16 KiB

BIN
build-staging/assets/files/settings-full-a068891bad494392f02a68cff0c943cd.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 66 KiB

BIN
build-staging/assets/files/status-busy-3fb73cba568a8a79114c63df9f09c01b.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 29 KiB

BIN
build-staging/assets/files/status-tooltip-busy-e3d123418d62abccb5ab50796aa86747.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 30 KiB

BIN
build-staging/assets/files/status-tooltip-busy-set-5764389ebf8112a9a420c911c424abe5.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 28 KiB

BIN
build-staging/assets/files/status-tooltip-e1b9f7ca4de7c1fb3b3ae39b2e10f578.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 31 KiB

BIN
build-staging/assets/images/4-698e941dd333a7200cddec8d926e9ca9.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 119 KiB

BIN
build-staging/assets/images/BASE_3-a31d3b4ac686c16d510e76ceed179a35.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 38 KiB

BIN
build-staging/assets/images/Themes_collage-ac81d091a47194dcfc2093f45987a300.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 821 KiB

BIN
build-staging/assets/images/aar-diff-cefdff70043215f9b9244cbc0a179078.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 45 KiB

BIN
build-staging/assets/images/attributes-contact-4ba7fccff01d2995a47b45098a47ef93.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 28 KiB

BIN
build-staging/assets/images/attributes-empty-3df496b84657bd88e590c245671de191.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 39 KiB

BIN
build-staging/assets/images/attributes-set-c412ff3d1c5116b11f01cbc56fe1f972.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 36 KiB

BIN
build-staging/assets/images/clickable_links-bb81ced13bf30ba78591fa7f0b5550dd.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 14 KiB

BIN
build-staging/assets/images/dev9-host-disabled-3d95df692e95765ccc97b4da4e35b23e.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 123 KiB

BIN
build-staging/assets/images/devlog1-53937adbfa7a7edf40d34660f71ed0fd.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 544 KiB

BIN
build-staging/assets/images/devlog10-160dd00841ab18c4fc41da81e8c6c133.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 339 KiB

BIN
build-staging/assets/images/devlog12-313b28c3f6bcc28a7df69b0f09ffa4f6.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 382 KiB

BIN
build-staging/assets/images/devlog14-3b9adf25edebfc8385b0b6fcc219d87b.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 66 KiB

BIN
build-staging/assets/images/devlog2-3f3a0725dfb20a2d49da23dd84274ec2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 590 KiB

BIN
build-staging/assets/images/devlog4-3f3e04bb10946b0f668423f66177ab7d.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 430 KiB

BIN
build-staging/assets/images/devlog5-3d09f11235d2bc53dd5e6f68d231cd53.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 334 KiB

BIN
build-staging/assets/images/devlog6-047cb55e43376529b3899ac2a0792f9c.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 380 KiB

BIN
build-staging/assets/images/devlog7-ddd3206f988a859af98340268befb0fa.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 337 KiB

BIN
build-staging/assets/images/devlog8-97ac031095f463e4b5172ac973677415.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 373 KiB

BIN
build-staging/assets/images/devlog9-db5594c3b12bd5d3baf3fe06894e1a6f.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 477 KiB

BIN
build-staging/assets/images/dl7-before-38cd04ba78b67745560d72a1872e4443.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 11 KiB

BIN
build-staging/assets/images/enhancedpermissions-a654ed1dfe43e9abc541278df1fda501.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 484 KiB

BIN
build-staging/assets/images/handbook-banner_small-590e912ab259150170999d6060160909.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 250 KiB

BIN
build-staging/assets/images/hybridgroups-11c21d2516ceadabac8af92290b53a08.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 480 KiB

BIN
build-staging/assets/images/picnic-96d07251e7d3691f4f5bd88eecb87e77.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 148 KiB

BIN
build-staging/assets/images/picnic1.12-a06a0594d75387abb048bc8009f595b2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 162 KiB

BIN
build-staging/assets/images/picnic1.13-726725011e7a5b02acf80130b7901db5.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 141 KiB

BIN
build-staging/assets/images/search-nightly-9b35c1459b05395a184e1b7ed2dd57b2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 25 KiB

BIN
build-staging/assets/images/settings-138ef72c7beda06bcdba55491d3f7c26.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 16 KiB

BIN
build-staging/assets/images/settings-full-a068891bad494392f02a68cff0c943cd.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 66 KiB

BIN
build-staging/assets/images/status-busy-3fb73cba568a8a79114c63df9f09c01b.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 29 KiB

BIN
build-staging/assets/images/status-tooltip-busy-e3d123418d62abccb5ab50796aa86747.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 30 KiB

BIN
build-staging/assets/images/status-tooltip-busy-set-5764389ebf8112a9a420c911c424abe5.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 28 KiB

BIN
build-staging/assets/images/status-tooltip-e1b9f7ca4de7c1fb3b3ae39b2e10f578.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 31 KiB

BIN
build-staging/assets/images/stickers-new-1e9b14bdd638b4907cce833e813a09ad.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 286 KiB

1
build-staging/assets/js/003ad223.d75008d1.js
View File

@ -1 +0,0 @@
"use strict";(self.webpackChunkuser_handbook=self.webpackChunkuser_handbook||[]).push([[8073],{6533:e=>{e.exports=JSON.parse('{"title":"Appearance","slug":"/category/appearance","permalink":"/docs/category/appearance","navigation":{"previous":{"title":"An Introduction to Cwtch App Settings","permalink":"/docs/settings/introduction"},"next":{"title":"Change Language","permalink":"/docs/settings/appearance/change-language"}}}')}}]);

1
build-staging/assets/js/017f0ba6.3ae86d7f.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/01a85c17.31893638.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/0250df79.468e5db8.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/06604d79.c9929cf3.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/06a743f0.eddc01da.js
View File

@ -1 +0,0 @@
"use strict";(self.webpackChunkuser_handbook=self.webpackChunkuser_handbook||[]).push([[3080],{6502:s=>{s.exports=JSON.parse('{"label":"bindings","permalink":"/blog/tags/bindings","allTagsPath":"/blog/tags","count":5,"unlisted":false}')}}]);

1
build-staging/assets/js/081d7fe1.f6d8b732.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/09058439.f1a33b28.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/0991cafe.12ecde70.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/0a9e402c.4d4255ee.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/0be9de06.e2a9d663.js
View File

@ -1 +0,0 @@
"use strict";(self.webpackChunkuser_handbook=self.webpackChunkuser_handbook||[]).push([[7222],{390:e=>{e.exports=JSON.parse('{"permalink":"/blog/tags/api","page":1,"postsPerPage":10,"totalPages":1,"totalCount":1,"blogDescription":"Blog","blogTitle":"Blog"}')}}]);

1
build-staging/assets/js/0d64c1d9.8b201bd2.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/0e384e19.fcd391c0.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/0e3e2a9e.70658b61.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/1075f7cd.de5e7adb.js
View File

File diff suppressed because one or more lines are too long

1
build-staging/assets/js/1252ef76.c600ae8a.js
View File

@ -1 +0,0 @@
"use strict";(self.webpackChunkuser_handbook=self.webpackChunkuser_handbook||[]).push([[815],{5566:e=>{e.exports=JSON.parse('{"label":"developer-documentation","permalink":"/blog/tags/developer-documentation","allTagsPath":"/blog/tags","count":1,"unlisted":false}')}}]);

1
build-staging/assets/js/12bd37d8.3d39aec5.js
View File

@ -1 +0,0 @@
"use strict";(self.webpackChunkuser_handbook=self.webpackChunkuser_handbook||[]).push([[6977],{4388:e=>{e.exports=JSON.parse('{"permalink":"/blog/tags/acl","page":1,"postsPerPage":10,"totalPages":1,"totalCount":1,"blogDescription":"Blog","blogTitle":"Blog"}')}}]);

Some files were not shown because too many files have changed in this diff Show More