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

Един ден реших да напиша приложение, което да избира музика за мен, за да я слушам у дома, навън, по време на тренировки и т.н. Исках всичко това да работи автоматично, с минимално участие от моя страна. Намислих архитектура, набросах прототип и накрая се сблъсках с един "малък проблем".

Но не беше ясно откъде да взема самите файлове с песни. Към този момент ВКонтакте вече беше затворила 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 — това е вече конфигуриран git хранилище за стартиране на собствен възел в глобалната мрежа за музика. Клонирате, npm i && npm start и по същество това е всичко. Може да конфигурирате по-подробно, да стартирате в Docker и т.н. Подробна информация е налична на GitHub.

Когато репозиторият се обнови, трябва да обновите и възела си. Ако се променя основният или минорният номер на версията, това действие е задължително, в противен случай старите възли ще бъдат игнорирани от мрежата.

С песните може да се работи както ръчно, така и програмно. Всеки възел стартира сървър за различни задачи. Включително, при посещение на дефолтния крайна точка, ще получите интерфейс за работа с музика. Например, можете да посетите кореновият възел (линкът може да не е актуален по-късно, входните възли могат да бъдат получени също в Телеграма, или да видите актуализациите на GitHub).

Така можете да търсите и да качвате песни в хранилището. Качването на песни може да протича в два режима: обикновен и модериран. Вторият режим означава, че работата се ръководи от човек, а не от програма. И ако поставите тази отметка при добавяне, ще трябва да решите CAPTCHA. Песните могат да се добавят с приоритети -1, 0 или 1. Приоритет 1 може да се задава само в модерирания режим. Приоритетите са необходими, за да може хранилището по-ефективно да взима решения, когато се опитвате да замените съществуваща песен с нова. Колкото по-висок е приоритетът, толкова по-голям е шансът да презапишете съществуващия файл. Това помага за справяне с спама и повишава качеството на качваните песни.

Ако започнете да добавяте песни в хранилището, се опитайте да прикрепите и изображения (cover), въпреки че това поле не е задължително. В 99% от случаите първите картинки в Google по имената на песните са кавъри на албуми.

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

• Клиентът получава адрес на свободен възел, който за известно време ще стане координатор.
• Функцията за добавяне на песен (от човек или код) се задейства, извършва се заявка за добавяне на крайна точка на координатора.
• Координаторът изчислява колко дубликата трябва да се запазят (конфигурируем параметър).
• Намират се най-подходящите възли за запазване.
• Файлът директно се изпраща на тези възли.

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

• Клиентът получава адрес на свободен възел, който за известно време ще стане координатор.
• Функцията за получаване на песен (от човек или код) се задейства, извършва се заявка за получаване на крайна точка на координатора.
• Координаторът проверява наличието на линк в кеша. Ако такъв съществува и е работещ, се връща незабавно на клиента, в противен случай се запитват възлите относно наличността.
• Изтегляне на файл по предоставената линк, ако такъв съ exists.

Алтернативи за музикални творци

Винаги съм се чудил как може да се оценят обективно цените на много творчески произведения? Защо, например, човек слага музикалния си албум за 10$? Или за 20$ или 100$? Къде е алгоритъмът? Когато, например, говорим за физически продукт или много видове услуги, можем поне да изчислим разходите и да изходим от това.

Добре, да кажем, че цената е 10$. Наистина ли е ефективно? Да предположим, че съм слушал албум или песен и искам да покажа благодарност. Но според моите чувства и възможности 3$ е моят максимум. Какво да правя? Вероятно просто няма да направя нищо, както и повечето хора.

Определяйки фиксирана цена за творчески труд, ти просто се ограничваш, не позволяваш на повече хора да ти изпращат по-малки суми, които в крайна сметка могат да се окажат по-големи от тези на тези, които купуват на зададената от теб цена. Смятам, че творчеството е именно сферата, в която донатите трябва да бъдат основни. За целта е нужно:

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

  Да кажем, линкът изглежда по следния начин:

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

  Ако се фокусираме върху музикантите, то:

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

  Изпълнителят трябва да потвърди своя никнейм и да се свърже с него.

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

Защо, именно за теб, музикалното хранилище, и как можеш да участваш в това?

• Ако работиш по проект, свързан с музиката, или планираш да създадеш такъв, всичко това е замислено именно за теб. Можеш да използваш museria за съхраняване и получаване на песни, увеличавайки потока на песни в мрежата. Ако имаш възможността да създадеш и поддържаш поне един собствен възел, това ще бъде най-добрият принос за развитието на мрежата.
• Може би си готов да поемеш някаква друга роля: да помогнеш с кода, или да запълваш и модерираш базата, да разпространяваш информация за проекта на приятелите си и т.н.
• Може би ти хареса идеята и си готов да помогнеш финансово, за да може всичко това да живее и да се развива. Колкото повече възли, толкова повече песни.
• Или в определен момент просто ще ти потрябва да намериш и свалиш песен. Ще можеш да го направиш много лесно, например, чрез телеграм бот.

Проектът в момента е на най-началната си фаза. Стартирана е тестова мрежа, възлите могат да се рестартират често, да изискват актуализации и т.н. В случай на отсъствие на критични проблеми в рамките на оценъчния период, същата мрежа ще бъде трансформирана в основна.

Информация за възела извънредно: брой песни, свободно пространство и т.н., може да се види по връзка от вида http://node-address/status или http://node-address/status?pretty

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

• @ortex
• mywebstreet@gmail.com
• Група в телеграм на английски.
• И сайтът, благодарение на който всичко това се роди.

Източник: habr.com