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.