Un día decidí escribir una aplicación para seleccionar música para mí y escucharlo en casa, en la calle, durante entrenamientos, etc. Y que todo funcionara de manera fluida, con mínima intervención de mi parte. Ideé la arquitectura, boceté un prototipo y al final me encontré con un "pequeño problema".
Y no estaba claro de dónde obtener los propios archivos de canciones. Para ese momento, Vkontakte ya había cerrado su API, y en los grandes portales musicales todo estaba igualmente cerrado, incluso las canciones se entregaban en partes para evitar que se raspeo. Solo quedaban algunos sitios de una sola vez llenos de anuncios y basura, programas de ‘grabbing’ dudosos y otras opciones ‘sucias’. En resumen, no había ninguna solución válida y buena. Por supuesto, podría comprar una suscripción a algún servicio de música de Yandex o similar. Pero nuevamente, no hay API pública abierta en ninguna parte y no tienes acceso a la música de forma programática. Varias empresas grandes, en esencia, limitaron el acceso a la música para los demás. ¿Por qué ocurrió esto? Al indagar más, se hizo evidente que el problema principal reside en los derechos de autor. La solución actual basada en suscripciones satisface a muchos creadores comerciales de obras musicales y a esas mismas empresas. Al mismo tiempo, la música no comercial y condicionalmente comercial también se incluyen en la lista general. O pagas por todo, o no escuchas nada.
Y comencé a pensar qué hacer con todo esto. ¿Cómo se puede organizar la distribución libre de música? ¿Qué haría si estuviera creando música y quisiera ganar dinero con ello? ¿Me gustaría si mis canciones comenzaran a distribuirse de forma pirata? ¿Qué solución alternativa existe?
En total, se formaron dos problemas principales que deben resolverse:
- Organización de la distribución libre de música por métodos convenientes para la mayoría de las personas, incluidas las soluciones programáticas.
- Propuesta de alternativas para que los creadores de música ganen dinero.
Almacenamiento musical global y descentralizado.
Inicialmente traté de encontrar soluciones existentes y construir todo sobre esa base. Después de un tiempo de búsqueda, lo primero que llamó mi atención fue . Comencé la implementación de mi idea, pero después de un tiempo descubrí varios problemas críticos en esta solución:
- Ipfs es un almacén para todo y para todos. Aquí hay imágenes, música, videos y cualquier cosa que puedas imaginar. En resumen, es un gran 'basurero' planetario. Por lo tanto, cuando inicias tu nodo, recibes una carga enorme. La máquina simplemente sufre.
- Es un mecanismo incompleto para la recolección de 'basura'. No sé cómo está ahora, pero en su momento, si especificabas en la configuración que querías limitar el almacenamiento a diez gigabytes de datos, eso no significaba nada. El almacenamiento crecía, ignorando muchos parámetros de configuración. En consecuencia, era necesario tener un gran espacio en el disco duro mientras ipfs decidía cómo liberar lo innecesario.
- En el momento en que usé la biblioteca (no sé cómo está ahora), el cliente no tenía implementados los timeouts. Envías una solicitud para obtener un archivo, y si no está, simplemente te quedas colgado. Por supuesto, la gente inventó diversas soluciones alternativas que resolvían parte del problema, pero eran parches. Este tipo de cosas deberían venir incluidas de forma nativa.
También había muchos problemas menores, la impresión que quedó era clara: no se puede utilizar para un proyecto. Continué buscando almacenes, explorando diferentes opciones, pero no encontré nada adecuado.
Al final, decidí intentar crear un almacenamiento descentralizado por mí mismo. Aunque no pretenda ser interplanetario, resolverá la tarea específica que se plantea.
Así surgieron , , , , .
spreadable es la capa principal, la más baja, que permite agrupar nodos en red. Contiene un algoritmo que he implementado parcialmente, orientado a aproximadamente 10,000 servidores. La versión completa del algoritmo es mucho más compleja de implementar y requeriría varios meses adicionales (quizás más).
No voy a detallar spreadable en este artículo, mejor haré uno separado en algún momento. Aquí solo señalaré algunas características:
- Funciona a través de http/https.
- Se pueden crear redes separadas para tareas específicas, lo que reducirá significativamente la carga en cada proyecto individual, en comparación con tener todos en una sola red.
- Inicialmente se pensó en un mecanismo con timeouts y otros pequeños detalles. Y esto funciona para todos los métodos tanto en el cliente como en el nodo. Se pueden gestionar flexiblemente los parámetros desde tu aplicación.
- La biblioteca está escrita en nodejs. Los problemas de rendimiento del stack se compensan con la naturaleza descentralizada. La carga se puede "dispersar" aumentando el número de nodos. A cambio, hay muchas ventajas: una enorme comunidad, simplicidad y comodidad en el trabajo, un cliente isomórfico, ausencia de dependencias externas, etc.
storacle — es una capa que hereda de spreadable, que permite almacenar archivos en la red. Cada archivo tiene su propio hash según su contenido, que se puede utilizar posteriormente para recuperarlo. Los archivos no se dividen en bloques, sino que se almacenan en su totalidad.
metastocle — es una capa que hereda de spreadable, que permite almacenar datos en la red, pero no archivos. La interfaz es similar a bases de datos noSQL. Se puede, por ejemplo, añadir un archivo a storacle, obtener su hash y escribirlo en metastocle vinculado a algo.
museria — hereda de storacle y metastocle. Esta capa es responsable del almacenamiento de música. El almacenamiento trabaja solamente con archivos mp3 y etiquetas id3.
Se utiliza el "nombre completo" de la canción como "clave" en forma de Artista (TPE1) — Título (TIT2)Por ejemplo:
- Brimstone — The Burden
- Hi-rez — Lost My Way (feat. Emilio Rojas, Dani Devinci)
Para saber con el máximo detalle cómo se forman los nombres de las canciones se puede ver la función utils.beautifySongTitle().
Una coincidencia por claves se considera el porcentaje configurado en los ajustes del nodo. Por ejemplo, un valor de 0.85 significa que si la función de comparación de claves (nombres de canciones) detecta una similitud mayor al 85%, se considera que es la misma canción.
El algoritmo para determinar la similitud está también allí, en la función utils.getSongSimilarity().
La carátula de la canción, para recuperación posterior, también se debe adjuntar a través de las etiquetas (APIC). En las utilidades (utils) hay todos los métodos necesarios para obtener y procesar las etiquetas.
Un ejemplo de funcionamiento con el almacenamiento a través del cliente se puede ver en .
Todas las capas mencionadas anteriormente son autosuficientes y pueden ser utilizadas por separado como capas más bajas para otros proyectos. Por ejemplo, ya hay una idea de hacer una capa para almacenar libros.
museria-global — es un repositorio git ya configurado para ejecutar su propio nodo en la red global de música. Clona, npm i && npm start y eso es todo. Se puede configurar más detalladamente, ejecutar en docker, etc. Hay información detallada disponible en .
Cuando se actualiza el repositorio, también es necesario actualizar su nodo. Si cambia el número de versión mayor o menor, esta acción es obligatoria; de lo contrario, los nodos antiguos serán ignorados por la red.
Se puede trabajar con canciones manual o programáticamente. Cada nodo inicia un servidor para diversas tareas. En particular, al visitar el punto final por defecto, obtendrá una interfaz para trabajar con música. Por ejemplo, puede entrar en (el enlace puede no ser relevante más tarde; también se pueden obtener nodos de entrada en , o ver actualizaciones en GitHub).
Así puedes buscar y descargar canciones en el almacenamiento. La carga de canciones puede realizarse en dos modos: normal y moderado. El segundo modo significa que un ser humano, y no un programa, conduce el proceso. Y si marca esta casilla al agregar, será necesario resolver un captcha. Las canciones se pueden agregar con prioridades de -1, 0 o 1. La prioridad 1 solo se puede establecer en modo moderado. Las prioridades sirven para que el almacenamiento tome decisiones más eficaces sobre qué hacer cuando intenta reemplazar una canción existente por una nueva. Cuanto mayor sea la prioridad, mayores serán las posibilidades de sobrescribir el archivo existente. Esto ayuda a combatir el spam y aumenta la calidad de las canciones cargadas.
Si comienza a agregar canciones en el almacenamiento, intente también adjuntar imágenes (portadas), aunque este campo no sea obligatorio. En el 99% de los casos, las primeras imágenes en Google por los nombres de las canciones son portadas de álbumes.
¿Cómo ocurre técnicamente la adición de archivos, en pocas palabras?
- El cliente recibe la dirección de un nodo libre, que durante un tiempo se convertirá en coordinador.
- Se activa la función de agregar una canción (por una persona o por código), se realiza una solicitud de adición al punto final del coordinador.
- El coordinador calcula cuántos duplicados es necesario conservar (parámetro configurable).
- Se buscan los nodos más apropiados para el almacenamiento.
- El archivo, directamente, se envía a estos nodos.
¿Cómo ocurre técnicamente la obtención de archivos?
- El cliente recibe la dirección de un nodo libre, que durante un tiempo se convertirá en coordinador.
- Se activa la función de obtener una canción (por una persona o por código), se realiza una solicitud de obtención al punto final del coordinador.
- El coordinador verifica la existencia del enlace en la caché. Si existe y funciona, se devuelve inmediatamente al cliente; de lo contrario, se consultan los nodos sobre la existencia.
- Se está obteniendo el archivo a través del enlace, si se encontró alguno.
Alternativas para creadores de música
Siempre me ha interesado la pregunta de cómo se puede evaluar objetivamente el valor de muchas obras creativas. ¿Por qué, por ejemplo, alguien pone su álbum musical a 10$? ¿O a 20$ o a 100$? ¿Cuál es el algoritmo? Cuando hablamos de algún producto físico, o incluso de muchos tipos de servicios, al menos podemos calcular el costo de producción y partir de eso.
Ok, supongamos que se puso 10$. ¿Es realmente eficaz? Supongamos que escuché un álbum o una canción de allí y decidí agradecer. Pero según mis sensaciones y posibilidades, 3$ son mi techo. ¿Y aquí qué hacer? Lo más probable es que simplemente no haga nada, como la mayoría de las personas.
Al establecer un precio fijo por el trabajo creativo, simplemente te limitas, no permites que más personas te envíen menos dinero, que en suma podría ser más significativo que aquellos que compren al precio que tú has establecido. Me parece que la creatividad es precisamente el ámbito donde deberían prevalecer las donaciones. Para esto se necesita:
- Enseñar a las personas a agradecer de esta forma. Los creadores deben mostrar claramente que les gustaría recibir donaciones, añadir enlaces a diferentes métodos de pago en todas partes, etc.
- Se necesitan más mecanismos para simplificar y reforzar estos procesos. Por ejemplo, crear un sitio global donde se pueda donar por la creatividad a través de enlaces de autor.
Supongamos que el enlace es aproximadamente así:
http://someartistsdonationsite.site/category/artist?external-infoSi nos limitamos a los músicos, entonces:
http://someartistsdonationsite.com/music/miyagi?song=blablaEl intérprete necesita verificar su apodo y asociarlo con él.
En el cliente museria añadimos una función para generar este tipo de enlace, y todos los proyectos que utilicen el almacenamiento pueden colocar botones para donaciones con estos enlaces junto a las canciones en sus sitios/aplicaciones. Los usuarios tienen la posibilidad de donar de forma muy rápida y sencilla. Naturalmente, este enfoque se puede usar en cualquier proyecto y categoría de creatividad, no solo a través del almacenamiento.
¿Por qué, para ti, un almacenamiento musical, y cómo puedes participar en esto?
- Si trabajas en un proyecto relacionado con la música o planeas crear uno, todo esto fue concebido para ello. Puedes usar museria para almacenar y obtener canciones, aumentando el flujo de canciones en la red. Si, además, tienes la capacidad de levantar y mantener al menos un nodo propio, será la mejor contribución al desarrollo de la red.
- Quizás estés listo para asumir algún otro rol: ayudar con el código, o llenar y moderar la base de datos, difundir información sobre el proyecto a tus conocidos, etc.
- Tal vez te haya gustado la idea y estés dispuesto a ayudar financieramente para que todo esto viva y se desarrolle. Cuantos más nodos, más canciones.
- O simplemente, en algún momento necesitarás encontrar y descargar una canción. Podrás hacerlo muy fácilmente, por ejemplo, a través de .
El proyecto está en su etapa inicial. Se ha lanzado una red de prueba, los nodos pueden reiniciarse con frecuencia, requerir actualizaciones, etc. Si no hay problemas críticos durante el período de evaluación, esta misma red se transformará en la principal.
Puedes ver la información sobre un nodo desde afuera: la cantidad de canciones, espacio libre, etc., a través de un enlace del tipo http://node-address/status o http://node-address/status?pretty
Mis contactos:
Fuente: habr.com
