Hmm… it looks like there may have been an infrastructure issue, but this Space might be stopped for a separate reason too
:
I checked the Space runtime state, and there is a more specific clue than the 503 itself:
{
"stage": "PAUSED",
"hardware": {
"current": null,
"requested": "cpu-basic"
},
"errorMessage": "Flagged as abusive"
}
So I would stop treating this as an ordinary Docker/build failure for now. The useful next step is probably to ask Hugging Face to review the flag, rather than repeatedly trying Restart / Factory Rebuild.
I would keep the Space URL, the Request ID you already posted, and the runtime JSON above, and send them to website@huggingface.co. In a very recent similar Forum case, HF staff specifically asked the user to email that address so they could take a closer look.
If this turns out to be a moderation decision that needs to be contested, HF’s Content Policy also lists safety@huggingface.co for moderation-related complaints/appeals.
The important limitation is that the runtime response does not expose the actual reason behind the flag. So I would not assume from this alone that Telegram, Stremio, a proxy feature, or any particular part of the application is the cause.
Why this may be separate from the infrastructure issue
The original symptoms — PAUSED, Restart/Factory Rebuild returning 503, and no new logs — can certainly look like a control-plane problem.
But there are public cases where essentially the same visible symptoms turned out to be a Space-level flag. For example, in this case, the runtime API eventually exposed:
Flagged as abusive, reason trojan proxy on :7860
That does not mean your Space has the same reason; your API response does not say that. It only shows why the runtime state is more useful here than the generic 503.
So I would handle the flag first. If HF clears it and the Space still cannot start, then it makes sense to return to normal Docker/build/runtime debugging.
A practical decision tree
A more specific reason / detector / rule is visible
|
+--> Include that exact signal in the HF support request
and investigate that component first.
Only "Flagged as abusive" is visible
|
+--> Ask HF to review the exact reason.
|
+-- HF says false positive
| +--> Review / unflagging is the relevant path.
|
+-- HF identifies a specific feature or behavior
| +--> Change or separate that component.
|
+-- Flag is cleared, but the Space still fails
+--> Return to ordinary build/runtime debugging.
I would avoid deleting random files or repeatedly redeploying similar copies before knowing the reason, because that provides little diagnostic information.
Also, I would not read the Content Policy as saying that any application with proxy/relay functionality is automatically prohibited. The policy specifically mentions proxies/tunnels in the context of using them to bypass platform restrictions. The exact reason for this Space’s flag still needs HF-side confirmation.
If HF does identify one particular relay/networking component as the problem, that still would not necessarily mean abandoning the whole Telegram/Stremio project; separating only that component onto a more suitable host may be an option.