                     __ 
                    /  \                              New-Sysop 
                   /|oo \                             Orientation
   * FidoNet *    (_|  /_)                            Information
      266          _`@/_ \    _ 
                  |     | \   \\ 
                  | (*) |  \   )) 
     ______       |__U__| /  \// 
    / Fido \       _//|| _\   / 
   (________)     (_/(_|(____/ (tm) 
 

The purpose of this little treatise is to provide introductory
information for persons who are interested in connecting an
existing system with FidoNet.  


Introduction to FidoNet 
------------ -- ------- 
 
The network is a loose coalition of many different bulletin board
systems. "FidoNet" and "Fido" are registered trademarks of Tom
Jennings. The network is by no means limited to the Fido software;
there are several "FidoNet compatible" systems which interface with
the network.  By joining, you as a sysop can take advantage of the
expertise of thousands of other users. 
 
A short history lesson will help in understanding FidoNet.  Tom
Jennings was in San Francisco, and John Madill was in Baltimore,
both working on the Fido BBS software.  In the spirit of finding
out if it could be done, they decided to add code to the system to
support a dialup connection with no human intervention during the
wee hours when the sysops were sleeping and the systems were free. 
This quickly became a useful function, since both systems and both 
sysops were busy and it was a convenient method of exchanging
information. 
 
From this chance beginning in May 1984, growth was phenomenal.  By
August 1984, there were 30 nodes; by September there were 50.  By
February 1985, there were 160 systems, and a group of sysops in St.
Louis had taken over the administration of the list of systems. In
June 1985 the network converted to the currently-used two-part
addressing scheme to support the growth.  As this is written in
late 1987, the size of the network has passed 2000 nodes and change
continues with a zone-based nodelist to facilitate communication
with systems overseas.  But we get ahead of the story . . . 


Network Organization
------- ------------ 
 
Today's network is organized into geographical divisions of zones,
regions, networks, individual systems, and points.  A zone is a
very large division; zone 1 is North America, zone 2 is Europe, and
zone 3 is Australia, New Zealand, etc.  Of more interest are
regions, networks, and points.  

North America is divided into regions.  For example, the central
region, region 11, includes Illinois, Indiana, Kentucky, Michigan,
Ohio, and Wisconsin. Regions are assigned 2-digit numbers to
differentiate them from networks. 
 
Regions are further broken down into networks.  A network usually
covers a rather small geographic area, such as a metropolitan area. 
Seattle is network 343. 
 
Individual systems are assigned a node number within the
appropriate network or directly within the region if no network
covers that specific location. A point is a usually a one-person
BBS. 
 
There is an analogy with telephone numbers.  Think of the zone as
the country code, the network as the area code, the node number as
the telephone number, and the point as an extension for the
individual.  This is written as zone:network/node.point.  For
example, Seattle is covered by network 343, and is in zone 1.  The
specific BBS which has been assigned node 100 in the Chicago 
network would be 1:343/100.  If there were point systems served by
this BBS, they would be 1:343/100.1, 1:343/100.2, and so on. 
 
The purposes of this organization are twofold.  First,
decentralization means that no one person has the task of
administering the entire network.  Since it is a volunteer and
amateur operation and such an assignment would be a big job, 
it became obvious early in the life of FidoNet that
decentralization was necessary to support growth of the network.

The second reason for such a hierarchy is to improve the flow of
mail.  One system in each network takes on the responsibility of
Network Coordinator, and that BBS becomes node zero in the network. 
One of the tasks of the Network Coordinator is to forward incoming
mail.  Thus, if I have ten messages for different systems in the
Seattle network, I need to make not ten telephone 
calls but only one -- to system 343/0, which is the NC for Seattle. 
The mailer software automatically routes messages for nodes in
network 343 to 115/0, saving me money and making the network work
better. 

 
The Nodelist and FidoNews
--- -------- --- -------- 
 
All of this is held together by two documents, each published
weekly.  One of these is a list of every system in the network,
with network/node address, telephone number, and other useful
information; this is called the NODELIST. 

The other document is a newsletter, FidoNews.  Both the nodelist
changes and FidoNews are distributed using the network; once your
system is up and running you will have a source for the most
current information. 

 
What's in it for Me? 
------ -- -- --- -- 
 
This is all well and good, but other than the thrill of being a
part of all this exciting technology, what good is FidoNet to the
average sysop?  Through the magic of echomail, your system can have
thousands of callers a day, posting messages, asking questions, and
receiving answers.  This use of the network has eclipsed the
original sysop-to-sysop communication, although this is still a 
strong motivation, especially when used to exchange data and/or
programs.  More about echomail later. 

 
What Must I Do? 
---- ---- - -- 
 
There are really only two rules to follow to be a part of the
network.  The first is that your BBS system must be "FidoNet
compatible" and able to receive network messages during one hour
each day (1:00am to 2:00am PST).  The second is that you must not
unduly annoy other members of the network, or yourself be unduly
annoyed.  Like a large family, the members of the network must all
learn to live together, if not in perfect harmony, at least working
together. 
 
A formal policy document exists which states in more detail the
expectations of systems as members of the network. Look for 
POLICY4.ARC located on the Seattle Software Exchange 343/8 file
area 13. 

 
The Nodelist 
--- -------- 
 
Perhaps the single most-important file on your system is the
nodelist.  From it, your system obtains the information necessary
to communicate with other systems, be they across the street or in
another country. 
 

The most basic format of nodelist is described by the FidoNet
Technical Standards Committee (FTSC) and is generally called the
"St. Louis format" nodelist.  If you find a file named
NODELIST.nnn, where nnn is a number, that is an FTSC nodelist.  The
number is the date associated with the nodelist; for example,
NODELIST.275 was issued on day 275.  Nodelists are often ARC'ed; 
NODELIST.A75 is the ARC'ed version of NODELIST.275.  (No, Virginia,
all ARC files don't end with .ARC.)  FTSC nodelists along with a
file called NODEDIFF.nnn (which no longer come from St. Louis) are
issued each Friday. 
 
The FTSC nodelist contains information on every BBS in the network. 
Luckily, it is rare that you will need to transmit or receive an
entire nodelist. CHANGES are distributed each week in a file named
NODEDIFF.nnn.  For example, let's say that you are running with
NODELIST.267.  When the next nodelist is ready, you will obtain a
file named NODEDIFF.275.  When you run the XLAXNODE program (see
below) it will automatically apply the changes in the nodediff 
file, and as if by magic you will have NODELIST.275 on your system.

Virtually all systems process this file into other forms before it
is actually used by the BBS software.  For further information on
how this is applied please consult your software documentation.
 
 
Routing of Echomail 
------- -- -------- 
 
It is not unusual for a moderately-sized echomail hub to handle
dozens of conferences and thousands of messages a day.  This volume
would quickly swamp the structure which was set up to handle
person-to-person communication in which mail flows into a network
through the network coordinator.  For this reason, separate
structures have been established to expedite the movement of 
echomail conferences.  Echomail coordinators have the
responsibility to administer this activity. 

There are entire systems dedicated to the movement of echomail. 
These "echomail backbones" serve as repositories for large numbers
of conferences and links to the next level down on the hierarchy. 
 
The actual topology of echomail is unimportant.  The point is
simple -- do not route echomail through normal channels!  Send a
few hundred echomail messages to some network coordinator and find
out the real meaning of "annoying behavior". 
 
To get started in echomail, first get a working BBS.  Get into the
network, and get settled.  Then talk with your network coordinator,
or perhaps by then you will have found out who the echomail
coordinator is.   You should start by receiving a small number of
conferences from the HUB that you will be assigned too. you will
also route your traffic (that is, messages your users enter) back
to that node. As your knowledge and confidence grows, you can ask
for more conferences. 


Echomail Etiquette 
-------- --------- 
 
There are a few simple things you can do to make echomail more
pleasant for everyone.  These are common-sense issues but they may
not be immediately obvious when you are just getting started with
echomail. 
 
Do not send person-to-person messages using echomail.  If you have
a message for Joe Klutz, and no one else is interested in it, then
use standard netmail. Even if you mark the message private, every
sysop in the conference will pay to receive it!  A message between
two sysops across town in New York, received on a BBS in
California, isn't likely to win any friends. 
 
Every conference has a subject; don't get too far off of it.  Most
conferences have a moderator who will step in and shout if the
topic strays too much. Unless you have been involved in a
conference and have a good grasp of its scope, be cautious about
starting a new topic. 
 
When you reply to a message in echomail, mention enough of the
previous message so that readers can tell what you are replying to. 
It is maddening to see someone discussing the merits of a previous
message when you can't figure out what the previous message is
about.  Remember, reply chains in echomail are imperfect at best
and some echomail processors don't even attempt to reconstruct
reply chains. 
 
Also, remember the delay inherent in echomail.  If you post a
question, don't expect a response tomorrow.  If you reply to a
question, realize that many others may be replying at the same
time, a flood which will pour in over the next several days. 


Who Pays For All This
---------------------

Who pays for all this. I do, you do and other members in the net
help defray the phone and hardware costs to bring this all to you
and me. Please contact the local echo coordinator for the latest
information on this cost.


Flames 
------ 
 
The term "flame" is used within FidoNet to describe a "hot" message
which disagrees violently with some issue.  Unfortunately, flames
often are attacks on persons, not ideas.  This can be very
annoying, using the term in its "technical" context from FidoNet
policy. 
 

There is no excuse within FidoNet for personal attacks by one
individual upon another individual, yet it happens all the time. 
When you compose message, remember that the electronic media does
not convey facial expressions or voice tones.  This can make it
very difficult to convey the real meaning of what you are trying
to say. 
 
Flames are contagious.  If you see an attack on something you
believe in, or on someone you like, it is human nature to want to
answer the challenge.  Instead, think about whether you really
should reply.  If you violently disagree with what you just read,
a reply may not be the best idea. . . at least not until you have
had time to calm down.  It is bad form (although altogether too 
common) to spend more time in the reply discussing personalities
than the real issues.  Calm reasoning will win over more support
than calling your opponent names. Remember, it's not the COMPUTER
you are jousting with; there is a real human being out there, with
feelings.  Sure, the modem does a great job of insulating you, but
don't say anything in an electronic message which you would not say
face-to-face. 
 
On the other hand, if someone attacks YOUR ideas, don't take it
personally. Humor is often the best response to a flame.  Remember,
everyone has a right to their opinion, and the lack of verbal
queues in echomail makes disagreement sound like attack.  It is not
necessary to respond to each and every message which states an
opinion different from your own.  There are times when ignoring a
message is the right thing to do, even though it is much more
difficult than replying to it. 
