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.

