Tom Jennings
30 Apr 84
Fido #1: (415)-864-1418

	Some preliminary ideas for the FidoNet. (If you
haven't heard, FidoNet is an intersystem message forwarding
system mostly for Fidos, but could be used for others as
well.)

	Please, don't worry about all the seeming complexity
here. Most will go away. I have just typed everything I
could think of all at once, and not all is applicable.
(Besides, you're (probably) not gonna code it.)

	There are some points that need ideas: mainly, how
to pay for it, how it will appear to callers trying to send
mail, and any mysterious operational type problems you see.
Like most of Fido, I imagine this too will be built with 90%
suggestions.

	If you have any ideas on this proposed system,
please leave me a note on Fido #1 at the above number.
Thanks.

		O P E R A T I O N


	From a callers point of view, the system will have
one additional feature when entering a message. One way or
another the caller tells Fido which system the message is to
be sent to. This could consist of a prompt (System A, B,
...) or some such thing. (Any ideas?)

	In any case, mail will only work from a MAIL
subdirectory. Messages left here will be like all other
messages; readable or not, depending on the privacy, etc.
Replies can be left, etc, which get mailed in the same way.

	It may be desirable to search this area for each
user after signon, the same way message searching works now.
If old messages don't pile up like in other areas, this
should be nice and fast.

	There will not be any automatic confirmation of
received messages. It will be up to the user to do so, by
mailing a message stating that is was received. Maybe it
will be possible to confirm, by reading the RECV'D flag from
the message, but that won't go into the first one.

	In the MAIL area, the usual message search
("Messages to you" etc) should be adequate, if mail traffic
is less than or the same as the current message traffic.

	I M P L E M E N T A T I O N

	The only change to Fido will be a new command line
parameter:

	<number>/Y
	<number>/W

	/Y Is the hour of the day to start doing mail as
opposed to normal BBS stuff. /W is the window width, in
minutes, to do mail in. For example, 0200/Y 90/W says do
mail from 2:00AM, for up to 90 minutes, i.e. until 3:30AM.
During this time, Fido will not accept any normal callers.
Also, outside these times, Fido will not accept mail. If no
switch is present, or the window is set too small (TBD) then
it will not send or receive mail, like it does now.

	Neither will it bump someone off if they happen to
call just before the appointed time. However, as soon as
they logoff, it will start handling mail if it's supposed
to.

	The mailer (the program that actually sends and
receives mail) is a seperate program. It is run from the
batch file (RUNBBS.BAT) right after Fido.EXE. This works
like Control-C and errors do; via ERRORLEVEL. For instance,
the batch file might look like:

	    FIDO  ... 0200/Y 90/W
	    IF ERRORLEVEL 4 GOTO MAIL
	    IF ERRORLEVEL 1 GOTO END
	    RUNBBS
	MAIL:
	    MAILER 0200/Y 90/W
	    RUNBBS
	END:

	Like current Fidos, ERRORLEVEL is 0 if normal
termination (caller hung up, etc) 1 if Control-C or stack
overflow, 2 if disk file error (disk full, missing files,
etc) or 4, the new level for: "Time to do Mail".

	If it's time to do mail, Fido exits with ERRORLEVEL
4. If 4 or higher, it runs MAILER, which then runs
RUNBBS.BAT which starts it all over again. Otherwise, if 1
(or higher) it is an error, it goes to the end and stops.

	When run, the mailer sits and waits for phone calls,
or if instructed to do so, (command line switches or a
command file, whatever) makes calls. If a human type caller
calls, they will get a message to the effect "Waiting for
mail, please call back after <xxx>", where <xxx> is the end
of the window to wait for mail, and hang up on them. (The /W
and /Y switches will be duplicated in the mailer, for
reasons I'll not bother with now.)

			C O S T

	First, it is very important that we figure out what
it would cost. This is the second most important part. The
cheaper it is, the more likely FidoNet can be made operable.
However, no matter how cheap it is, if an ingenous way of
paying for it doesn't exist, then it all falls flat.

	Right now, late night long distance (coast to coast)
toll charges are about $13.00 per hour. ATT is proposing, as
part of some other boring issue, lowering this to $10.00 per
hour. This is quite cheap; a lot of messages can be sent in
an hour.

	I hereby declare the mail size unit to be the Cubit:

	1 Cubit == 80 characters * (1200 / baud rate)

	A cubit of mail sent at 300 baud will cost 4 times
as much as one sent at 1200. When 4800 baud modems become
available, the price per cubit will drop.

	Unlike commercial mail systems that are out for
profit, FidoNet's mail unit, the Cubit, is small enough to
account for very small messages, but large enough not to be
too small to account for. There are 12.8 cubits in a K byte. 

	An error checking transfer protocol is needed;
XMODEM will not be used, as transfer times routinely double
with long phone lines. (Dont want to pay for that.) More on
that later.

	As an example, say we want to send a small (five
lines, 64 characters per line) message from Los Angeles to
New York. Each message has a header (to, from, date, etc)
that consumes about 80 characters. Assume also that the
transfer rate is 1200 baud, and also that the transmission
method has a 10% overhead. 

Msg size:	      4.	Cubits
Message Overhead:     1.	Cubit
Message Size:	      5.	Cubits
Message Size:	    400.	Characters

Cost Per Hour:	     13.00	Dollars
Chars/Second:	    120.0	(10 bits/char)
Cubits/Second:	      1.3636..	(120sec / (cubit * 1.10))

Cubits/Hour:	  4,909.	(3600 sec * cubits/sec)
Cost/Cubit:	      0.2648	Cents ($13.00/cubits/hr)

Sample Msg Cost:      1.324	Cents

	Yes ... its cheap. Remember, this is pure cost, no
hardware maintenaince overhead, no payroll, no profit, etc.
Delivery time, nor even delivery, is garenteed. The above
does NOT include any connect/disconnect or disk access
overhead. However, it also does not count any savings from
text compression, which could save 10% to 40% maximum.
Probably more like 20% maximum in the real world.

	P A Y I N G    F O R    A L L    T H I S

	This is the most serious problem. The technical part
is easy! Also, BBS's in general are run more like little
fiefdoms than businesses, in the sense the are usually
operated privately, and almost never pay for themselves,
never mind make money! If FidoNet takes inordinate amounts
of effort on the part of the sysop, it'll probably fold up
due to that also.

	There are a couple of ways this can be paid for, but
none are really any good for typical free systems. (Note
that receiving (accepting) mail costs nothing. FidoNet might
be able to operate well with only a few well placed
"benefactors", and work acceptably well with only local
"paying" nodes, if mail is limited to say, an area code.)

	IF YOU HAVE ANY IDEAS AT ALL ON THIS SUBJECT PLEASE
LET ME KNOW!!!!!! THIS WILL MAKE OR BREAK THE FIDONET
IDEA!!!!

	In any case, some sort of accounting will have to be
done. Except for very rare cases, mail will have to be paid
for. The mailer will be able to account for each messages
cost, length of transmission, etc. There must be a method
for limiting mail sent by a specific user, and a "sysop"
type feature for relatively unlimited, or at least
differently limited, mail. The information associated with a
peice of mail will have to be worked out in detail later,
and while not too complex (any complexity can be put upon
the mailer) it must be adequate for future expansion.

	Presumably, not everyone will be allowed to forward
mail indescriminately. That would be awful nice, but
unfortunately not practical. There may be exceptions: for
instance, for a club-run system, you might want to let any
user send a fixed amount of mail over a fixed period of
time, say, a month. If it was a dues paying club, a number
could be worked out that would accomodate this. Anything
beyond that amount would have to be accounted for by some
other method.


IDEA #1

	Club-run systems. Basically, covered above.

IDEA #2

	Private, pay-ahead system. While this is very
workable, it means even more work for the sysop, and
probably some legal liability, like running a business,
unless the proper rigamarole wording is used, i.e.
"donations" not "charges".

	No one will be able to send mail unless they mail
some amount of money to the sysop. The amount donated is
kept in a list maintained by the mailer, who subtracts the
cost of the message from the balance. Usual warnings if not
enough, etc, and probably a warning when it reaches some
threshold.

		T H E    N E T W O R K


	Might as well be trendy and use some network
terminology here. Some of it's even handy.

	The topography of FidoNet is in keeping with
bulletin board philosophy; totally random and as little
organization as possible. Also, there is no control over the
location of the various message nodes (mail send/receive
systems).

	My first thought was to pass mail over as short a
distance as possible; however, this is a waste of time, as
late night long distance calls are charged on a per hour
basis, and in any case the more transfers the higher
likelyhood of messages getting lost.

	Message delivery time, if all is well, should be
overnight. If a system goes down, delays will be in
increments of 24 hours.

	There should also probably be a "broadcast" type
message, that stops at each node. Also, there really isn't
anything stopping binary files from being mailed; they are
not included here mainly because costs will skyrocket, but
it would be a nice way to do Fido updates, etc.


	So, my current idea (any other ideas at all
welcome!) is:

	Each sender has a list of systems it can forward to.
This can be used to limit forwarding to non-toll call areas
if desired. Also, this same list can be used to send mail
destined for one system, to be sent to a different system,
for further forwarding. This allows cheapskates to let
someone else make the toll calls. (If they in turn let it
go) Also, it lets a well funded system forward mail for
other systems.

	If there are messages destined for five different
systems, there will be five calls made (unless the
abovementioned forwarding is done). This "nodeless" system
is then relatively insensitive to down machines, etc, such
that only mail for the down system will not be sent. 

	If the net gets tied up (everyone calling everone
else, for instance, though I think thats unlikely!) then
some message forwarding can be done to lessen the traffic
load between busy systems.

