Goals? Format compatibility: yes. CLI compatibility?

[xpe]

I have a few ideas/suggestions, but first I wanted to get clearer on the project philosophy/goals.

1. It seems that a goal of rustic is to maintain format compatibility with restic. What "level" of a priority is this? One way to answer this question indirectly would be ask this question: If we found improvements that required breaking changes, would breaking compatibility be on the table?

2. It seems that rustic is happy to add features beyond restic. Is there a "project position" on CLI compatibility? It seems clear that exact compatibility isn't a goal, but it seems like there is a spirit of compatibility. If so, that would suggest the value of documentation showing how to do the same thing in both rustic and restic.

I have read the FAQ and Comparison with Restic, but they don't (yet) directly answer the questions above. But I haven't read everything in the discussion forums and issue tracker, so some of my commentary might already be answered. In any case, I feel like these questions are very helpful for a new person looking into a new open source project, so collecting them in one place would be beneficial.

[aawsome]

Thanks @xpe for your questions. This has been already discussed, but I didn't find it within a quick search, so this is definitively a topic to document somewhere, most likely within #757.

About 1.: The goal is to stay repository compatible. That simply means that backups done by restic must stay restorable by rustic and backups made by rustic must stay restorable by restic. We may add optional fields to the repository structs in order to add new functionality but have to make sure that those can be easily removed without losing restore information.

About 2. CLI compatibility with restic is not a goal. The CLI is of course inspired by existing restic CLI commands and options, but only uses what makes sense. Actually even restic recently changed their CLI using rustic's CLI command repair index instead of rebuild-index. I would go even further that breaking CLI changes are allowed within rustic but need to be introduced in a nice way.

General remark: Currently we are in the progress of splitting rustic: A core/backend crate rustic_core which basically contains all logic about the repository format and commands on the repository. And the rustic crate which is only the CLI layer above rustic_core. I hope we or other developers can offer other frontends soon like GUIs or backup schedulers only running the equivalent of rustic backup in a centrally-coordinated way.

[simonsan]

I contacted him again, I did that a while ago via mastodon, but had no answer coming in: benjizhai/cketh-ethereum-contracts#5

[wechsler42]

"I hope we or other developers can offer other frontends soon like GUIs or backup schedulers only running the equivalent of rustic backup in a centrally-coordinated way."
I would strongly support the idea of a Web GUI which would share the same attention by the rustic developers as the CLI does. The missing of this is in my point of view a drawback with which veterans like Borg Backup, Restic, etc live all their live time. In their product history you could see several initiatives which have led to desktop applications, CLI wrappers or Web GUIs but they usually lack of functions, maintenance or the further development is ceased etc.. So I really hope that the Rustic project finds a way for a Web GUI equivalent to the CLI.

[simonsan]

For sure, an idea is to utilize something like Dioxus there, so we already have most of the rust backend part and could implement the UI part with svelte for example.

EDIT: After reading more into Dioxus, you wouldn't need any other frontend framework.

That shouldn't be something so out of line. BUT: First we need to get the library right and improve various other constructions sites for new users chiming in (e.g., documentation). Because from the UX perspective, I would say that restic and rustic are kind of advanced backup tools (due to their amount of possibilities and options). Creating a good and intuitive UI for that needs a lot of research and design work beforehand.

[wechsler42]

"Creating a good and intuitive UI for that needs a lot of research and design work beforehand." Indeed, you are right, especially for advanced backup tools like restic/rustic. When I look at the folks at Duplicati, they chose for the Web GUI of version 2.x the approach that they offer a sort of assistant guided approach for setting up backup jobs as well for restore operations. All the more advanced or expert stuff (advanced options for each command) could be picked up via a drop down menu. Perhaps this give some inspiration for creating a good and intuitive Web GUI for rustic.

[simonsan]

Yes, I think that would be the way to go. Having a UI that has basically two buttons backup and restore and having an I'm an expert field which shows the whole power for tech-savvy users. And then backup and restore are guided in the general case. all other options should be easy to find but not overwhelming to the user. etc.

I added personas, use cases, user stories and requirements in #808, I think that this will help to strike the right balance.

[simonsan]

Right. It probably wouldn't hurt to reach out to the current owner of https://crates.io/crates/rustic and see if they would release it to you. Maybe they don't plan on using it? Their associated Github repository seems gone: https://github.com/astefanutti/rustic .

https://github.com/internet-computer-protocol/rustic/

They initialized it now new with some crypto (as in blockchain) stuff 🤦🏽