Alright, I said I was going to do i2p this week.

printf "7looking for:\t((hour . 1))\n((hour . 6))\n" | nc \
       -x127.0.0.1:4447 \
       acc2svi43emo3sri5pxbwmhrm5lprktwkv4jxkjcejmqbwpzsgwq.b32.i2p 70
((SECOND . 37) (MINUTE . 32) (HOUR . 10) (DATE . 22) (MONTH . 5) (YEAR . 2022)
 (TIMEZONE . 0))

I  imagine   you have installed  i2pd (pkg_add  i2pd) and either   left  its
defaults intact, or are comfortable yourself.  I hope you also have a normal
openbsd  netcat  (nc).   There is a socks5 (I guess?)  tcp tunnel  to a port
broadcast as port 70 over i2p. In particular  it is that a+b-c.lisp date app
from yesterday  (except  talking to a usocket  tcp stream).   I have two one
second  pauses because  #'force-output  seems to need to be waited  for, and
#'finish-output   doesn't   seem  to do what I want.  And forming   the  i2p
connection seems to take a few seconds already. 

In finer resolution, at my eepher address:

acc2svi43emo3sri5pxbwmhrm5lprktwkv4jxkjcejmqbwpzsgwq.b32.i2p

Port 70

I am serving a slightly liberally minded item type 7. The rule for item type
7 is that  you send the item specifier  followed by a tab.   Here,  now I am
telling you that the item specifier is 

7looking for:

followed by a literal tab. Item type 7 is handled by the server by reading a
line (until a double? CRLF I think). I am a bit badly behaved in that I just
attempt   3  (optional)  lisp READs (*read-eval*  nil).  Those can  be  time
specifiers  that look kind of like what you get if you don't  send anything.
So minimally: 

printf "7looking for:\t" | nc -x127.0.0.1:4447 \
       acc2svi43emo3sri5pxbwmhrm5lprktwkv4jxkjcejmqbwpzsgwq.b32.i2p 70

One bug for me is that if you send a newline, my app thinks you're trying to
send a date specifier  like ((hour . 3))\n and tries to wait for you. Please
hang  up on your  own in that case ;p.  The EOF from  not sending  a newline
works as a newline which is why cutting off after the \t works. 

If it's useful,  you are welcome to use it. If it has too much  interference
I'll  patch  it...   I guess  it should  really  be an inetd  thing  to take
advantage of inetd's behaviors. I do log (get-universal-time) when I receive
a connection,  and it is possible  that when an error happens  what you send
might   show up in my logs,  but generally  I am not attempting  to log time
queries.