Juan Bautista Peretto / Software engineer

Case study · 2026

fassht

An experimental Go terminal interface for opening and editing remote files through existing SSH configuration.

Contribution
Independent project
Status
Experimental pre-1.0
Scope
SSH configuration · Terminal interface · Local editor · SSH and SFTP session · One remote file
Source
Publicly readable; no licence yet

Context

The experiment began from a recurring task: connecting to a known SSH host, locating one file and editing it with a familiar local editor without assembling several manual commands.

What exists today

The repository explores host selection, remote browsing, SFTP transfer and the local-editor handoff in a terminal interface written in Go. It is useful evidence of systems-oriented product exploration, not a stable tool recommendation.

Direction and limits

The next meaningful milestone is safety, not more features. Strict host verification, atomic replacement, bounded permission handling, unique temporary files and failure-path tests come before installation guidance or a first release.

System overview

  1. SSH configuration
  2. Terminal interface
  3. Local editor
  4. SSH and SFTP session
  5. One remote file

Three decisions worth discussing

Existing SSH configuration

Hosts and authentication stay in the user's established SSH setup.

Local editor

Editing remains in the tool the user already knows instead of recreating an editor.

Deliberately narrow scope

The product direction is one safe remote-file workflow, not a general SFTP manager.

From problem to evidence

  1. 1
    Problem

    Editing one known remote file repeatedly required assembling the same sequence of SSH and transfer commands.

  2. 2
    Constraint

    The workflow had to reuse the user's SSH configuration and local editor without pretending to be a general file manager.

  3. 3
    Decision

    Build a narrow terminal interface around host selection, SFTP transfer and a local-editor handoff.

  4. 4
    Evidence

    The public Go prototype implements that end-to-end path and makes the remaining safety work explicit.

Technical notes

Host trust

The current fallback is not safe enough; a future release must require explicit known-host verification.

Atomic writes

A trustworthy version must upload to a unique temporary path and rename only after a complete successful write.

Permissions and cleanup

Privilege handling, temporary files and editor exit paths need bounded behaviour and automated failure tests.

Current limitations