Museria — децентрализованное хранилище музыки

    image

    Собрался я однажды написать приложение, чтобы отбирать музыку для себя и слушать дома/на улице/тренировках и.т.д. И чтобы все это работало в потоке, с минимальным моим участием. Придумал архитектуру, набросал прототип и в итоге столкнулся с одной “небольшой проблемой”.

    А непонятно откуда брать сами файлы песен. К этому моменту вконтакте уже закрыла api, на крупных музыкальных порталах тоже все глухо, даже песни отдаются кусками, чтобы не парсили. Оставались только какие-то отдельные сайты-однодневки с тонной рекламы и всякого мусора, всякие сомнительные программы-грабберы и прочие “грязные” варианты. В общем, ни одного действительного хорошего решения. Можно, конечно, купить подписку на какую-нибудь яндекс музыку или подобное. Но опять же, там нигде нет открытого публичного api и у тебя нет доступа к музыке программно. Несколько крупных компаний, по сути, ограничили остальным доступ к музыке. Почему так произошло вообще? Копнув глубже, стало понятно, что основная проблема в авторских правах. Текущее решение в виде подписок устраивает многих коммерческих авторов музыкальных произведений и эти самые компании. При этом некоммерческая и условно-коммерческая музыка тоже попадают в общий список. Ты либо платишь за все, либо не слушаешь вообще ничего.

    И я начал думать что с этим всем делать. Как можно организовать свободное распространение музыки? Что бы я делал, если бы сам занимался созданием музыки и хотел бы зарабатывать на этом? Понравилось бы мне, если бы мои песни начали распространять пиратским образом? Какое вообще есть альтернативное решение?

    В итоге сложились две основные проблемы, которые нужно решать:

    • Организация свободного распространения музыки удобными для большинства людей методами, в том числе программными.
    • Предложение альтернатив создателям музыки для заработка

    Глобальное децентрализованное хранилище музыки


    Изначально я попробовал найти уже существующие решения и создать все на базе этого. После некоторого времени поисков, первым приглянулся ipfs. Я начал реализацию своей идеи, но через некоторое время обнаружил несколько критичных проблем в этом решении:

    • Ipfs — хранилище для всего и вся. Тут и изображения и музыка и видео и все что угодно. В общем-то большая такая планетарная «помойка». Поэтому когда ты запускаешь свой узел, то сразу получаешь огромную нагрузку. Машина просто корчится от боли.
    • Какой-то недоделанный механизм сборки «мусора». Не знаю как с этим сейчас, но в тот момент, если ты в конфиге прописывал, что хочешь ограничить хранилище десятью гигабайтами данных, то это не значило ничего. Хранилище разрасталось, игнорируя многие параметры конфигурации. В итоге, нужно было иметь огромный запас жесткого диска, пока ipfs сообразит как сбросить ненужное.
    • На момент использования библиотеки (не знаю как с этим сейчас), у клиента не были реализованы таймауты. Посылаешь запрос на получение файла, и если его нет, то просто висишь. Конечно, люди придумали всякие обходные пути, которые отчасти решали проблему, но это было костыли. Такие вещи должны быть из коробки.

    Еще было много мелких проблем, впечатление сложилось тогда однозначное: это нельзя использовать для проекта. Я продолжил поиски хранилища, изучал разные варианты, но так и не нашел ничего подходящего.

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

    Так и получились spreadable, storacle, metastocle, museria, museria-global.

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

    Подробно я spreadable в этой статье не буду описывать, лучше напишу отдельную как-нибудь. Тут лишь отмечу некоторые особенности:

    • Работает через http/https.
    • Можно создавать отдельную сеть под конкретную задачу, что существенно снизит нагрузку на каждый отдельный проект, чем если бы они все были в одной сети.
    • Изначально продуман механизм с таймаутами и другими мелочами. И это работает для всех методов и в клиенте и в узле. Можно гибко управлять параметрами из своего приложения.
    • Библиотека написана на nodejs. Проблемы с производительностью стека компенсируются децентрализованной природой. Нагрузку можно «размазать», увеличением количества узлов. Взамен много плюсов: огромное сообщество, простота и удобство работы, изоморфный клиент, отсутствие внешних зависимостей и.т.д.

    storacle — это слой, наследующийся от spreadable, который позволяет хранить в сети файлы. Каждый файл имеет свой хэш по содержимому, по которому его позже и можно получить. Файлы не делятся на блоки, а хранятся целиком.

    metastocle — слой, наследующийся от spreadable, который позволяет хранить в сети данные, но не файлы. Интерфейс похож на nosql базы данных. Можно, например, добавить файл в storacle, получить его хэш и записать в metastocle с привязкой к чему-либо.

    museria — наследуется от storacle и metastocle. Этот слой непосредственно отвечает за хранение музыки. Хранилище работает только с mp3 файлами и id3 тэгами.

    В качестве «ключа» к песне используется ее полное название в виде Исполнитель (TPE1) — Название (TIT2). Например:

    • Brimstone — The Burden
    • Hi-rez — Lost My Way (feat. Emilio Rojas, Dani Devinci)

    Максимально подробно узнать как формируются названия песен можно тут. Надо смотреть функцию utils.beautifySongTitle().

    Совпадением по ключам считается определенный в настройках узла процент. Например, значение 0.85 означает, что если функция сравнения ключей(названий песен) обнаружила схожесть более 85%, то это одна и та же песня.

    Алгоритм определения схожести там же, в функции utils.getSongSimilarity().

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

    Пример работы с хранилищем через клиент можно посмотреть в readme.
    Все вышеперечисленные слои являются самодостаточными и могут быть использованы отдельно как более низкие слои для других проектов. Например, уже сейчас есть мысль сделать слой для хранения книг.

    museria-global — это уже сконфигурированный гит-репозиторий для запуска собственного узла в глобальной сети музыки. Клонируете, npm i && npm start и по сути все. Можно настроить более детально, запустить в докере и.т.д. Подробная информация есть на гитхабе.

    Когда репозиторий обновляется, нужно обновить и свой узел. Если меняется мажорный или минорный номер версии, то это действие обязательно, иначе старые узлы будут игнорироваться сетью.

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

    Так вы можете искать и загружать песни в хранилище. Загрузка песен может проходить в двух режимах: обычный и модерируемый. Второй режим означает, что работу ведет человек, а не программа. И если вы ставите эту галочку при добавлении, то нужно будет решить капчу. Песни можно добавлять с приоритетами -1, 0 или 1. Приоритет 1 можно ставить только в модерируемом режиме. Приоритеты нужны, чтобы хранилище эффективнее принимало решение, что делать когда вы пытаетесь заменить уже существующую песню новой. Чем больше приоритет, тем больше шансов, что вы перезапишете существующий файл. Это помогает бороться со спамом и увеличивает качество загружаемых песен.

    Если вы начнете добавлять песни в хранилище, старайтесь прикреплять и изображения (cover), хоть это поле и не обязательное. В 99% случаев первые же картинки в гугле по названиям песен это каверы альбомов.

    Как технически происходит добавление файлов, в двух словах:

    • Клиент получает адрес свободного узла, который на некоторое время станет координатором.
    • Триггерится функция добавления песни (человеком или кодом), происходит запрос на добавление на эндпоинт координатора.
    • Координатор вычисляет, сколько дубликатов нужно сохранить (конфигурируемый параметр).
    • Ищутся наиболее подходящие узлы для сохранения.
    • Файл, непосредственно, уходит на эти узлы.

    Как технически происходит получение файлов:
    • Клиент получает адрес свободного узла, который на некоторое время станет координатором.
    • Триггерится функция получения песни (человеком или кодом), происходит запрос на получение на эндпоинт координатора.
    • Координатор проверяет наличие ссылки в кэше. Если такая есть и она рабочая, то сразу возвращается клиенту, иначе опрашиваются узлы на предмет наличия.
    • Происходит получение файла по ссылке, если таковая нашлась.

    Альтернативы для создателей музыки


    Меня всегда интересовал вопрос, как вообще можно оценить объективно стоимость многих творческих произведений? Почему, например, человек выставляет свой музыкальной альбом за 10$? Или за 20$ или за 100$. Где алгоритм? Когда, например, мы говорим о каком-то физическом продукте, или даже многих видах услуг, то мы можем как минимум посчитать себестоимость и исходить из этого.

    Окей, допустим 10$ поставили. Очень уж ли это эффективно? Допустим я послушал альбом где-нибудь или песню оттуда и решил отблагодарить. Но по моим ощущениям и собственным возможностям 3$ — мой потолок. И как тут быть? Скорее всего я просто не сделаю ничего, как и большинство людей.

    Выставляя какую-то фиксированную цену за творческий труд, ты просто ограничиваешь себя, не даешь бОльшому числу людей отправить тебе меньшие деньги, которые в сумме могут быть внушительнее, чем у тех кто купят по установленной тобой цене. Мне кажется творчество — это именно та сфера, где в первую очередь должны рулить донаты. Для этого нужно:

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

      Допустим, ссылка примерно такая:

      http://someartistsdonationsite.site/category/artist?external-info

      Если сузить до музыкантов, то:

      http://someartistsdonationsite.com/music/miyagi?song=blabla

      Исполнителю нужно верифицировать свой никнейм и прикрепиться за ним.

      В клиент museria добавляем функцию генерации подобной ссылки, и все проекты использующие хранилище, могут расположить на своих сайты/приложениях кнопки для донатов с этими ссылками рядом с песнями. Пользователи имеют возможность очень быстро и просто сделать донат. Естественно, этот подход можно использовать в любом проекте и категории творчества, не только через хранилище.

    Зачем, именно тебе, музыкальное хранилище, и как в этом можно участвовать


    • Если ты работаешь над проектом, связанным с музыкой, либо планируешь такой создать, то ради этого все и было задумано. Ты можешь использовать museria для хранения и получения песен, увеличивая поток песен в сети. Если, при этом, у тебя есть возможности поднять и удерживать хотя бы один собственный узел, то это будет наилучшим вкладом в развитие сети.
    • Возможно ты готов взять какую-то иную роль на себя: помочь с кодом, или заполнять и модерировать базу, распространять информацию о проекте своим знакомым и.т.д.
    • Может быть тебе понравилась идея и ты готов помочь материально, чтобы это все жило и развивалось. Чем больше узлов, тем больше песен.
    • Или тебе просто в какой-то момент понадобится найти и скачать песню. Ты сможешь сделать это очень просто, например, через телеграмм бота.

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

    Посмотреть информацию об узле извне: количество песен, свободного места и.т.д., можно по ссылке вида http://node-address/status или http://node-address/status?pretty

    Мои контакты:

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 28

      0
      создать некий глобальный сайт, куда можно донатить за творчество с помощью авторских ссылок.

      Bandcamp?

        0
        Не совсем. Нужен лишь сайт для верификации творчеких псевдонимов и принятия донатов через генерируемые ссылки.
        0
        Если бы всё было так просто «автор» < — «слушатель».
        В реальном мире этот путь много сложнее и разветвлённее:
        Автор — исполнитель — музыканты — студия звукозаписи — продюсер — «лейбл» — маркетинг — радио — каналы распространения и раскрутки… слушатель.
        На каждом этапе существуют договорённости (фиксированная сумма, % от выручки, бартер в конце концов) и кто кому платит тоже не всегда очевидно. Далеко не всю сумму получает правообладатель.
        Возможно в идеальном мире (скажем блокчейна) и можно было настроить автоматические отчисления от каждого доната всем участникам цепочки по заранее оговоренным договоренностям, но это фантастика.
        И да, автор (правообладатель) бы и рад получать деньги напрямую от потребителя, но без большинства участников этой цепочки произведение просто не дойдет до слушателя (в нужном объеме).

        P.S. а что будет, если все ноды заполнятся? Кто платит за эти ноды? Имхо, очень быстро все забьется «мусором» (да, даже если и «полезным», уже чего, а музыки в мире — *лиарды песен).
        И да, что вы там делаете на данном этапе с жалобами правообладателей? Имхо, подсудное дело это — распространение пиратского контента, пусть даже и децентрализовано. Хотя, у Вас, судя по всему, файл лежит полностью на одной ноде, т.е. уже отвертеться, что «часть контента не может быть рассмотрена как целое произведение и потому никаких претензий» — не прокатит… И да, ip ноды видно явно — стрёмно же.
          0
          Спрятали бы ноды хоть за Cloudflare, хоть какая-то защита (плюс ssl бесплатно).
          А вообще, мне кажется, у Вас получился CDN, а не распределенное хранилище.
            0
            В том и смысл, чтобы упростить все это, сделать границу между автором, слушателем и его донатом минимальной. В идеале везде, где ты будешь слушать какую-то песню, рядом будет кнопочка доната. Нужно лишь, чтобы большинство следовало этому алгоритму.

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

            По поводу мусора. Сеть настроена на циркуляцию. Если места не хватает, то наименее приоритетные и редкоиспользуемые песни удаляются, чтобы освободить место. Даже если будет всего один мой узел (200gb), он может обсуживать около 20000 песен.
            20 узлов — это уже 400000 песен за вычетом копий.

            По поводу открытого ip. Сейчас работает тестовая сеть, пока не сильно заморачиваюсь с блокировками возможными. В любом случаи в качестве адреса может быть любой домен в итоге, и сеть автоматически перерегистрирует узел если надо. А поводу механизмов скрытия можете написать мне в телеграмм или хотя бы скинуть ссылки интересные. Я рассматриваю возможные варианты.

              0
              Правообладателям не нужно уменьшать эту цепочку, т.к. в ней не только нахлебники, но и полезные для всего процесса звенья. Которые хотят, внезапно, % от продаж.

              Нода упала -> весь контент с неё пропал из сети?

              Т.е. по сути Вы сделали такой себе API, который шлет всем нодам find и возвращает список ссылок? Почему по имени, а не скажем, по MusicBrainz ID. И что с дубликатами все-таки? Они могут быть как по имени, так и по хешу. Вы хеш, кстати, вместе с ID3 тэгами берете? (Пардон, в исходники не смотрел). Если да, то можно залить абсолютно идентичные файлы с отличием в одном символе в комментарии в ID3. И что с вариантами одной песни в разном качестве, обрезанное, с рекламой? Это будут все разные песни? Т.е. при поиске этой песни выдаст десяток ссылок на нее и куда кликать? В итоге получится такая же мусорка, как сейчас DirectConnect
                0
                Процент можно поделить между всеми же. Внезапно, даже создатель этого глобального сайта может себе брать небольшую комиссию :)

                Нода упала — контент пропал из сети, но не узла. Если узел вернется, то все восстановится.
                Если узлов больше 1, то у всех песен будет как минимум один дубликат. Чем больше узлов, тем больше дубликатов. Кол-во дубликатов настраивается, сейчас стоит как корень из размера сети. Поэтому если в сети 9 узлов, скажем, то 2 любых могут падать, ничего не поменяется. Тут главное — постоянная циркуляция песен. Тогда все будет ок.

                Вы сделали такой себе API, который шлет всем нодам find и возвращает список ссылок

                Если очень упростить, то да. Но роль кэша тут велика. Если песни часто тянутся, то в основном ссылки будут приходить без обхода сети. Ты не можешь получить несколько разных ссылок с разными вариантами. Приходит ссылка с наибольшим совпадением.

                По поводу хэшей, ключей и названий.
                Хэш тут мало роли играет, именно в музыкальном хранилище. Ключом является название песни, потому что это убивает сразу всех зайцев: дает уникальность песне, обладает человекоперевариваемым видом, легко копируется и.т.д.
                Единственное узкое место в этой схеме то, что название может не соответствовать содержанию. Но в ближайшем будущем это, впринипе, кажется нерешаемая проблема.
                Я решил удерживать качество путем разделения людей от роботов. Человеческий контент приоритетнее. Поэтому если ты, например, увидел не очень качественную или левую песню в хранилище, то можешь перезаписать ее в режиме модератора. А робот не может (в теории).

                Тема спама в открытых сетях это одно из самых узких мест.
            0
            .
              +1
              nodejs и вообще веб стек здесь совершенно не к чему.
                +2
                1. есть уже распределённое на весь мир хранилище качественной музыки — торренты. Осталось написать программу для анонимного поиска и скачивания с любого компа планеты.
                2. лучше один раз скачать и слушать с винта/флешки чем перегружать сеть передачей одних и тех же данных
                3. с оплатой проблемы — где гарантия что платишь не мошеннику? вот при оплате через госуслуги я бы не сомневался, остальные сайты не вызывают доверия
                  0
                  С проектом pathefone знакомились? Как оно в сравнении с вашим.
                    0
                    Да, это один из проектов, который навел на мысли и вдохновил на создание. Но как я уже писал в статье, у ipfs слишком много минусов. Можно сказать museria — более функциональная, гибкая и удобная реализация этого всего.
                    0
                    Тест буквально из печи:
                    Залил песенку на ноду, начал искать через бота, нашел, однако неитуетивно понятно то, что композиции, имеющие больше одного слова нужно вбивать в кавычках — не все ж программисты). Бот отдал ссылку на скачивание, которая не работает.
                    В остальном затея классная, только как бороться с пиратами?
                      0
                      Название песни напишите, чтобы проверить что к чему.
                      С какими пиратами бороться собрались? Пираты с пиратами не борятся))

                      Можете в телеграмм написать по поводу песни, если что.
                      0
                      Про борьбу со спамом вообще непонятно. А это, IMHO, самый сложный момент во всём проекте.
                      Что помешает злоумышленнику заменять роботом песни на них же со вставками «покупайте натяжные потолки только в нашем казино»?
                        0

                        Я выше уже писал про это. Песни можно сохранять с приоритетами и в режиме модерации. Только человек может сохранить с наивысшим приоритетом, так как в этом режиме надо проходить капчу. То есть если человек добавил песню x с приоритетом 1(максимум), то робот уже не может перезаписать ее, его максимум 0. Только другой человек. Это придумано специально, чтобы система стремилась быть заполненной, в итоге, людьми. Поспамить может и человек, но надо постоянно решать капчу. И для этого случая тоже есть решение, которое возможно будет введено в будущем.

                          0
                          Если я правильно понял, то и приоритет, и капча присущи клиенту, а не сети в целом. Тогда, если я напишу свой клиент, то я смогу спамить с желаемым приоритетом и без капчи.
                            0
                            Нет, приоритет и капча реализованы на уровне сети(серверов), а не клиента. А вот как я реализовывал капчу для децентрализованной сети, это уже отдельную статью писать надо )
                              0
                              Ага, надо :)
                              Хотя всё равно всё не гладко. Даже если спамеру не удастся полностью автоматизировать процесс, то он может просто 1000 раз вводить капчу. Он в этом материально заинтересован, а тот, кто исправляет результаты его действий, — нет.
                            0
                            5$ за тысячу капчей: платишь на специальном сервисе — китайцы решают.
                              0

                              Это все понятно, но проспамить можно все что угодно. Я могу сейчас сесть и добавить кучу левых песен вконтаке, не соответствующих соодержанию, например. Но все же работает в целом. Такие моменты решаются уже другими инструментами и по мере их появления: контроль ip адресов, ограничения по кол-ву действий за время, модерация и.т.д.

                                0
                                Это всё плохие решения (IP адреса — а что, если адрес за NAT, и там 1000 пользователей? да и вообще, глядя в будущее, к IPv4 уже как-то не очень правильно привязываться. Модерация предполагает централизацию, которая в децентрализованной сети нехорошо выглядит).

                                Видимо, тут должно быть что-то такое:
                                — на одно имя объекта должно быть можно повесить много хэшей
                                — при этом хэш содержимого должен сопровождаться «подписью» загрузившего
                                — в клиенте должны вестись локальные чёрные и белые списки подписей загрузивших. В чёрный список загрузивший попадает по нажатию спец кнопки. В белом хранится некий счётчик количества «успешно» прослушанных композиций. Списки определяют, какой именно хэш из кучи навешенных на нужное имя будет играться.
                                  0

                                  Примерно в этом духе я уже планировал реализовать систему распознавания фейковых трэков. Это пока требует более тщательного анализа.

                          0
                          Осталось завернуть это в сеть Yggdrasil и ваш IPv4 в безопасности ;)
                            0
                            Интересная идея, но, на мой взгляд, сыровата. Тут бы блокчейн пригодился, в плане платежного средства. Навскидку:

                            1. Клиент отправляет запрос на поиск песни. К примеру, поиск по её хешу.
                            2. Получает список серверов и метадату — размер файла, стоимость, которую нужно будет заплатить за получение.
                            3. Клиент делает запрос самому дешевому серверу, вместе с ним отправляет нужное количество денег.
                            4. Сервер отдает песню, получает за это вознаграждение.

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

                            На самом деле идея настолько очевидная, что я удивлюсь, если её еще не реализовали.

                            Ну и с копирайтом можно что-то придумать. К примеру, кто-то заявляет, что имеет авторское право на хеш Х. Он предоставляет документы или другие доказательства. Если консенсус достигнут — с каждого запроса ему будет перечисляться процент.
                              0

                              Такая мысль была изначально, они и сейчас обдумывается, но вперед пока выходит более простая альтернатива: собирать все донаты и инвестиции и какую-то часть распределять между владельцами узлов. Дело в том что вариант с криптой и плата за скачивание/хранение конечными пользователями может тупо убить спрос.

                              0
                              Касательно раздела «Альтернативы для создателей музыки»:
                              об оплате труда композиторов думало множество совсем неглупых людей. Возможно != будет. Текущие цены в 5-10$ установлены именно исходя из текущих реалий. Плюс не забывайте, что микротранзакции сами по себе дорогое удовольствие, и пока адекватного решения этой проблемы нет, единственный вариант – большая аудитория, донатящая каждый день, как в ММО, например; очевидно, что за новый альбом каждый день одни и те же люди платить не будут.
                              Продюсеры и прочие «лишние» с точки зрения потребителя люди в цепочке всё это уже давно посчитали, прогнали на моделях и установили цены с точностью до цента, всеми силами поддерживая тонкий баланс существующей системы. При этом, если систему развалить, совсем не факт, что потребителю станет лучше – всё значительно сложнее.

                              Тем не менее, сам факт создания вами такой системы — это хорошо, ИМХО. Просто не забывайте, что важными для многих вопросами занимаются и другие, совсем неглупые, люди. И если их решение кажется вам странным и неэффективным, однако система при этом работает – это повод задуматься.
                                +1

                                Вы абсолютно правы, только есть один нюанс. Я не из соображений самого умного предложил такое решение. Фиксированная и устанавливаемая цена нам привычна, это да. Потому что тысячи лет люди продавали и покупали товары и услуги, когда интернета еще не было. Возможности доната были крайне ограничены. Сейчас же это становится очень удобным и эффективным. Появились криптовалюты, микротранзакции тоже становятся эффективнее. В общем поезд движется куда-то в эту сторону, могут произойти большие изменения, и я разделяю взгляды таких людей.

                              Only users with full accounts can post comments. Log in, please.