Heh, no cerification to post. Blarg. Check my sourceforge.net user page http://sourceforge.net/users/bluefoxicy

Right now I'm hoping to find someone who understands trackers (music software) to help me finish the Advanced Tracker pre-planning. Understand: IT WILL HAVE A SEQUENCER BACKEND! The entire playback engine is event-driven. The trick is to convert legacy modules to AT format. It also will be object oriented C++.

fcomp2 should be pretty nice for compression size. I have someone working on that currently--I think :) He's to look at the doc and do it from scratch on his own, except that I'll give him the fcomp code (which doesn't currently work) to look at to rip things like the fcomp_scan functions out of.

fdber is what, sleeping?

Sampletune is one I need for Advanced Tracker, to add extended sample contol (auto-tuning actually). It'll be cool; no more booting Windoze, opening AnalogX SampleTune, tuning a ton of ripped samples, and then loading modplug under Wine in Linux and fine-tuning. Load AT up right in Linux or Windows or on a Mac or whatever, load the converted SPC or the ripped audio, hit tune, fine tune. Bingo. No intermediate steps.

And wtf is daedalus? He's supposed to be working on CPD/UPD, which is a database for package managment on Linux/Unix designed to replace the RPM, DPKG, Ports/Ported/emerge, and whatever Slackware .tgz uses. It is intended to be integrated with all package managers; see http://cpdupd.sourceforge.net/cpm.html for an explaination.

I'll get back to ESIC one day... don't tell NT I said this but I'm really annoyed with him wanting to design it to look like C, i.e. with brackets and C-ish functions. I want to just extend BASIC to have pointers, classes, and to use the struct keyword. Also I want to header-ize it so that everything isn't all crammed together, and make it non-specific to the system.

E-MAIL ADVANCING

The next project I'm starting after all of this is a mailer message control plug-in structure and an e-mail client that uses it, to supply a simple and easy way to pass messages through spam-filter, compression, encryption, and so on. I'm thinking eventually all e-mail clients will support compression, spam filtering, and address-to-address cypher auto-negotiation.

The auto-negotiation requires a database of e-mails that auto-creates itself. First, when sending to an unknown host, you are allowed to tell it to try to get a message there querying supported features. The return message gives a response for each. E-mail query header:

negotiation-query: cipher, compress, gzip, bzip2 requested-cypher: 00-F9-CC-A7-B9-24-17-FF

The Requested-cypher is a number representing the cypher key that is to be used. It is 64 bit hex, as seen there. If there is known cypher between the two addresses, the sender will send one of these, and the client on the other side will reply with a cypher-request-response header.

The response has in its header:

negotiation-response: cipher, gzip, bzip2 cypher-request-response: accept 00-F9-CC-A7-B9-24-17-FF

In this example, compress (proprietary LZ0) is unsupported in the queried address. Once the response (or a "Mailer error" reply) comes back, the message is dealt with (i.e. compressed/cyphered and sent, or halted and the user is informed of the error in the "Mailer Error" issue). Note that the cypher-request-response is {accept/deny} [key-ID].

A cyphered message could need a sync up first, if there is no known cypher between the two clients. Header:

send-features: bzip2 negotiation-cypher-request: 3DES negotiation-cypher-supported: 3DES, blowfish

The response has the cypher key attatched to it, if it accepts.

send-features: bzip2 negotiation-cypher-response: 3DES, 00-F9-CC-A7-B9-24-17-FF

[Key is attatched]

After all these messages go back and forth, the mailer clients finally have a key matched to eachother. The negotiation-cypher-response has two parts: The algorithm, and the key's ID. Now to send messages back and forth:

send-features: bzip2 cipher send-cypher: 00-F9-CC-A7-B9-24-17-FF

Take note that the send-features are processed in order, left to right. In this example, the message data (not header) is bunzip2'd, then the key referenced by 00-F9-CC-A7-B9-24-17-FF (which is 3DES).

Now we've negotiated send-cypher and encryption, by sending like 4 messages back and forth. Now, both sides CACHE the response values. That means they both know eachothers' features. This process can be forced to occur later anyway, i.e. if you now add an fzip2 module for fcomp2 compression.