Manual contract formation and priortization

[skunk-ink]

Description

It would be helpful if, from the host's list, users could select hosts that they would like to prioritize contract formation with. This would effectively tell renterd that the user is happy with this specific host and would like to maintain this contract.

It also might make sense to allow users to give prioritized hosts a bit of leeway. For example, if the user knows that a specific host has been exceptionally reliable and they trust that if the host goes offline, it is for a legitimate reason. The user might then be okay with giving that host a bit of extra time to figure out the problem. As a user myself, if I have a host that I've had a contract with for, let's say, over a year, and they have never been offline or lost any data. I would much prefer to maintain a contract with them even if they went offline for a bit. Because if I am confident that the host will return, maintaining that contract could prevent an unneeded repair of that data.

Of course, you wouldn't want to just give the host a pass, and you'd want to ultimately drop the contract if the host takes too long to solve the issue. So maybe something, where the user could set a grace period for prioritized hosts, would be good. I could set it to 24 hours or something, where if the host is offline longer than the grace period, it will then be unprioritized and treated as a regular host.

Eg.

Version

v1.0.5

What operating system are you running (e.g. Ubuntu 22.04, macOS, Windows 11)?

Ubuntu 22.04.3 Server LTS

Anything else?

No response

[ChrisSchinnerl]

This is an interesting proposal but I think we will need to brainstorm this a bit more and refine it. The problem is that the more knobs you add for users to play around with, the more confusing the overall experience gets.

While I can definitely see the appeal of a preferred host list since it makes sense that you would like to "bookmark" great hosts you have encountered, it seems like the specific issue we are trying to solve here is losing a contract due to a host going offline. So first of all we need to spend time figuring out why all the leeways we already have in place don't prevent that issue.

Once that is fixed, we can think about what that feature would look like exactly. My guess is that you'd want a preferred host to

• be scoped to a specific autopilot and not be enforced globally
• ignore min score checks
• ignore gouging checks (except for when actually using the contract)
• ignore offline checks
• ignore redundant IP checks while still contributing to the subnets we consider for those checks
• still be more likely to be picked amongst other preferred hosts if the score is better

The problem with all of these ignored checks is that a user is still interested in the cases where a preferred host is actually not good anymore but still kept around. Which is why we probably want to register alerts for all preferred hosts that fail any checks that would cause regular hosts to be removed from the set.

[skunk-ink]

Yeah, I agree there is a risk of keeping a host around too long after they have gone bad. That's why I suggested maybe something like giving the user the ability to set a grace period. It would also be good to log any failed checks just so the user is aware of it. But the grace period would essentially allow the user to say that for this specific host, they are willing to give them an extra bit of time to sort out a problem, but after a set amount of time, the host should be dropped as a preferred host.

[ChrisSchinnerl]

If we add a feature that allows the user to tell the autopilot that a host is good I would keep it that way and also require manual intervention to remove that host again. Of course with the guidance of the autopilot which can tell you about that host not being good anymore. Otherwise a preferred host is not much more than a regular one since we already allow hosts to be offline for a while before dropping them.

Then it would also be a pretty nice feature for advanced users who actively pick hosts to keep and watch their alerts.