Preferred Implementations

Raspberry Pi and similar small computing platforms are most suitable
for the primary implementation. They are low powered, DC, and highly
mobile. A unit can be put into a car as a black box and never
touched by the owner. It is capable of using its internal wifi
adapter and a USB wifi adapter to serve as a server and client
at the same time. The client would constantly be searching for
other nodes. The unit can be programmed to shut itself down
an hour (or however long) after the vehicle is turned off. When the
user get home, their laptop can access it.

A custom rapid-acquisition wireless adapter or low-level
driver for standard hardware, combined with RAMdisk or SSD
will enable drive-by data exchanges.

Smartphones are also a good platform. They bear the necessary wifi
equipment and are always on the move. A simple app will activate
phones for the system. A business or local association can display
a smartphone QR code that will take a user directly to an application
install page.

A cell phone should be able to use this system through the internet
(gateway site) or its wifi client. The user can set their phone to roaming
client mode, server mode, or a switching mode that goes back and forth
on a certain interval. A single friendly cell phone with unlimited
internet can provide an internet gateway to all those it is in the
vicinity of in a day.

In a city setting, the congestion provided by traffic will ensure
that the daily packages will be well distributed.


Basic Server Configuration - taking HTTP-style queries.
--------------------------------------

GET /indexdatetime.txt gives the date/time stamp of the index file.

Calling GET / or GET /index.txt or GET /index.zip
gives the index file which has txt extensions for all datafiles.
A pull of a file with a zip extension causes the server to distribute
a zipped version. Otherwise, it gives what they ask for. The index file
has the filename, the time/date stamp of its last modification as UTC,
the two shasums, the size as txt and the size as zip. These are
separated by %BK% tokens.

As regards pulling the actual data files, which files are identified
by the abbreviated location and date stamp of its entries, calling
GET /filename.txt or .zip
will give the entire data file.
Calling GET /filename.txt/shasum (or .zip instead of .txt)
will give the entry identified by that hash.
Calling GET /filename.txt/shasumA-shasumB (or .zip instead of .txt)
will give the entries in the range defined by those hashes.
Calling GET /filename.txt/hashlist.txt or .zip will yield a list
of all regular hashes in the file, sorted for efficient distribution as is
described below, by the server. GET /filename.txt/headerhashlist.txt
or .zip is for the headers.

Lines are separated by %LBK% instead of newline characters. Ports for incoming data request connections: 80, 81, 82. This is because
anyone behind a firewall should be able to access 80, and others in case an
unfriendly webserver is already in use. Client software will know if
it is given what it wants versus a standard webpage. These connections are
for the DOWNLOADING of data, so the system can be run in conjunction with
a webserver. Client software and users must know on their own how to
download the data when using a web browser or a site that distributes
the data via its normal webserver, since domain issues get involved. Some
server engines may choose to provide search queries, etc.

Ports to upload data are: 443, 444, 445. This is to allow access through
a firewall. These connections are not HTTP, but are straight text OR ZIP
into the socket. This upload can simply be one entry or a whole file.
The server should organize the files by date time. If the entry is
has no tokens, that is fine as the server can accept it as the main text
entry and choose to fill in the other fields, including some with NULL.

Any advanced features are to be implemented in the header in an XML fashion
such that the oldest of clients continue to work indefinitely.

Advanced features such as:
Pruning of the local files based on x,y,z..with a
note of details, such as what method was used for pruning.
Destruction of entries that do not follow the basic profile.

Special Client Features (to be implemented on a web page,
software app, or even just a text editor:
Searching for relevant (to the individual user) content.
Working with a PGP signature so you know for sure
(kinda) who sent a certain message, so you can
search by message

*Consistent Date sorting (by entry's date, from oldest to newest) by a server
could be useful in case two systems have a complete file and yet entries were
received at different times so the files are not ordered the same and would not
have matching hashes.
If they are sorted, they would match, and this would save time that could be
wasted working on them. Once again, this is not mandatory.

When data is transferred, systems should choose to transmit the shorter
and older messages first, such that the number of entries served in a
broken connection will be higher.

Each entry has: an shasum of all of the following entries, an abbreviated
location descriptor (the names of states or actual regions), a date/time
stamp (from the issuer's computer), a SENDER, a RECIPIENT, keywords,
detailed location descriptor (up to the user, but we recommend at least
county,state,country), and the text.

A server should not feel that it is necessary to output the hash with
each requested entry. A smart client will be able to tell if the hash
(which will be discarded) was included or not due to the number of tokens
in the entry. Tokenized information after the last necessary token will
be discarded. Too many tokens could result in such a client assuming
that the first field was a hash, and discarding it.

Return to the main page.

Hermann L. Johnson. January 2019. Free for unmodified redistribution and non-commercial use.