Ok, let’s dissect that.
First I disagree that anyone will impound a server unless something really really bad has transpired.
Most usual what will happen is you will get an email from your colocation/server provider letting you know there is a problem with some content on your server, or your server did something malicious(e.g. it’s part of a DoS network) and you need to deal with it within 24 hours or so and if not they will simply deny service. So if I have 10 servers running all kinds of stuff and one of these is a farmer machine, having some stupid contract I could loose hosting for all of my servers because of that. So yeah, for most people running serious hardware they won’t go into this, and anyone hosting it for fun will stop farming when they get their first email.
So, we agree that just nuking the whole server is not an option, also, who guarantees the same content won’t arrive again after restarting? So that’s not really a solution as-is now.
Double or triple signing, yes, not something we should demand. But there are 2 tweaks to this I can see.
a) while not mandatory, a 2nd or 3rd signee could raise the level of “trustfulness” one can give to a contract, maybe even give cheaper hosting to such(optional implementation if there is desire), as there is less risk of “having to deal with issues”. Also additional signees will likely want to have some transparency about the content and or the app, so likely the application itself will be more public, e.g. their public endpoints will be known, thus allowing anyone to inspect what the application appears to be doing. So, more public trust == good thing. This still allows the people to run a 0 signee contract on their own risk(for all parties), especially in the beginning.
b) there should be a way for a farmer to deny certain contracts/issuers of hosting on their farm(s), hence allowing you to say “get off of my lawn”. Which right now if I understand right the farmer has no such ability. Basically a hosts.deny kind of a thing. Actually a good possibility would be contracts.deny contracts.allow method, which can be * as default, but subsequently would allow someone to pick their contracts. Which is also freedom, freedom to choose with whom you do business with, plus it protects the farmer in these edge cases of complaints so they have a tool to ban certain contracts/issuers.
Now, obviously if it’s something contested (not something simple as CP), there will be people who will support such content so it’s a game of whack a mole for the people wanting to take it down.
But without such a mechanism there is a real adoption problem of the tech. And I would like to support this and host it, and possibly also bring some developers to help with this. But I would like to know if there is a will to get something in place which will shield people who do honest farming.
For this to work you would need to be able to:
a) identify which contracts are running on your farm(s)
b) identify which contract was active at the time of the issue, so you are able to blacklist it.
c) identify applications which use your contracts so you can trace the illicit behaviour/content.
a) in my mind is simple and you guys already probably have it or can be added, b and c are potentially tricky, depends on the inner workings of TF.
Potentially you could just ban all contract currently on your server, and if they displace to other servers, while we play a game of whack-a-mole after a few “local bans” the suspicious contract could be identified. So a simple solution would be “button” to: publish a complaint against all contracts on my machine at the time of x(time of the infraction you got, usually there is a timestamp, but even “right now” will probably also be okay?), and ban them from being used on my machine(s) (probably people will want to ban a contract on a single machine but across all their machines, so it won’t just migrate to a 2nd machine in the cluster).
This could be implemented so that the contracts migrate gracefully?(depends on volume obviously), but they all get a +1 on the ban counter, the farmer can truthfully say he did all what he could do to fix the problem (usually you have to say you made sure the issue will not repeat when you get such an email), and if the issue happens to a few more farmers with the same contract… we’ll quickly identify the bad one, as most likely all contracts would go to different machines, so chances of the same contracts getting blacklisted again are slim. Now certainly, with age certain contracts might accumulate a number of these “infractions”, but with time one can probably identify the real problematic ones as they will get. e.g. 1 ban/month, vs 1 ban per year for the accidental ones.
Then again, the farmer could have control to say how comfortable is he with the # of bans to applications per e.g. month. E.g. 0.25 would be one ban per quarter.
Maybe this (probably a bit more fleshed out) could work?
I know this goes against what @heaps said, and what I also said, but assuming it’s difficult to identify offending contracts (which it probably is), this whack-a-mole-counter could be a gray solution.
Depending on how difficult of an implementation would we like it to be, this could be paired with signed/allowed/denied contracts so if you know certain workloads are okay(your own?), you could ban selectively. In any case something to think about. Thoughts?