November 2019 Development Update

It’s been quite some time since the launch of the project earlier this year. Not much code has been written just yet because more research and thought has been needed. Instead, the project has been developing proper technical solutions.

First in development was research into a possible new binary-to-text encoding algorithm based on another algorithm, yEnc, developed by Juergen Helbing with the goal of reducing overhead when working with non-text files, like attachments and encryption keys. yEnc leverages the majority of the ASCII character set, unlike the standard encoding algorithm, base64. The test algorithm made a few small changes for compatibility reasons. However, it was discovered that both yEnc and the test algorithm were not compatible with the way text is stored, an encoding algorithm called UTF-8. As a result, development efforts in that direction were halted and, instead, base85 was chosen as the preferred encoding scheme, increasing efficiency while still retaining compatibility.

Also under development is AnTM, a new text format designed for a balance of safety and expressiveness. It was inspired by BBCode, another system originally designed for online message boards. “Why do we need ANOTHER format” you ask? Because HTML is a mess in regard to security, complexity, and privacy. Messages on the Anselus platform need to be expressive without compromising user security. It is very much possible to have both: AnTM is easy to write with just a text editor, easy to read and write from code, privacy-friendly, and closes a potential avenue for attack from bad actors that is made available by e-mail.

The structure and architecture of Anselus Server has also been better fleshed out. Originally, it was thought that avoiding the use of a formal database would reduce complexity, but doing so had the opposite effect. For the moment, PostgreSQL has been chosen to be the first official DBMS supported for Anselus Server, having exemplary support, technical excellence, and cross-platform compatibility. Rust was originally slated to be the language for the server’s production code, but for a number of reasons it was decided that Go should be used instead.

The months ahead will focus on building the server side of individual workspaces, starting with completing the database interaction layer. It is an exciting time for the project to see first steps toward a bright future.