- Android 2.3+.
- Fidonet point or NNTP-server access.

1. Download and install the feed providers you need:
fido: or in Google Play
nntp: available in Google Play.
Nothing will appear on your desktop right now.

2. Download and install HotdogEd editor: or in Google Play.

3. Run HotdogEd. After a while you'll see categories of the feed providers you've just installed. Press "Add new..." to add a new account. You can add/delete categories later, but don't forget to restart HotdogEd in order to activate them.

How to setup the HotdogEd to work with fidonet?
I tried to create a self-explaining user interface, but if there are some difficulties, here are some advices that could help you start.
If you have an existing point address, use this manual (in Russian) to fill the requested fields.
If you don't yet have a point, but want to get one, install the Fidonet provider, editor and then after the program starts click "Add new..." under Fidonet section and then "Request point". Then just choose the node you want to link to. Good luck and have fun :)
The documentation creation is in progress...

Taking a participation in point requests
Since 2.11 any sysop can announce his node to accept new point requests via HotdogEd in the program's interface.
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:

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:
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:

    <node ftnaddress="2:5020/1906" requestby="email">
        <system>Damage BBS</system>
        <sysop>Alexander Lobachev</sysop>

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 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:

    <node ftnaddress="2:5020/2141" requestby="http">
        <system>Pushkin's BBS</system>
        <sysop>Sergey Poziturin</sysop>
        <note>Welcome, friends. A lot of echoes. No fileechoes. Добро пожаловать. Много эх. Файлэх нет.</note>

Note the <note> 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 <areasfull> 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:
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.

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 <areasfull>.

There is also an alternative tag <areas>. It's the URL pointing to a simple echo list: one area per line, just area name, no other info. Example:


I have a unix shell command for HPT that generates a list of areas for <areas> 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.

Developing for HotdogEd

If you are willing to take part in developing for Hotdoged, please consider reading this.

Using scoring, virtual groups and filters

Sinse 2.13 it's possible to use scoring and virtul groups.

Scoring is the way of assigning a rating to the article. Rating affects the way articles are sorted. If rating is 0 (this is the default value), the sorting is done as usual accorodng to preferred sorting order. But once the rating (score) is increased, the article goes higher in article list. Lower scores make article go lower.
Also articles with positive scores are marked green in article list. Negative score colors them in red. If score is not equals to zero, the rating is displayed in square brackets on the left of the subject in article list:

Assigned score can be relative or absolute. Relative score is the one that is added or substracted from the previous score of the article, if there are several of them. Absolute article is assigned as is.
If a score gets below -100, the article is banned (not shown). When exiting a group, HotdogEd asks you of you'd like to mark all articles with negative score as read. It can be tweaked in general settings.
Filters are used to assign scores (see below).

Virtual groups give you a way to organize you messages or search some information. Virtual group is a group that includes articles from other groups (except virtual ones, of course).

Both virtual groups and scores are ruled by filters. Each filter is a set of conditions (i.e. to name equals to "Sergey Pushkin" or subject contains "android") combined by AND or OR filter group. AND/OR groups can include other groups so the filters can be very complex. There is also a NOT filter group that negates the filter included.

When a scoring filter matches an article, it's rating is set according to scoring rules. When a virtual group filter matches an article it's included in a virtual group and will be shown if you enter this group.
Consider not using a lot of filters with searching by "Article" field, because full text search is not something your phone wants to do every time article list is refreshed :) It's not a database server. Nevertheless filters (both for scoring and virtual groups) are rather lightweight and don't consume too much resourses. Good examples of virtual groups are "Starred" and "To me" groups. Now they can be configured as you like and even deleted.

Limitations: some phones may ignore case insensitive search flag with national text patterns (containing non-latin letters). It depends on the compiled-in sqlite implementation. Thanks google for that mess.

There is also an article search mechanism available. It is actually just a convinient way to create and enter a virtual group with specified search filter, but it can be saved as a virtual group that can be visited later:

Hardware keyboard navigation

Here is a list of keyboard shortcuts available when reading articles:
- 'E' - Create new article.
- 'Q' - Reply to auhtor.
- 'N' - Reply to auhtor in another group.
- 'C' - Edit article (to be used in Outgoing group).
- 'F' - Forward article.
- 'W' - Export article.
- 'Z', space - page down or next article.
- 'A' - page up or previous article.
- Left/right - Previous/next message.