Hi everyone!   
   (warning: very long letter inside! :) )   
      
   First of all I'd like to thank all of you for your support. Also thank's   
   for not letting this echo die. :)   
      
   The new release of HotdogEd is upcoming and there is one feature I'm   
   announcing beforehand in order to make all of the sysops who may find it   
   useful ready for it.   
      
   Right now, while version 2.10.x is in public, the user can make a new   
   point request from HotdogEd. But he can only request it automatically on   
   my node 2:5020/2141.   
      
   Since 2.11, that will ne available next week (I hope), any sysop can   
   announce his node to accept new point requests.   
      
   Point request can be sent from HotdogEd in 2 ways:   
      
   1. Via http POST-request to some server. The request must include 4   
   mandatory POST variables:   
   _name - point's first name and second name   
   _email - point's e-mail   
   _password - password for everything (session, pkt, etc)   
   _about - some info about the new point so that the sysop can make up his   
   mind whether to approve or decline the request.   
      
   All fields are mandatory in HotdogEd, so the user can not just skip it   
   and go on.   
      
   The server should respond with 2 lines of text: first line is OK or   
   ERROR (if the point request was approved or declined respectively ) and   
   the second line is the new 4D-address assigned to the new point (i.e.   
   2:234/567.89) or the reason of the decline (i.e. Sorry, you are lame).   
      
   In case of OK response, HotdogEd makes all the necessary setup   
   automatically and the user can enjoy fido starting from this moment, if   
   there is an automatic approve algorythm on the node side. I myself   
   prefer 2-way algorythm, where the user sends me a request and I approve   
   it later. The user receives several e-mails after both stages. But it's   
   up to you to decide. I know one of my friends approves all requests   
   automatocally.   
      
   2. Via e-mail request. HotdogEd just composes a letter to sysop and   
   sends it by e-mail after user enters all the data about himself   
   mentioned above. Of course the sysop should receive this email and   
   manually setup his node to accept the new point. And he should also   
   notify the point of his new point address. With this method, hotdoged   
   makes all the setup for the point, except point address, because at the   
   moment of the request no one actually knows it. So HotdogEd makes setup   
   for .999 (i.e. 2:234/567.999). The user should edit the address manually   
   after receiving a response from the sysop.   
      
   As you can see the first method requires some effort from sysop to   
   implement it. But actually not very much. I think one of the sysops in   
   Russia is already working on some scripts for HPT and binkd for this and   
   soon they may become available. And Ivan Agarkov (2:5020/848) already   
   implemented the full auto-approve algorythm in his latest commit to   
   jNode repository - his beautiful and much loved tosser and mailer   
   all-in-one written in pure Java. BTW it's very powerfull and full of   
   features. And production ready! You can check it here:   
   https://github.com/kreon/jnode   
      
   The second method does not require any work extra efforts except listing   
   your node as point-request available. You just receive e-mails, reply to   
   them and make configuration changes manually. As you probably did before.   
      
   How to make HotdogEd aware of your node accepting point requests? Very   
   easy. Me and several other guys are maintaining a simple XML-file on   
   github, take a look at it:   
   https://github.com/propush/hdpntreqlist/blob/master/nodes.xml   
   HotdogEd parses it and that's how it's aware of the nodes that accept   
   point requests. The file is self-explaining and here is the easiest node   
   description:   
          
           Russia   
           Moscow   
           Damage BBS   
           Alexander Lobachev   
           ss_di(dog)mail.ru   
           binkp   
           binkp.nauchi.ru   
          
   This section tells hotdoged that node 2:5020/1906 in Moscow, Russia   
   accepts point requests by e-mail specified. Hotdoged automatically makes   
   setup for this node for binkp protocol (the only one supported at the   
   moment) and the ip-address binkp.nauchi.ru. Please fill the    
   and  tags carefully - HotdogEd asks the user to choose his   
   location and it sorts the node list so that the nearest nodes to him are   
   on top positions. It also awares the user that despite the fact that   
   fidonet is a world-wide network, some region-specific echo areas exist.   
      
   Here is an example of the node (my node btw) with http-request feature:   
          
           Russia   
           Moscow   
           Pushkin's BBS   
           Sergey Poziturin   
           Welcome, friends. A lot of echoes. No fileechoes. „®¡à®   
   ¯®¦ «®¢ âì. Œ­®£® íå. ” ©«íå ­¥â.   
           offspr@pochta.ru   
           binkp   
           vp.propush.ru:24555   
      
   http://vp.propush.ru/pntreq/request.php   
           http://vp.propush.ru/pntreq/areasfull   
          
   Note the  tag here :) This is just a note that will be displayed   
   on the user's phone if he selects 2:5020/2141 before he submits his   
   point request.   
      
   And the tag  is the second feature I'd like you to know about   
   and to get ready for it. It's optional but if you specify it, it should   
   be the URL where the full echo list of your node can be downloaded.   
   Everytime the user goes to subscription management in HotdogEd, he will   
   be able to use the list of areas available from your node. He will see   
   area name, description, message count and the latest message time for   
   every echo. You can download the file example and see it yourself:   
   http://vp.propush.ru/pntreq/areasfull   
   On my node it is generated every hour automatically.   
      
   The file consists of lines of text, one line for single echo. 4   
   comma-separated fields:   
   area name, unixtime of the last message, message count, description.   
   Example:   
   ==   
   hotdoged,1433136356,35,Autocreated echoarea   
   ==   
   (note: unixtime is the number of seconds since epoch).   
      
   First field (echo name) is mandatory. The rest are optional and can be   
   omitted for some reason. Examples:   
   ==   
   hotdoged,,35,The best android fidonet client on earth   
   linux,,,The best operation system for geeks   
   ==   
      
   If someone is using jNode, I can give you an SQL-script that produces   
   this beautiful listing for tag .   
      
   There is also an alternative tag . It's the URL pointing to a   
   simple echo list: one area per line, just area name, no other info. Example:   
   ==   
   n5020.sysop   
   ru.linux   
   hotdoged   
   ==   
      
   I have a unix shell command for HPT that generates a list of areas for   
    tag. If you need it let me know (or ask Alexey Vissarionov,   
   2:5020/545, he is the author).   
      
   In the list of nodes, where the user makes a choice which of the nodes   
   to prefer, nodes implementing http-requests are higher than those   
   preferring requests by e-mail. Nodes providing echo list are higher than   
   the others. Nodes located in the user's country and the city are the   
   highest ones.   
      
   Well, I hope you are not very bored reading all this sh.t. :) These are   
   not the only features planned for the next release. Stay tuned.   
      
   --    
   [ pushkin_kukushkin@jabber.ru ] [2:5020/2140]   
   http://vp.propush.ru   
   --- FIDOGATE 5.1.7ds   
    * Origin: Pushkin's BBS (2:5020/2140.2)