It was vervis.localhost, probably a remainder from the time before the FedURI
rewrite, where it had to contain a period character. Now, in dev mode, it needs
to *not* contain one, and localhost works just fine and makes sense more than
anything else probably.
In Darcs, any command can have a post hook (and a pre hook), and the hook
command can be set using a command-line option to the darcs command that you
run. So, in the Vervis SSH server, if we add a --posthook option when running
`darcs apply` to apply remotely received patches, we get a chance to process
the patch data much like in the git post-receive hook.
The setup this patch creates is similar to the git one: It writes a
_darcs/prefs/defaults file to all Darcs repos, and that defaults file sets the
posthook line for `darcs apply`. The posthook line simply executes the actual
hook program written in Haskell.
The current hook program is a one-liner that prints a line to stdout, so every
time you `darcs push` you can tell the hook got executed. The next step is to
implement the actual hook logic, by reading patch data from the environment
variable in which Darcs puts it.
Here's how it works:
- When Vervis starts, it writes a config file and it writes post-receive hooks
into all the repos it manages
- When a git push is accepted, git runs the post-receive hook, which is a
trivial shell script that executes the actual Haskell program implementing
the hook logic
- The Haskell hook program generates a Push JSON object and HTTP POSTs it to
Vervis running on localhost
- Vervis currently responds with an error, the next step is to implement the
actual publishing of ForgeFed Push activities
The settings file is now used only during run time, and build-time settings are
set directly in source code. This patch removes those settings from the YAML
file, since they're unused, to avoid confusion.
I'm not sure what the best balance is, but once an hour may end up causing a
lot more key re-fetch requests coming from other servers. I prefer to default
to once a day for now (maybe even once a week) and tighten it later if needed.
Caveat: If an instance key is rotated once a day, there's no
change-key-right-after-toot-deletion thing for deniability. Potentially,
rotation may happen only 24 hours after that deletion, which is much more than
1 hour. On the other hand, it's a whole instance key, not personal key of the
actor.
The actor key will be used for all actors on the server. It's held in a `TVar`
so that it can always be safely updated and safely retrieved (technically there
is a single writer so IORef and MVar could work, but they require extra care
while TVar is by design suited for this sort of thing).
