Skip to content

Implement upload history #678

@Cafe137

Description

@Cafe137

Problem statement

Upload commands addressed via swarm-cli upload and swarm-cli feed upload print the resulting address (also called "reference" or "hash"), but it is not persisted anywhere. If the user does not manually copy the hash and save it elsewhere, it will be lost (just the link to it, not the actual data on the network).

New feature

Upload history

Implement a new feature in swarm-cli that maintains an upload history in a JSON file. A similar system is already implemented for the identity commands, see src/command/root-command/command-config.ts.

The two upload commands are implemented in src/command/upload.ts and src/command/feed/upload.ts. In the former, the resulting hash is tracked in the class field public result: Optional<Reference> = Optional.empty(), and in the latter it is also in a class field public feedManifest?: Reference. After successful uploads, store the Swarm hash from these fields in the history and persist.

history list command

Implement a new group (history) and a new command (list) that prints the upload history in a nice, user-friendly way (table?).

Upload history item structure

Suggested information to save for an upload:

  • UNIX timestamp
  • Resulting reference
  • Which postage batch was used
  • Uploaded file or folder path (nullable, null if uploading from stdin)
  • Type: was it a file, folder, or data from stdin? (maybe can be merged with previous field)
  • Resulting feed address (nullable, only for feed upload)
  • Which identity was used (nullable, only for feed upload)
  • process.argv - Not sure about this, does it add value? If we go ahead with this, only print with history list --verbose

Possible improvements

  • Filter options (CLI flags) for history list, e.g. filter by stamp, by date, or find by name match.

Next iteration

  • Users who do not wish to have any information stored on their disk about their interactions with the network may find this feature hostile. Before releasing this, we may need to iterate on this to make this feature opt-in.
  • Download history too?

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions