Юридические последствия запуска узла Swarm на VPS/сервере [закрыто]

Я полностью поддерживаю Swarm и хотел бы стать его частью и предоставить узел/ферму для сети Swarm, поэтому мои вопросы.

1. Хотя многие провайдеры VPS согласны с тем, что вы используете узел Ethereum, многим не понравится идея хранения неизвестных файлов на одном из их серверов так же, как им иногда не нравятся торренты или другие технологии p2p. Будет ли запуск узла Swarm столь же спорным для провайдеров серверов, как запуск узла выхода TOR? Будут ли они генерировать жалобы на злоупотребления или уведомления dmca, с которыми придется иметь дело операторам узлов Swarm?

2.- В настоящее время Storj напрямую обращается с жалобами на нарушение авторских прав. https://storj.io/terms-of-use.html (см. статью 6). Стоит ли ожидать чего-то подобного от Swarm?

Либо слишком много возможных ответов, либо хорошие ответы будут слишком длинными для этого формата. Пожалуйста, добавьте детали, чтобы сузить набор ответов или выделить проблему, на которую можно ответить в нескольких абзацах.
вопрос переформулирован.
Похоже, вы задаете четыре вопроса (1) имеют ли узлы SWARM право на Safe Harbor в соответствии с DMCA и чем они юридически отличаются, скажем, от TOR или freenet ? (2) технически возможно ли, чтобы узлы SWARM отказывались хранить или передавать определенный контент. (3) возможно ли иметь какой-то белый список/черный список/список DMCA, на который узлы могли бы дополнительно подписаться. (4) есть ли планы по внедрению такой системы.
Если вопрос слишком широк, то он слишком широк. Пожалуйста, модераторы, удалите вопрос, так как я не могу этого сделать, потому что у него есть ответы.
@wacax, тем не менее, это открытый вопрос, вы не просите Джастина, подходящего для формата QA. Может быть, вы можете использовать Reddit, потому что они поощряют это. ТА.

Ответы (1)

См. пункт 4 в приведенных ниже целях (имейте в виду, что файлы хранятся в виде фрагментов на нескольких узлах, фрагменты делятся и хранятся на многих узлах:

куски данных (макс. 4 КБ), основная единица хранения и поиска в рое

Цели Swarm влекут за собой следующие требования к дизайну:

1) распределенное хранилище, инклюзивность, длинный хвост степенного закона

2) гибкое расширение пространства без аппаратных инвестиционных решений, неограниченный рост

3) нулевое время простоя

4) неизменное, не поддающееся подделке, проверяемое, но правдоподобно отрицаемое хранилище

5) отсутствие единой точки отказа, отказоустойчивости и устойчивости к атакам

6) устойчивость к цензуре, общедоступная постоянная публичная запись

7) устойчивость за счет системы мотивации

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

9) эффективное использование блокчейна протоколом роевого учета

10) гарантированное хранилище на основе залога [запланировано для POC 0.4 ко второму кварталу 2017 года]

Вышеизложенное взято из вики Swarm, эта информация не должна рассматриваться как юридическая консультация!!!