~/.gale/public-keys and
~/.gale/private-keys directories
used for anything?
See http://gale.org.
In short, Gale is a messaging system, designed to
resemble Zephyr in user interface and social
characteristics but IRC in architecture, with some
features of its own. It works across the Internet and
supports the use of public-key cryptography for privacy
and authentication.
Good question. Gale is still in beta, and Dan Egnor is still doing active development. If you're interested in (on the technical side) the development of a clean, robust, scalable messaging system or (on the social side) the construction of a wide-scale messaging system that covers a diverse set of schools and workplaces but still has the "flavor" of Zephyr, and you don't mind dealing with software that's in a state of incomplete development flux, then you might be interested in Gale. Otherwise, don't worry about it. Go back to whatever you were doing.
Gale draws from the successes and failures of several messaging systems. It has a spanning-tree topology with failover, little server state, no concept of "op privileges", security through end-to-end encryption, multi-line messages, and command-line-driven clients.
Gale, as deployed, will probably have a much lower client-to-server ratio. The servers are easy to set up, and this means that public messages cause less bandwidth, since they can be sent singly to local servers and then rebroadcast to all interested users in a given subnetwork. Each server should only have to handle a relatively small number of clients, but the Gale system as a whole should function just as well.
A recent feature, introduced in gale 0.9, is known as directed categories. Directed categories are a mechanism that can prevent unnecessary distribution of messages from server to server, thus improving gale's scalability.
Dan Egnor described it as follows in a series of puffs
(gale messages) on August 3, 1999:
The proposal for directed categories, as I've described it before, has each
client connecting to a server (as they do today), requesting subscriptions for
and sending messages to various categories (as they do today), some of them
directed (i.e. beginning with '@domain.name/...').
Servers would then make connections on behalf of their clients to other
servers. For example, if someone at OFB posted to
'@ugcs.caltech.edu/something', then the OFB galed would make a connection to
the UGCS galed to send the message. It would keep the connection open in case
another OFB user wanted to send a message to UGCS; it would use the same
connection if anyone on OFB wanted to subscribe to '@ugcs.caltech.edu/...'.
(The connection would time out after a while, if nobody used it or had
subscriptions on it.)
Thus, the global network would form a two-level 'star topology': multiple
servers connecting to each single 'master server' for a discussion forum, and
multiple clients connecting to each single server. Contrast this set of
overlapping stars with the 'single spanning tree' model we currently use.
Since I've started thinking about this recently again, I'd like to add an
extension: each 'domain' should (optionally) have multiple servers associated
with it, for redundancy, scalability, and geographic distribution. Within the
domain, these servers would use a self-organizing spanning tree; externally,
remote servers would connect to the first one that responded.
More specifically, given a category '@foo.bar.bat/...', servers would look up
all of 'foo.bar.bat.gale.org', 'gale.foo.bar.bat', and 'foo.bar.bat' itself in
DNS. Each such name could have multiple A records and/or an SRV record with
multiple associated addresses. In total, this will offer a collection of IPs
to try.
If the server doing the lookup notices that one of those IPs belongs to itself,
then it belongs to the 'domain' in question (see below). Otherwise, it simply
attempts a connection to all of the IPs in parallel, using the first one to
succeed (closing the others).
If the server actually belongs to the domain, it will attempt a connection to
all of the IPs _numerically less_ than its own.
In either case, it will then do the standard directed-category thing of sending
messages and/or subscribing to messages on its clients' behalf. Note that
servers don't distinguish between remote servers and local clients; note also
that servers can participate in any number of 'domains' simultaneously, and
indeed don't need to know about them ahead of time (they discover their
membership when they find out that the domain's IP addresses includes their
own).
This effectively results in spanning trees (of arbitrary size) with
point-to-point connections between them. It depends on DNS and IP for location
and routing; I'd rather not try to solve those problems on my own. Think
"mailing lists" or "Web servers" instead of IRC or USENET. The former has the
problem that any one popular forum puts a large drain on its host servers,
which much scale to meet the load, beg for mirrors, or fold; the latter has the
problem that as the network itself grows large, the load on each server gets
bigger, until the whole thing threatens to collapse. (IRC doesn't broadcast
everything everywhere as USENET does, but it still must propagate and manage
channel metadata throughout the tree.)
On the bright side, adding 'mirrors' takes very little effort; the owner of the
domain just lists another IP (or a reference to another hostname).
As Aaron says, that means that people can associate any number of 'domain
names' with your server without your permission; however, this does nothing but
just that -- associate a name. You could already flood the server with
traffic, or host all your conversations on it, if you wanted. This does open
the door to 'server hijacking' where people host their high-bandwidth forums on
others' convenient servers. I don't know quite how to get around that without
server-based "ownership" of forums (which I'd like to avoid); I also note that
people will tend to load-balance themselves.
The gale protocol is open, if not well-documented. There are a few distinct clients that implement that protocol.
The original client suite is a set of command line utilities that can be compiled for most modern versions of UNIX. Backbone systems using these clients run Irix, HP/UX, Solaris, Linux, and NetBSD. The source code for the clients includes source for a library, libgale, which can be used to write your own clients. The most important user commands are gsub and gsend; the rest are only occassionally useful, or are primarily useful to domain managers.
To get bleeding-edge source code, you can use cvs:
cvs -d:pserver:cvs@ofb.net:/ofb/cvs login
cvs -d:pserver:cvs@ofb.net:/ofb/cvs co gale
The password is blank.
| gsub | The client that receives messages and prints them in your terminal window. Allows you to call an external script for custom formatting of messages. |
| gsend | The client for sending messages. Allows you send encrypted or public text messages, with or without a cryptographic signature. |
| gwatch | Monitors logins and logouts (people starting and stopping their listening clients, for example gsub). |
| gzgw | A gale-to-zephyr gateway. Zephyr is a similar system, but more hacked together and less scalable, or so we like to believe. If you use zephyr, you may also find John Prevost's Gale for Zephyr users page handy. |
| gkeys | A now obsolete client to generate keys. Use gkgen instead. |
| gkgen | Generates a gale public/private key pair. Attempts to sign the public key (private keys need not be, and should not be, signed) using gksign. |
| gksign | Attempts to sign a public key, making it's identity cryptographically verificable. This will be done for you automatically the first time you run a gale client. |
| gkinfo | Gives you info on the key whose name you pass on the command line. Displays number of bits in the key and, for public keys, displays the signing chain. Will display info on both public and private keys, if it can find both. Useful for debugging authorization problems. |
| galed | The gale server. Your other clients must point at a valid gale server, but you don't need to run one of your own unless you think that your domain will be generating a lot of traffic, or if you need to operate independently of the main gale network. The servers are connected to each other by links to form a spanning tree of the gale network, and are responsible for passing all messages of any kind from any client to any other. At the moment, they have nothing to do with cryptography or gale domain names, although large domains do tend to run their own servers. |
| gdomain | The domain's key server. Responsible for
providing public keys (sent via gale puffs) to
clients that don't have access to them.
Should be run by the gale user on a machine
with access to the cache of generated local
keys (~gale/etc/gale/auth/local
is a common location for this cache). |
Fugu is a Python/Tk integrated client by Tessa Lau. Previous versions were based on a Python interface to the libgale created with SWIG, but later versions are based on PyGale, a reimplementation of the client side of the gale protocols in pure Python except for the cryptography functions, which are provided by RSAREF.
Jack Frechet's Java client, written from scratch. Unfortunately, it has no cryptography (no private messages and no authentication). Or maybe it does. I just can't tell. And, in any case, there are no longer any extant links to this code.
Wesley Tanaka's Praya supports various protocols in addition to gale, and uses Jack's Java client for its gale support, with encryption and signing added on top.
Seth LaForge has a set of O'Caml bindings that he used to write a statbot, if you're into lunatic fringe languages. No web link available at this time.
Alan McConchie tells me that it's obvious that I should mention that, if you want to read gale from a web interface and post as if you were webgale.whuang@ugcs.caltech.edu, then you should use his web client.
gwatch has two main functions: to find out who's listening to a given category prefix, and to watch login and logout activity.
To find out who's listening to a prefix, you use the
-p switch, like so:
gwatch -p pub:/ping
The argument to -p is the category to
probe. Make sure you add :/ping to the end
of the category. (Recent versions of gwatch will add
the :/ping automatically.) This feature
works by posting a message of a special type, called a
"ping." When a gsub sees a message of this type, it
responds by sending back a "receipt" to the sender.
Adding :/ping causes the ping to be
crossposted to the category /ping, which,
by convention, indicates that gsub shouldn't print out
the message. Thus, a ping will elicit responses from
all listening gsubs, but will not be displayed, so as
not to annoy people.
To watch login and logout activity, you can use the
-i and -d switches. For
example,
gwatch -d ofb.net -i notjtr@ziskamonic.nu
will run gwatch in the background. Any time anyone
whose key ends in @ofb.net logs in or out,
a notice will be printed, and any time
notjtr@ziskamonic.nu logs in or out, a notice
will be printed. In this context, logging in means
starting a gsub, and logging out means stopping a gsub.
If you start gsub in your .login or .zlogin file, this
will be equivalent to the standard definition of logging
in and out.
If you don't want people to know that you are listening
to a category, or you don't want people to know when you
log in or out, you can use the -a switch to
gsub, which suppresses notices and receipts.
The spylist file (which lives in ~/.gale/spylist, by default) contains instructions for gwatch. Most switches to gwatch have a corresponding keyword that you can put into your spylist file to get the same effect.
| gwatch switch | spylist command | what it does |
|---|---|---|
-p cat |
ping cat |
sends a ping to a category to let you know who is subscribed to it |
-i name |
id name |
watch login and logout notices from user whose gale id is "name" (note: name must be a fully qualified gale id, including domain) |
-d dom.ain |
domain dom.ain |
watch all login and logout activity at domain dom.ain |
| cat | category cat |
watch for receipt or notice activity on the specified category |
Note: this information, though still correct, is out of date and will be changed in the near future.
Imagine you have two different gale accounts,
attila@ofb.net and
ahun@ugcs.caltech.edu. You want to be
able to read private messages for
attila@ofb.net even when you're logged into
UGCS.
You need to do two things: copy over the private key (from ofb.net to ugcs.caltech.edu, in this case), and subscribe to the user category for the foreign gale key.
~/.gale/auth/privatescp
ofb.net:.gale/auth/private/attila@ofb.net
chaste.ugcs.caltech.edu:.gale/auth/privateA@B, the
private category is @B/user/A/ (don't
forget the trailing slash), so in our example it would
be @ofb.net/user/attila/, and, hence, you
would add a line like this:
GALE_GSUB @ofb.net/user/attila/~/.gale/conf file (which you can
create if it doesn't exist already). If there's
already a GALE_GSUB line, add a ":" and the new
category to the end of the existing line, like so:
GALE_GSUB existing/categories:@ofb.net/user/attila/Now, just start a new gsub at UGCS, and you're set. You may want to do the same thing, in reverse, in case you're ever running a gsub at ofb.net. These machines and account names are, of course, examples.
You may also want to set the variable
GALE_ID on both systems to one of these
gale ids. After you have done this, you will send and
receive messages under that id instead of the normal id
for that account. In this example, young Attila would
set GALE_ID to attila@ofb.net
on ugcs in a shell dotfile or in .gale/conf. It could
also be done on ofb.net, but that's less essential,
since clients started on ofb.net would use the ofb id by
default.
A gsubrc file lets you customize the display of messages received by gsub. The gsubrc is invoked for every message that gsub is configured to receive (i.e. any message you're subscribed to); the message body will be piped in on standard input, and information about the puff will be available in environment variables.
By default, gsub will look for a gsubrc in
~/.gale/gsubrc, but you can invoke gsub with the
-f switch to specify a different filename.
Here is a simple gsubrc:
#!/bin/sh gsub -r |
gsub -r invokes the default formatter, aka
"default gsubrc." Here is a slightly more complex
example:
#!/bin/sh
for f in kaihsu ryan joew jwasson
do
case "$GALE_SENDER" in
$f@*)
if [ -f $HOME/.in-bad-mood ]; then
echo "* [dumbass ($GALE_SENDER): suppressing]"
exit
fi
;;
esac
done
gsub -r
[ -n "$GALE_TEXT_ID_CLASS" -o -n "$GALE_TEXT_ID_INSTANCE" ] && \
echo - $GALE_TEXT_ID_CLASS $GALE_TEXT_ID_INSTANCE
|
A list of information about a puff that may be available in a gsubrc follows. Some of this information, such as the recipient, may be multivalued (in this case, because the message was crossposted); in the case of multivalue information, multiple variables are set. For example, GALE_TO is used for the first recipient of the message, GALE_TO_2 for the second, up through GALE_TO_n for the nth recipient.
Many of the variables are named for their fragments (see here for more information); data from the first fragment named a/b/c of type t (where t is TEXT or TIME) will be available in the variable GALE_T_A_B_C. If there are multiple fragments of the same name, additional values can be found in GALE_T_A_B_C_2, GALE_T_A_B_C_3, and so on.
| variable | significance |
|---|---|
GALE_FROM |
gale id of sender (if this is set, it means that the signature verified) |
GALE_TO |
first recipient of the puff (there will be multiple if the message was crossposted) |
GALE_TEXT_MESSAGE_KEYWORD |
first condiment (e.g. url, noise,
q).
From message/keyword fragment. |
GALE_TIME_ID_TIME |
time message was sent, in a text format.
From id/time fragment. |
GALE_TEXT_ID_CLASS |
name and version of client that sent message, in
the format client name/version number From id/class fragment. |
GALE_TEXT_ID_INSTANCE |
information about the client used to send message,
in the format gale domain/machine name/user name/tty/PID of client From id/instance fragment. |
http://www.ugcs.caltech.edu./~jtr/gale/contrib/gsubrcs
Some of these are old and rely on variables that no longer exist or have changed names; the information in the table above is current as of versions 0.99cheese, 0.99danger, and 0.99egg.
~/.gale/public-keys and
~/.gale/private-keys directories
used for anything?Not anymore. They were used in ancient versions of the gale software. If they still exist, they probably contain keys that are totally incompatible with the current architecture. Delete them.
Puff a url of your photo to pub.gale.verisimilitude, and John Reese will see it and eventually create your thumbnail. He'll take care of cropping and resizing the image too. Please do not crop it yourself, cuz you'll do it wrong.
John Reese reserves the right to reject any image that he feels does not accurately represent your face. This may include but is not limited to images in which:
These will work in the Z Shell, which any civilized command line user should be using.
compctl -g '~egnor/etc/gale/auth/cache/*(:t)'
-x 'C[-1,-[cC]] n[-1,:],C[-1,-[cC]]' -k compcats --
gsendcompcats to a set of
useful categories first.
~egnor/etc/gale/ is the path of the
gale etc directory on the machines that make up the
(distinct) ugcs.caltech.edu and ofb.net gale
domains. Ask your local gale master where it is on
yours. Typical locations might be
/usr/local/etc/gale or
/var/opt/gale.
lgp() { less +G ~jtr/gale/by-prefix/"$1" }
lgc() { less +G ~jtr/gale/by-category/"$1" }
lgs() { less +G ~jtr/gale/by-sender/"$1" }
lgk() { less +G ~jtr/gale/by-keyword/"$1" }
lgd() { [ -z "$1" ] && set `date +%Y-%m-%d`;
less +G ~jtr/gale/by-date/"$1" }
compctl -g '~jtr/gale/by-sender/*(:t)' - lgs
compctl -g '~jtr/gale/by-prefix/*(:t)' - lgp
compctl -g '~jtr/gale/by-category/*(:t)' - lgc
compctl -g '~jtr/gale/by-date/*(:t)' - lgd
Quick links:
Once upon a time, the official logger at gale.org logged all puffs, public and private, although the private puffs were not accessible (by anyone... they were stored encrypted). It accepted a set of criteria (range of dates, categories), and returns matching puffs. But now, alas, it is dead.
Aaron Bannert has created database-backed logs which everyone should always use, all the time.
There is another logger on the web at UGCS which logs public posts. This logger is unsupported and spottily maintained, and the maintainer may well yell at you if you ask questions about it. If you have a lot of disk space, logs in this format are convenient to maintain on your local machine for quick searching, and redundancy would be good when UGCS goes down. The code for the logger, written in horrible, horrible perl, is here.
No respectable loggers will display any messages
crossposted to /nolog. Since many logs are
publically accessible to any Web user, you may wish to
use this with potentially questionable material.
Long, long ago, embedding the string JJ-232
had the same effect, but it is no longer nearly as
widely supported as /nolog.
Truly questionable material should probably be protected with encryption, or use different channels entirely. Other people may have logs of their own, and you can never know for sure who's listening to public messages.
Redirect a gsub to a file, like so:
% gsub -beak @dom.ain/user/username:-@dom.ain/user/username/receipt >>& ~/.glog &
Where you would, of course, replace dom.ain and username
with your domain and username. (Credit for this exact
command line goes to Andrew Chang.) The -b turns off
beeping for private messages (bell characters would be
annoying in a file); the -e tells it to listen only to
the category on the command line, which is your private
category, except for receipts; the -a makes it
"incognito," so the logger doesn't return receipts when
people send you private messages and lead them to
believe that you're just ignoring their messages; and
the -k prevents the log gsub from killing any existing
gsubs.
That's not a question. See the Entering Newbies' Guide About Gale Etiquette.
You can get a rough but updated list by issuing the
command
finger
gale@ugcs.caltech.edu.
Primarily current or former students at Caltech or Carnegie Mellon, though this will probably expand in the future. Geographically, we're spread around North America. If you want personal commentary on how much the weather sucks in some random locale, this is the service for you.
That's not a question.
presto@pfarner.nom).
egnor@ofb.net)
or Heath Hunnicutt (gsend heath@ofb.net).
peterh@sapros.com).
jlm@ugcs.caltech.edu), or Aaron
Denney (gsend wnoise@ugcs.caltech.edu).
There are programs which listen to gale categories and/or post data to them. They are called "bots," and one might consider them to also be residents of gale. One can find a current bot roll call by fingering gale@gale.org.
Those bots that accept user commands are supposed to listen to two categories: a public category in the "cmd" hierarchy (for example, cmd.puffbot) and a private category corresponding to the key they use to sign their puffs. Bots that accept user commands in this wise are required to give you a usage message if you puff the word "help" to them. Please, goddamn it, try this before you post a message asking how to use any given bot.
Those interested in writing bots should study the Bot Law currently recorded in the data returned when you finger gale@gale.org (the relevant portion, which may be out of date, follows:)
1. Bots MUST respond only to requests made in cmd.<bot-name> or to
"personal messages" addressed to the bot's ID.
1a. Bots MUST NOT ever respond to messages (cross)posted to bot.
1b. Bots SHOULD answer messages in cmd.<bot-name> containing only "help"
with an explanation of usage, sent as per rules in rule 2 below.
The explanation SHOULD include contact information for the bot maintainer.
2. Bots MUST crosspuff every public message they send to bot.<bot-name>.
Bots MUST NOT include other categories EXCEPT as per 2a, 2b, and 2c below;
Bots MUST NOT under any circumstances generate any output in cmd.
2a. If the sender crossposted a cmd puff to other categories, the bot MAY
post one message to those categories.
2b. Bots SHOULD respond privately to the signer of a cmd puff.
2c. Individual users may establish contracts with the bot to send them personal
messages. These bots MUST make "unsubscribe" information abundantly clear.
John Reese has a
bot framework
for python that handles a lot of the grunt work, such as
picking the category to which to reply and, if necessary,
simple parsing. The code for this framework is on ofb,
which is not reachable at the time of this writing, so,
alas, no link can be provided. The two typical methods of
writing a bot are to write a special gsubrc that may post
in respond to the puffs it receives, and resident programs
that use the libgale directly (or a clone, such as PyGale
or that incomplete thing Schachter wrote in perl).
Some strange, inbred mannerisms have developed on gale. Chief among these are (1) ridiculous abbreviations and (2) quotation marks in places you wouldn't expect. Although you should avoid using these yourself, a short explanation will help you understand the more grievous offenders.
There is a table of commonly used acronyms at http://www.gale.org/acronyms. The intended purpose of these acronyms is to save on typing, but every time someone uses one, two extra posts result ("What does ZXCOOWL mean?" and "[proud explanation of coinage]").
"The quote convention" indicates sarcasm by putting it in quotation marks (sometimes called "quote tongs" or "smack quotes"). Although many would argue that explicitly flagging sarcasm defeats the purpose, many gale denizens are too afraid of being misinterpreted to take any risks.
Uh, nothing. I put it in the previous answer as a joke, and then people started using it. It's caused no end of confusion. I think Wei-Hwa explained it best, after himself being confused: [this is a paraphrase]
it's a dummy acronym that doesn't actually have an expansion; therefore it is a suitable example to use as an acronym [when you want to make fun of abstruse acronyms]
To the horror of the gale community, John Reese has started to maintain a mug book of gale users at http://www.ugcs.caltech.edu/~jtr/gale/mug.
To submit a picture to the gale mug book, mail the URL to him or post it to the gale category pub.gale.verisimilitude@ofb.net.