Table of Contents


Castopulence is not currently actively developing software (since it's not really an organization yet; see the About Page). Development of projects occurs during developer free time, assuming they have the energy and motivation to do so. :D The projects listed here are some of the small projects that have been proposed or developed by Castopulence members in the recent past. If they're useful to you then great, but don't expect much just yet. ^_^


rot is a simple little console application that implements arbitrary rotation-based ciphers on textual streams. It supports rot13 and rot47, and is flexible enough to support many custom ciphers as well, based on the same rules of defining character ranges to rotate a given number of characters.

The code was originally written in Cygwin, a UNIX-like environment for Windows, though it should be mostly cross-platform. The current repository only has a rudimentary shell scriptMakefile to build it, however, so if your platform doesn't support the shell scriptMakefile (or it just doesn't work properly on your platform) then you may have to build it manually. If it's of any use to you then you probably already know how to do this. If not, contact us and motivate us to write a platform independent Makefile, release a binary build for your platform, or at least provide you with some guidance for building one yourself.

The project is hosted at GitHub. The source code can be retrieved from there:


Myt is intended to be a secure messaging platform that fights spam through encryption and server communication. Far from being complete (at the time of the writing there is basically just a stub application with proposed command line options), it is merely a proposal based on the frustration of being unable to hand out E-mail addresses at will. Myt would support both E-mail and instant messaging facilities to start. Extended functionality, like voice/video chat may follow, but that's looking a long way into the future.

Firstly, Myt would guarantee a secure connection (or at least each connection would be encrypted). This means that messages sent through Myt should be able to safely contain things like passwords or personal information (though just because it could doesn't mean it has to).

Secondly, Myt would hold hosts responsible for the messages they send. In particular, when a Myt server receives a message, it will contact the alleged sender to request confirmation that they actually sent the message on behalf of the specified user. If the server doesn't confirm sending it then the message is discarded before the user is even aware of it. This should help to prevent spoofing of the sender.

Thirdly, Myt would maintain a network of whitelisted and blacklisted servers and users, managed by a peered network of trusted servers, to help automatically block messages from known spammers across the entire network. If user A on server B flags a message from user C on server D then it would log the event by user, server, and message; and communicate the event to a centralized network. Given a certain threshold of reports, the message would become automatically flagged as spam and filtered appropriately. Similarly, given enough reported spam messages from a particular user or host, the respective user or host would find themselves flagged as spammers across the network and respectively blacklisted.

In addition to the server managed lists, users could also maintain their own lists. Either a blacklist, or perhaps more conveniently, a whitelist. What this means is that merely having an E-mail address would be insufficient for actually contacting a user. They would need to have explicitly allowed communication from you first. This would cut down on spam because it requires a mutual desire to communicate between nodes.

Consider, for example, the very regular occurrence of Web site registrations that require a valid E-mail address. You don't really want to provide that information because for all you know the Web site will share the information, often for money, with third parties that will then spam you. With a whitelist based model, they would have to explicitly tell you each and every address that they intend to contact you with. You can easily filter them because you know exactly what they are. At the very first sign of spam, you can also easily remove the address from the whitelist, essentially revoking their privileges to contact you.

Myt is mostly just an informal proposal right now. It's a work in progress. If you have ideas or concerns, feel free to contact us to let us know what you think.

The existing source code for Myt is hosted on GitHub:

[Cross-platform Software Package Manager]

This "project" is currently just in the idea stage. Essentially, the goal is to develop a package format based on open technologies (XML, tar, gzip or xz). Then create a package manager application for the major desktop platforms (Linux, Windows, and Mac OS X; others of course can follow).

The package would be installed by following a set of reversible instructions inside of a [valid] XML file. The uninstall process would be determined by reversing the installation instructions (and hopefully guaranteed to succeed).

If something doesn't work properly though, the package itself would be a simple compressed archive and plaintext XML. You could easily open it up and see what it's trying to do (or undo) and do it yourself.

For efficiency's sake, platforms that have disorganized file system structures (i.e., Windows) would use an organized hierarchy within the mess. For example, something like this:

  • C:\Program Files\PROJECTROOT\
    • bin (for executables, single path added to PATH)
    • include (for C/C++ header files)
    • lib (for static and/or shared libraries)

The XML file that describes the installation process would use built in 'commands' that are considered safe and automatically reversible (this may require version control to manage previous states). Using standard packages would allow users to have confidence in the package. They can easily open it up and see what it does and trust that it can only do safe things. This concept will probably break with source packages though. Even then, however, the hope is that the XML can describe the build process in a safe and platform-independent way (without referring to any specific system commands) so that the process is somewhat controlled.

Unsafe packages would be supported that are free to do whatever they want, but the package manager would require explicit options from the user to allow them. They'd otherwise fail with an ugly error message.

As you can see, it's a very informal mess of ideas right now. :P