Considerations for FidoNet

As  mentioned,  one of the major drawbacks in the FidoNet project
is  the  way  by  which  it  would  be  paid  for.   One  of  the
possiblities  is  the  'Pay Ahead' method.  The amount to be paid
should most likely be a predetermined quantity of TJ Cubits.  The
application of the payment should be an entry, by  the  SysOp  of
the  local  Fido,  into  the  USER.BBS  file.   This  places  the
necessary information into a location that can be verified  as  a
user  utilizes their allocation of cubits.  Each time an entry to
the mail system is made, the  available  cubit  quantity  can  be
updated on a real time basis.

Another major problem is the verification of recieved mail.  This
applies  not only to the FidoNet concept, but also to the message
system as it exists in FidoBBS.  A possible way of  handling  the
transfer/receipt  of  remote  mail,  is  to  calculate the return
message (received your  message  ###  at  FidoNet  Location  ###,
time/date...)   as  part  of  the  initial outgoing message.  The
local  FidoMail  system  should  in  theory,  check  the  senders
USER.BBS  record  to  determine  the  message area last used, and
enter a message with the acknowledgement.  As  this  pertains  to
local  messages, when a message is entered, Fido could verify the
name of the "To:" party, and the message area last used.

Another thing to be considered is the possiblity of automating SQ
and  LU  modules  in  conjunction within a destination processor.
This could squeeze all messages, and pack them into a library for
each  destination,  cutting  costs  even  further.   If  not   to
difficult,  the  receiving  Fido  could  utilize  a squeezed file
interpreter to  speed  up  the  acknowledgement  of  receipt,  as
opposed   to   unsqueezing/de-lbr   while   on  line.   The  only
alternative would  be  for  the  remote  Fido  to  call  back  an
acknowledgement,  shifting  the  cost to a location not receiving
the payment.

The  prospect  of  transferring,  or  as in another communication
which shall remain un-named,  "attachment"  of  program  or  data
files  would  definately increase the potential value of FidoNet.
This is especially true for club  or  commercial  ventures.   The
problem  becomes  one  of  cost accounting.  Would subscribers be
willing to pay for a portion, pro-rated amount, of the  transfer?
Obviously a stickey point, but should be considered.

I  certainly  hope that this input is helpful.  The possiblity of
using this type of relay system is exciting!  Hopefully  it  will
be rewarding.