it's 5:30a the following day and i'm having trouble moving my legs.
   i'm outdoors under a tarp shelter I put up recently, in four nested
   sleeping bags.  it's raining on the tarp and dry in here.
   since I was having trouble standing I was looking through
   opentimestamps a little on my phone, which disabled airplane mode on
   its own some time while I was asleep.
   it looks like the calendar servers also do blockchain publishing
   remotely, and their protocol doesn't appear to require data other than
   the op_return payload, although i'm not certain of this.  here's what I
   found:
   - they take only this payload when publishing
   - they expect a bitcoin daemon to be running on the server
   since the client also locally performs bitcoin publishing, they
   probably minimize their use of their blockchain, dunno.
   it's 5:34 and maybe i'll stand up!  pretty hard.  hmm.
   it's easier to stand up when there's a confident reason.  let's check
   out that opentimestamps server behavior. the server is
   at [1]https://github.com/opentimestamps/opentimestamps-server possibly.
   535
   -> the max length accepted is a constant called MAX_DIGEST_LENGTH
   537
   the timestamp is submitted to an aggregator attribute of the rpc
   handler self.aggregator.submit(digest) .  I don't see where aggregator
   is set yet.  the max digest length appears to be 64 bytes.
   539
   aggregator is manually set by StampServer which accepts it to its
   constructor
   second parameter, after address
   541
   the otsd entrypoint is in the root folder of the repo
   it instantiates an Aggregator class
   543
   Aggregator is in calendar.
   in its submit function it has further code for adding a nonce
   server-side, with specific purpose of preventing control of published
   data by the client.
   it's possible this was done poorly, but it seems calendar servers are
   unlikely to be good for publishing data.

References

   1. https://github.com/opentimestamps/opentimestamps-server