This FAQ has been owned by various people, from a mysterious man or woman named something like Bridget Spitznagel, to Dan Egnor, to John Reese, which is me typing this. But because of the nature of the Wiki, questions and answers will have been touched by many people.
Or, to put it another way, it's your fault.
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.
Gale is still in beta, though active development has ceased. 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 an incomplete development state, then you might be interested in Gale.
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.
You know, nobody actually asks this question. They actually ask "why is it so hard to start using gale?" But it's traditional to have this question in here.
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.
An old message from Dan Egnor explains in more detail. The message was written on August 3, 1999 but is more or less still correct:
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.
see a list on GaleWiki
His obese cat ate his brain.
gwatch is obsolete. Its functionality has been rolled into gsub and gsend.
It allowed you to keep track of user logins or logouts; to do this now, subscribe to
_gale.notice.username@dom.ainfor just username@dom.ain, or
_gale.notice@dom.ainfor all users in the dom.ain.
simply subscribe to as many private categories as you wish and make sure the appropriate private keys are available. these can be copied between systems and reside in .gale/auth/private with extensions like .gpri
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 gsub formatter on the message. Here is a slightly more complex example:
![[Home]](/usemod-wiki/debian-logo.png){kind=logo}
#!/bin/sh
for f in kaihsu ryan joew jwasson jlw ghostc
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
This is a killfile; messages from certain users are suppressed, predicated on a marker file in your home directory so that you can turn this behavior on and off. In addition, extra information that isn't displayed by the default formatter is output, if it's available; GALE_TEXT_ID_CLASS and GALE_TEXT_ID_INSTANCE contain information about the client used by the sender, including version number and optional information about the machine they're logged in to.
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 contains the gale id of the first recipient of the message, GALE_TO_2 contains 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.
Here's one way to do it. You install [wmctrl] and then run a gsub in an xterm with this gsubrc:
#!/bin/sh
gsub -r
if [ -n "$WINDOWID" ]; then
if xwininfo -id $WINDOWID | grep -q 'Map State: IsUnMapped'; then
wmctrl -iR $WINDOWID
fi
fi
Caveats:
Make a bunch of broken symlinks in .gale/aliases, like this:
~% ls -l .gale/aliases/ total 0 lrwxrwxrwx 1 zaphod zaphod 13 Nov 15 2001 local -> local@ofb.net lrwxrwxrwx 1 zaphod zaphod 11 Aug 21 2001 pub -> pub@ofb.net
Puff a url of your photo to pub.gale.verisimilitude@ofb.net, 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. They also only work on ofb.net, because that's where John Reese's logs are.
Shell functions:
lgp() { less -rn +G ~jtr/glog/by-prefix/"$1" }
lgc() { less -rn +G ~jtr/glog/by-category/"$1" }
lgs() { less -rn +G ~jtr/glog/by-sender/"$1" }
lgk() { less -rn +G ~jtr/glog/by-keyword/"$1" }
lgd() { [ -z "$1" ] && set `date +%Y-%m-%d`;
less -rn +G ~jtr/glog/by-date/"$1" }
Shell completion for above functions:
compctl -g '~jtr/glog/by-sender/*(:t)' - lgs compctl -g '~jtr/glog/by-date/*(:t)' - lgd
The by-category and by-prefix directories are gigantical and completion on them is not encouraged.
Look along the navigation bar here. Asking "are there logs?" is grounds for key revocation because it means you haven't read the FAQ or looked at the Gale homepage.
This is a frequently asked question, but it shouldn't be. Just try them and use your own judgment.
No respectable loggers will display any messages with the keyword "nolog". Since many logs are publically accessible to any Web user, you may wish to use this if you are mocking your employer. Long, long ago, embedding the string JJ-232 had the same effect, but it is no longer nearly as widely supported as /nolog.
Bear in mind that nolog is not a real guarantee that your information will stay private. Anyone could log messages and post them wherever they want, in violation of community standards. So think.
Note that like many questions, I'm answering this in a UNIXy context. Fugu supports some sort of message logging, which I will not go into here.
gsub -eak username@dom.ain > ~/.glog
Where you would, of course, replace dom.ain and username with your domain and username. The -e tells it to listen only to the category on the command line, which is your private category; 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.
Anyone can subscribe to pub@ofb.net, so there are no effective means to control distribution of messages you send there. So you should be cautions when posting sensitive information. That said, the social convention is that messages puffed to pub@ofb.net are intended for the participants of the forum, and should not be forwaded to others without the puffer's permission. Forwarding of particularly inappropriate material may result in enraged galies hunting you down like a dog.
Loggers are also forbidden (not that we can enforce this except by shouting) from letting search engines index public gale logs.
Good question. See the Entering Newbies' Guide About Gale Etiquette.
see GaleLocations
Lots of former Caltech students, or people who know former Caltech students, or former UCI students, or former CMU students, or wacky space hackers who found gale by referral or web search. Geographically we have a strong presence on the American East and West coasts and the United Kingdom.
You bet! On the wire, the messages are encoded as UCS-2. Or maybe UTF-16.
Anyway, to get gsend and gsub to properly interpret non-ASCII text, you'll need to tell them what encoding to use for reading in and sending out. You can do this by setting the gale variable GALE_CHARSET (either in the environment, or one of the conf files) to an appropriate. You'll probably want either "LATIN1" or "UTF-8", but other encodings may be possible. Check the documentation for iconv on your system. (iconv -l lists available character sets.)
You'll also have to have "iconv" support compiled in to your gale binaries. This will either be provided by libc, or by "libiconv". Check the configure settings and log of the run. There's an outside chance you'll need to upgrade libiconv/libc -- the interface changed slightly. If your system provides iconv support in libc rather than libiconv, you'll need to edit configure to not add -liconv to the flags (line 7750), or possibly regenerate configure via autoconf, etc.