DASL — Data-Addressed Structures & Links — is a small set of simple, standard primitives for working with content-addressed, linked data. If
README.md

Hosting dasl.ing on supramundane #

This directory is an sm service that hosts https://dasl.ing/ behind the supramundane front proxy. Unlike a stock sm static service, the content is not baked into the image: the container is just a Caddy file_server rooted at /data, which is the service's directory in the shared data root (/srv/supramundane/data/dasl-ing on the host). New content lands there over SSH and is live immediately — no rebuild, no restart.

One-time setup #

  1. Stand the service up (builds the container, mounts the data dir, wires dasl.ing into the front proxy):

    cd sm && sm deploy
    
  2. Create a dedicated deploy key and authorize it on the server, for the same user sm deploys as (so it can write to the data dir):

    ssh-keygen -t ed25519 -f dasl-ing-deploy -N "" -C dasl-ing-deploy
    ssh $SUPRAMUNDANE 'cat >> ~/.ssh/authorized_keys' < dasl-ing-deploy.pub
    

    Then restrict the key so it can only ever rsync into the data directory, by prefixing its authorized_keys line with:

    command="rrsync -wo /srv/supramundane/data/dasl-ing",restrict 
    

    (rrsync ships with rsync.) The workflow relies on this restriction: rrsync anchors transfers inside that directory, which is why DEPLOY_PATH in the workflow is ".". If you ever use an unrestricted key instead, set DEPLOY_PATH to the absolute data dir path.

  3. On Tangled (repo → Settings → Pipelines), pick a spindle for the repo and add three secrets:

    Secret Value
    DEPLOY_TARGET <user>@<server>, e.g. robin@$SUPRAMUNDANE
    DEPLOY_SSH_KEY contents of dasl-ing-deploy (the private key, pasted whole)
    DEPLOY_KNOWN_HOSTS output of ssh-keyscan -t ed25519 <server>

    Then delete the local copy of dasl-ing-deploy.

Continuous deploys #

.tangled/workflows/deploy.yml runs npm run build and rsyncs the generated build/ directory — and only that — into the service's data directory on every push to main. It can also be triggered manually from the repo's pipelines page. The site is built in CI, so there is nothing to regenerate before pushing.

Redeploy this directory (sm deploy) only when the container itself changes (Caddyfile, Dockerfile, compose, domains in service.json).