Skip to content
C library for implementing Glitched Epistle clients.
C Other
  1. C 98.3%
  2. Other 1.7%
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

API Docs License Shield


This library is still a WORK IN PROGRESS. It is not done yet.

Progress: [‣‣‣‣____________________________________] Progress shield

(only a rough estimation!)

Glitched Epistle

Client library

This is the Glitched Epistle C library (C11 standard) for implementing clients that interact with the Epistle server backend.

ᐳᐳ Check out the API docs here on

There is also a C# variant available on NuGet.

How to build

You need to have the following requirements set up on your system for this library to build properly:

  • git lfs installed and initialized
    • After installing, make sure you run git lfs install at least once on your system.
  • CMake >= 3.1.0
  • Any of the standard C compilers:
  • git clone --recursive
    • Do not forget the --recursive; you need those submodules ¹ to be cloned as well!
  • cd GlitchedEpistle.Client.C11 && mkdir build && cd build
  • cmake ..
    • If everything went according to plan, you should have your build files written into {repo}/build/. On Unix, you can now just make; on Windows (using MSVC) you can open the generated solution inside Visual Studio >= 2019 and compile from there.


You could download precompiled binaries from the release section and link against those. Vendoring is not that horrible considering the current situation of C/C++ dependency hell.

What is this?

Glitched Epistle is a messaging service that encrypts messages locally (client-side) and submits them to a server-side stored "Convo" (conversation). There are already a few live clients out there, such as the official Windows client and Android (Xamarin Forms).

  • Every message is encrypted using every convo participant's public RSA key individually.
  • The server NEVER stores messages in plaintext and DOES NOT under any circumstance know the user's private message decryption key at any given time.
  • Requests to the backend are cryptographically signed using 4096-bit RSA keys.


Epistle does make use of a few dependencies, but theoretically if you git clone --recursive'd successfully, those should be submoduled into {repo}/lib/ and build without any further ado.

Nonetheless, there's a complete list of dependencies in the lib folder's

Why CMake?!


I use another build system

Great! If you're proficient with it and have the time, you can fork out, write a config for that system that works ² and submit a pull request :)

CMake is not good either. They're all bad. We know that! But you gotta use something, so CMake just seemed the sanest decision (despite its innovative and creative scripting language).

Including Epistle into a project

If you use CMake, you can just add_subdirectory(path/to/this/repo) and target_link_libraries(YourTargetName PRIVATE epistle).

If you use another build system, you need to compile Epistle and its dependencies from source and link them together. In case you decide against static linking, make sure to ship all dependencies, DLLs etc... along with Epistle/have them installed in their correct paths!

[1] There is a great git submodules cheatsheet over on It's very useful, check it out here!

[2] "Spongebob Configs" that just barely work, fail to build on one or more of the major OS'es (Linux/Mac/Windows), fail to link against the required dependencies or simply have a nerdy amount of time/dedication needed to get running WILL NOT BE ACCEPTED. Those pull requests will be rejected! A user should be able to git clone --recursive, cmake .. and compile under 10 minutes without any further steps!

You can’t perform that action at this time.