0 Fork 0

mirror of https://github.com/narrrl/narl-workspace.git synced 2026-11-03 16:41:27 +01:00

Files

T

nvrl 7f8d625a8d commands: one grammar for !, merged commands, a settings sheet, two-level help

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.

2026-10-22 15:35:36 +02:00

3.0 KiB

Raw Blame History

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:

: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:

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. 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.

3.0 KiB Raw Blame History