Integration with Sutty: Publishing changes to Distributed Press

[fauno]

Related to #26

The current APIv0 only accepts a full tarball of the website before publishing it. Adding support for incremental synchronization would make publication faster. distributed-press-api-client streams the tarball so it doesn't have to tarball-then-send.

Some ideas:

• SSH+Rsync: are well-stablished, well-known and secure methods to synchronize directories. Distributed Press could be such a server, and it would only need a public SSH key to authenticate site owners. An authorized_keys file can be generated for each key with the exact command it allows for synchronization (ie. rrsync), providing rw access to the site directory and nothing else. This can be achieved using the AuthorizedKeysCommand directive (see sshd_config(5)), a pseudo-shell like Gitlab and Gitea or even statically generated authorized_keys files (prepending options to a public key, see sshd(8) § "AUTHORIZED_KEYS FILE FORMAT").

  Also SSH private keys can be used to sign authorization tokens on OpenSSH latest versions (I think it's supported since v8).

  Sutty already supports pushing changes to SSH+Rsync servers. This replaced Syncthing for synchronization between servers a few months ago. We had to because ST was creating issues with filename UTF-8 normalization and sometimes just simply refused to synchronize some files.

• Neocities-like API: provides synchronization over HTTPS and clients can detect files changes locally by comparing checksums. I'm not sure of the details, but client-side it's like Rsync over HTTPS.

• In any case, an API endpoint for running hooks could be added, so it can be pinged after a successful synchronization to run publication tasks.

[fauno]

Just checked neocities API client it sends each file's path + SHA1 to the API and if they differ it POSTs the contents.

[RangerMauve]

Should we close this now that sutty integration seems to be working?