Един ден реших да напиша приложение, което да селектира музика за мен, за да я слушам вкъщи, навън, по време на тренировки и т.н. И да работи всичко в поток, с минимално мое участие. Обмислих архитектурата, начертах прототип и в крайна сметка се сблъсках с един "малък проблем".
Но не беше ясно откъде да взема самите аудиофайлове. В този момент ВКонтакте вече затвори API-то си, на големите музикални портали също нямаше нищо, дори песните се доставяха на парчета, за да не могат да бъдат парснати. Останаха само някакви отделни сайтове-однодневки с тон реклама и различни боклуци, всякакви съмнителни програми-грабъри и други "мръсни" варианти. В обобщение, нямаше нито едно наистина добро решение. Може, разбира се, да купиш абонамент за някаква Яндекс музика или подобно. Но отново, никъде няма открито публично API и нямаш достъп до музиката програмно. Няколко големи компании по същество ограничиха достъпа на другите до музиката. Защо така се случи? Като задълбах, стана ясно, че основният проблем е в авторските права. Текущото решение с абонаментите удовлетворява много търговски автори на музикални произведения и самите компании. В същото време некомерсиалната и условно-комерсиалната музика също попада в общ списък. Плащаш или за всичко, или не слушаш нищо.
И започнах да мисля какво да правя с всичко това. Как може да се организира свободното разпространение на музика? Какво бих направил, ако самият аз създавах музика и исках да печеля от това? Харесваше ли ми, ако песните ми започнат да се разпространяват по пиратски начин? Какво е алтернативното решение?
В крайна сметка се изправиха пред две основни проблема, които трябва да се решат:
- Организация на свободното разпространение на музика по удобни за повечето хора методи, включително програмни.
- Предложения на алтернативи за създателите на музика, за да печелят.
Глобално децентрализирано хранилище за музика.
Първоначално опитах да намеря съществуващи решения и да създам всичко на базата на това. След известно време на търсене, първоначално ми хареса . Започнах реализирането на идеята си, но след известно време открих няколко критични проблема в това решение:
- IPFS — хранилище за всичко и вся. Има и изображения, и музика, и видео и какво ли не. Всъщност, огромна такава планетарна „боклук“. Затова, когато стартираш твоя възел, веднага получаваш огромна натовареност. Машината просто се мъчи от болка.
- Някакъв недовършен механизъм за събиране на „боклук“. Не знам как е сега, но в момента, ако в конфигурацията напишеш, че искаш да ограничиш хранилището до десет гигабайта данни, това нямаше да означава нищо. Хранилището нарастваше, игнорирайки много конфигурационни параметри. В крайна сметка, трябваше да имаш огромен запас от твърд диск, докато IPFS измисли как да изтрие ненужното.
- В момента на използване на библиотеката (не знам как е сега), клиентът не беше реализирал таймаути. Изпращаш заявка за получаване на файл и ако го няма, просто оставаш в застой. Разбира се, хората измислиха всякакви обходни пътища, които отчасти решаваха проблема, но това бяха импровизации. Такива неща трябва да бъдат вградено.
Имаше и много малки проблеми, впечатлението ми беше категорично: това не може да се използва за проект. Продължих да търся хранилище, проучвах различни опции, но не намерих нищо подходящо.
В крайна сметка реших, че е време да пробвам да напиша децентрализирано хранилище сам. Нека то да не претендира за междупланетно, но ще решава конкретно поставената задача.
Така получихме , , , , .
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) има всички необходими методи за получаване и обработка на тагове.
Пример за работа с хранилището чрез клиент може да се види в .
Всички изброени слоеве са самодостатъчни и могат да бъдат използвани отделно като по-ниски слоеве за други проекти. Например, вече сега има идея да се направи слой за съхранение на книги.
museria-global — това е вече конфигуриран git-репозиторий за стартиране на собствен възел в глобалната мрежа за музика. Клонирате, npm i && npm start и по същество е всичко. Можете да настроите по-задълбочено, да стартирате в Docker и т.н. Подробна информация има на .
Когато хранилището се обновява, трябва да обновите и узела си. Ако се променя основният или минорният номер на версията, това действие е задължително, в противен случай старите узли ще бъдат игнорирани от мрежата.
Можете да работите с песните ръчно или програмно. Всеки узел стартира сървър за различни задачи. Включително, при посещение на основната крайна точка, ще получите интерфейс за работа с музика. Например, можете да отидете на (връзката може да не е актуална по-късно, входните узли могат да бъдат получени също в , или можете да видите обновления на GitHub).
По този начин можете да търсите и изтегляте песни в хранилището. Изтеглянето на песни може да се извършва в два режима: обикновен и модериран. Вторият режим означава, че работата се извършва от човек, а не от програма. И ако поставите тази галочка при добавяне, ще трябва да решите капча. Песни могат да се добавят с приоритети -1, 0 или 1. Приоритет 1 може да бъде зададен само в модериран режим. Приоритетите са необходими, за да може хранилището по-ефективно да взема решение какво да прави, когато се опитвате да замените вече съществуваща песен с нова. Колкото по-висок е приоритетът, толкова по-големи са шансовете да презапишете съществуващия файл. Това помага в борбата със спама и увеличава качеството на зарежданите песни.
Ако започнете да добавяте песни в хранилището, опитайте се да прикрепяте и изображения (обложки), макар че това поле не е задължително. В 99% от случаите първите картинки в Google по имената на песните са обложки на албуми.
Как технически става добавянето на файлове, накратко:
- Клиентът получава адрес на свободен узел, който за известно време ще стане координатор.
- Стартира се функцията за добавяне на песен (от човек или код), изпраща се заявка за добавяне на крайната точка на координатора.
- Координаторът изчислява колко дубликати трябва да се запазят (конфигурируем параметър).
- Търсят се най-подходящите узли за запазване.
- Файлът, директно, отива на тези узли.
Как технически става получаването на файлове:
- Клиентът получава адрес на свободен узел, който за известно време ще стане координатор.
- Стартира се функцията за получаване на песен (от човек или код), изпраща се заявка за получаване на крайната точка на координатора.
- Координаторът проверява наличието на връзка в кеша. Ако такава съществува и работи, веднага се връща на клиента, в противен случай се запитват узлите за наличност.
- Файл се получава по линк, ако е намерен.
Алтернативи за музикални творци
Винаги съм се интересувал как може да се оцени обективно цената на много творчески произведения? Защо, например, човек продава музикалния си албум за 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
Моите контакти:
Източник: habr.com
