The application privacy policy is located here: http://hotdoged.propush.ru/docs/policy
Requirments:
- Android 2.3+.
- Fidonet point or NNTP-server access.
Installation:
1. Download and install the feed providers you need:
fido: http://vp.propush.ru/download/HotdogEdFIDO.apk or in Google Play
nntp: available in Google Play.
Nothing will appear on your desktop right now.
2. Download and install HotdogEd editor:
http://vp.propush.ru/download/HotdogEd.apk 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/ 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, 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 s 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
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
And the tag
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 native tag
n5020.sysop ru.linux hotdoged
I have a unix shell command for HPT that generates a list of areas for
In the list of nodes, 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 d.
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.
HotdogEd is pluggable software. It hosts an sqlite3 database and provides methods of accessing it under Android via the content-provider mechanism.
If you would like to create a plugin (i.e. you want a 3-rd party FTN-mailer and tosser), you can access the content by the following URIs:
There are some more URIs that are intended for internal purposes.
Here is a database scheme actual for 2.13.x:
You are free to use this data as you like :) If you have any questions or would like to develop some other provider (and extend category list), please feel free to contact me.
Âñå ïðàâà ñîõðàíåíû © Ñàéò ðóññêîÿçû÷íîãî fidonet
Ïåðåïóáëèêàöèÿ ìàòåðèàëîâ, âîçìîæíà òîëüêî ñ óñòíîãî èëè ïèñüìåííîãî ðàçðåøåíèÿ àäìèíèñòðàöèè ñàéòà!