mirror of
https://github.com/narrrl/narl-workspace.git
synced 2026-11-03 16:41:27 +01:00
nvrl
7f8d625a8d
A `!` now means force or everything and nothing else (`:w!`, `:search!`, `:export!`, `:logout!`). A command that did a second thing behind its bang takes a word for it instead: `:space new|name|rm`, `:list name|rm`, `:task [add]|edit`, `:upload seal`, `:import zip [/]`. `:card` while reading a document makes a card about it, so `:card!` is gone. Merged: `:export` downloads what has focus, a file as it is or a document as markdown (`:download` folded in); `:share [off|new]` replaces `:unshare` and `:link`, and the list's `s` and `y` give way to it and the info sheet; `:noh` replaces `:clear`; `:vault [unlock|lock|passwd]` replaces `:unlock`, `:lock` and `:passwd`; Esc in the list puts down what `m` picked up before it closes the document, replacing `:unmark`. The old spellings run as their new lines for one release through a table in commands.ts; help and Tab leave them out, and the wiki lists them. A settings sheet (`,` or `:settings`) holds the options, the vault, the backup, the signed-in browsers, ssh keys and capture tokens. Each row runs the command a line would. Bare `:set`, `:vault`, `:backup`, `:sessions`, `:sshkey` and `:token` open it at their part. `?` shows the keys and commands to start with, flagged in the keymap and the command table; a second `?` (or `:help all`) shows all of them, and a filter always searches all of them. Help rows are keyed by key and description, as two contexts can share a label.
73 lines
3.0 KiB
Markdown
73 lines
3.0 KiB
Markdown
# The SFTP mount
|
|
|
|
The workspace can be mounted as a filesystem over SFTP, so an editor or a file
|
|
manager on another machine works on it directly.
|
|
|
|
## Turning it on
|
|
|
|
It is off until `WORKSPACE_SFTP_BIND` is set, for example `127.0.0.1:2222`, or
|
|
`0.0.0.0:2222` in a container with the port published. Only public keys get
|
|
in, and only the ones registered from inside the workspace:
|
|
|
|
```text
|
|
:sshkey add laptop ssh-ed25519 AAAA… you@laptop
|
|
:sshkey the settings sheet's ssh keys, with their fingerprints
|
|
:sshkey rm laptop and this one is out, mounted or not
|
|
:sshkey vault laptop on this key may read sealed files while the vault is open
|
|
```
|
|
|
|
Then, on the other machine:
|
|
|
|
```sh
|
|
sshfs -p 2222 me@your-host:/ ~/workspace # the user name is ignored
|
|
```
|
|
|
|
The server makes its host key on first start, as `sftp_host_key` in the data
|
|
directory.
|
|
|
|
## What it looks like
|
|
|
|
- The root holds the spaces; `mkdir` there makes a space, anywhere else a
|
|
folder.
|
|
- A document is `<slug>.md`, read as `# Title` followed by its body. Writing a
|
|
different first heading back renames it.
|
|
- Files sit beside the documents under their own names. A later file with the
|
|
same name is told apart by its id: `slides (42).pdf`.
|
|
- A document's own files are in `<slug>/`, beside its `.md`. The directory is
|
|
listed once the document has a file, and can be copied into either way. It
|
|
holds files and nothing else, and moves when the `.md` is renamed.
|
|
- Anything copied in that is not a `.md` becomes a file, and its text is
|
|
indexed for search.
|
|
- `rm` and `rmdir` put things in the trash, as a delete in the browser does.
|
|
|
|
## Editors
|
|
|
|
Editors and `rsync` save by writing a temporary file and renaming it over the
|
|
real one. The mount understands that:
|
|
|
|
- swap files, `~` backups and dotted temporary files stay in memory for the
|
|
session and never appear in the workspace;
|
|
- a temporary file renamed onto a real name saves into that document or file;
|
|
- a rename onto a name that is taken replaces what was there, as `rename(2)`
|
|
does, without filling the trash.
|
|
|
|
A save over the mount keeps a version of what it replaces, see
|
|
[history](Not-Losing-Things.md#history). If the document was saved in the
|
|
browser while the SFTP client had it open, the client's save does not
|
|
overwrite it: it lands beside it as `<name>-conflict.md`, and both are kept.
|
|
|
|
## Sealed files
|
|
|
|
A file copied into a sealed folder is sealed on the way in, while the vault is
|
|
open in the browser. Reading one back needs more: a key is a standing
|
|
credential on another machine, so it reads sealed files only after
|
|
`:sshkey vault <name> on`, and only while the vault is open. Shutting the vault
|
|
or taking the access away cuts off a read already under way. Nothing done over
|
|
the mount keeps the vault open; only the browser does.
|
|
|
|
## Limits
|
|
|
|
A session holds at most 256 handles and 64 MB in memory, the server at most 32
|
|
connections, and a client that stops answering is dropped within a few minutes.
|
|
Removing a key in the browser ends what that key has mounted.
|