Насчёт доверия это не так критично как кажется. Сервисы pastebin, sprunge.us, ix.io прекрасно используются, просто, конечно, никто не пересылает через них чувствительную информацию.

Вообще, этот отдельно взятый сервис никакого принципиального значения не имеет. Это просто пример сервиса для консоли (для человека, работающего в консоли). Можно взять для примера какой-нибудь другой, давайте возьмём wttr.in.

Мне кажется, что использование TCP-интерфейса (netcat) наряду с HTTP очень важно для таких сервисов. Выбрасывать HTTP неправильно, но и ограничиваться HTTP тоже нельзя.

Другое дело, что при использовании голого TCP встают такие вопросы, как:

* как передавать параметры;
* как передавать заголовки;
* как передавать виртуальные адреса.

Эти все вопросы открыты.

Например, с помощью http всё это сделать легко:

  curl ru.wttr.in/Москва

вы получаете прогноз погоды по москве на русском языке.

Как это сделать с помощью netcat?

  echo Москва | nc wttr.in 1024

Неплохо, но нет языка.

Тогда так:

  echo ru.wttr.in/Москва | nc wttr.in 1024

получается по сути реализация HTTP-протокола заново.

Моё решение здесь: отказаться от передачи параметров (использовать дефолтные):

   echo Москва | nc wttr.in 1024

или, для определения положения по IP-адресу,

   nc wttr.in 1024

(кстати, вот вам интересная загадка: как на серверной стороне распознать,
собирается клиент передавать ему какие-то данные или нет; грубо говоря
как сделать так чтобы оба вышепреведённых варианта работали).

TCP-вариант хорош (по сравнению с HTTP-вариантом) ещё и тем, что вообще не требует
никаких клиентов. То есть, работать будет и так:

    cat < /dev/tcp/wttr.in/1024

(пока что TCP-интерфейс ещё не реализован, поэтому тест этот не отработает).

Вообще, почему я об этом так много пишу (здесь в комментах и вообще), потому что считаю, что направление консольных сервисов незаслуженно забыто человечеством в настоящий момент, и у них есть потенциал