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

A few small formatting fixes

This commit is contained in:
Sarah Jamie Lewis 2023-01-12 11:53:55 -08:00
parent 7a22f3c292
commit bc5937695e
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -18,7 +18,7 @@ As we grew, we inserted experimental functionality where it was most accessible
As we move out of Beta and towards Cwtch Stable it is time to revisit these previous decisions with both the benefit of hindsight, and years of real-world testing.
In this post we will outline planned new changes to 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.
In this post we will outline planned new changes to 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](https://docs.cwtch.im/blog/path-to-cwtch-stable), and beyond.
![](/img/devlog2.png)
@ -49,7 +49,7 @@ A summary of the experiments that are currently implements or in design, and the
- **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, Hooks into Peer Events, and additional capability in the ProtocolEngine itself.
- **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
@ -103,7 +103,7 @@ As mentioned in our experiment summary, some functionality needs to be implement
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 Engine 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.
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`:
@ -113,10 +113,10 @@ We are formalizing this subsystem into an interface, similar to the hooked funct
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 engine to encapsulate state.
- `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** engine specific events:
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.