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.