Museria — stockage de musique décentralisé

Un jour, j'ai décidé d'écrire une application pour choisir de la musique à écouter chez moi, en extérieur, pendant mes entraînements, etc. Et pour que tout cela fonctionne en continu, avec un minimum de mon intervention. J'ai conçu l'architecture, esquissé un prototype et finalement, je suis tombé sur un petit "problème".

Mais je ne savais pas d'où récupérer les fichiers musicaux eux-mêmes. À ce moment-là, VKontakte avait déjà fermé son API, et les grands portails musicaux étaient également bloqués ; même les chansons étaient délivrées en morceaux pour empêcher le scraping. Il ne restait que quelques sites éphémères remplis de publicités et de contenu indésirable, des programmes grabbers douteux et d'autres solutions "sales". En résumé, aucune solution réellement valable. Bien sûr, on peut acheter un abonnement à Yandex Music ou autre chose. Mais là encore, il n'y a pas d'API publique ouverte et tu n'as pas d'accès programmatique à la musique. Certaines grandes entreprises ont essentiellement limité l'accès à la musique pour les autres. Pourquoi cela s'est-il produit ? En approfondissant, il est devenu clair que le problème principal réside dans les droits d'auteur. La solution actuelle sous forme d'abonnements satisfait de nombreux auteurs commerciaux de compositions musicales et ces mêmes entreprises. Cependant, la musique non commerciale et conditionnellement commerciale est également incluse dans la liste générale. Soit tu paies pour tout, soit tu ne t'écoutes rien du tout.

Alors j'ai commencé à réfléchir à ce qu'il fallait faire avec tout cela. Comment organiser la distribution libre de la musique ? Que ferais-je si je créais de la musique et voulais en vivre ? Est-ce que cela me plairait si mes chansons étaient diffusées de manière pirate ? Quelle alternative existe-t-il ?

Au final, deux problèmes principaux se sont dégagés qu'il faut résoudre :

• Organisation de la distribution libre de la musique par des méthodes confortables pour la plupart des gens, y compris des méthodes logicielles.
• Proposition d'alternatives aux créateurs de musique pour gagner de l'argent

Un stockage musical mondial décentralisé

Au départ, j'ai essayé de trouver des solutions existantes et de créer tout à partir de celles-ci. Après un certain temps de recherche, j'ai été attiré en premier par ipfs. J'ai commencé à réaliser mon idée, mais après un certain temps, j'ai découvert plusieurs problèmes critiques dans cette solution :

• Ipfs — un stockage pour tout et n'importe quoi. Des images, de la musique, des vidéos, et tout ce que vous pouvez imaginer. En gros, c'est une vaste « décharge » planétaire. Donc, lorsque vous lancez votre nœud, vous êtes immédiatement soumis à une charge énorme. La machine souffre littéralement.
• C'est une sorte de mécanisme inachevé de collecte de « déchets ». Je ne sais pas comment ça se passe maintenant, mais à l'époque, si vous configuriez pour limiter le stockage à dix gigaoctets de données, cela ne signifiait rien. Le stockage s'étendait, ignorant de nombreux paramètres de configuration. En fin de compte, il fallait avoir une énorme capacité de disque dur tant qu'ipfs ne savait pas comment supprimer l'inutile.
• Au moment d'utiliser la bibliothèque (je ne sais pas comment c'est actuellement), le client n'avait pas de délais d'attente. Vous envoyez une requête pour obtenir un fichier, et si celui-ci n'existe pas, vous restez simplement bloqué. Bien sûr, les gens ont trouvé diverses solutions de contournement qui résolvaient en partie le problème, mais ce n'était que des rustines. De telles fonctionnalités devraient être incluses de manière native.

Il y avait aussi de nombreux petits problèmes, et l'impression que j'en ai gardée était claire : on ne peut pas l'utiliser pour un projet. J'ai continué à chercher un stockage, étudiant différentes options, mais je n'ai toujours rien trouvé de convenable.

En fin de compte, j'ai décidé d'essayer d'écrire mon propre stockage décentralisé. Qu'il ne prétende pas au rôle interplanétaire, mais qu'il résolve un problème spécifique.

Ainsi sont nés spreadable, storacle, metastocle, museria, museria-global.

spreadable — c'est la couche principale, la plus basse, qui permet de relier les nœuds dans un réseau. Il contient un algorithme que j'ai partiellement implémenté pour environ 10000 serveurs. La version complète de l'algorithme est beaucoup plus compliquée à mettre en œuvre et nécessiterait encore plusieurs mois supplémentaires (peut-être plus).

Je ne vais pas décrire approfondiament spreadable dans cet article, je préfère écrire un article séparé un jour. Ici, je vais juste noter certaines caractéristiques :

• Fonctionne via http/https.
• Il est possible de créer un réseau distinct pour une tâche spécifique, ce qui réduit considérablement la charge sur chaque projet individuel, contrairement à s'ils étaient tous sur un même réseau.
• Un mécanisme avec des délais d'attente et d'autres petits détails a été initialement prévu. Et cela fonctionne pour toutes les méthodes, tant dans le client que dans le nœud. On peut gérer les paramètres de manière flexible depuis sa propre application.
• La bibliothèque est écrite en nodejs. Les problèmes de performance de la pile sont compensés par la nature décentralisée. La charge peut être "étalée" en augmentant le nombre de nœuds. En retour, il y a beaucoup d'avantages : une immense communauté, simplicité et facilité de travail, un client isomorphe, absence de dépendances extérieures, etc.

storacle — est une couche qui hérite de spreadable, permettant de stocker des fichiers sur le réseau. Chaque fichier a son propre hachage basé sur son contenu, ce qui permet de l'accéder par la suite. Les fichiers ne sont pas divisés en blocs, mais stockés en entier.

metastocle — est une couche qui hérite de spreadable, permettant de stocker des données sur le réseau, mais pas des fichiers. L'interface est similaire aux bases de données nosql. Par exemple, on peut ajouter un fichier à storacle, obtenir son hachage et l'écrire dans metastocle avec un lien vers quelque chose.

museria — hérite de storacle et metastocle. Cette couche est directement responsable du stockage de la musique. Le stockage ne travaille qu'avec des fichiers mp3 et des tags id3.

La "clé" de la chanson est son titre complet sous la forme de Artiste (TPE1) — Titre (TIT2). Par exemple :

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

Pour savoir comment les titres des chansons sont formés en détail, il faut iciregarder la fonction utils.beautifySongTitle().

Une correspondance par clés est considérée comme un pourcentage défini dans les paramètres du nœud. Par exemple, une valeur de 0,85 signifie que si la fonction de comparaison des clés (titres de chansons) détecte une similarité supérieure à 85%, alors il s'agit de la même chanson.

L'algorithme de détermination de similarité est également là, dans la fonction utils.getSongSimilarity().

La couverture de la chanson, pour un accès ultérieur, doit également être attachée via les tags (APIC). Dans les utilitaires (utils), tous les méthodes nécessaires pour obtenir et traiter les tags sont disponibles.

Un exemple de travail avec le stockage via le client peut être vu dans readme.

Tous les couches mentionnées ci-dessus sont autonomes et peuvent être utilisées séparément comme des couches inférieures pour d'autres projets. Par exemple, l'idée de créer une couche pour le stockage de livres existe déjà.

museria-global — est un dépôt git préconfiguré pour lancer votre propre nœud dans le réseau mondial de la musique. Clonez-le, npm i && npm start et c'est tout. Une configuration plus détaillée peut être effectuée, lancer dans docker, etc. Des informations détaillées sont disponibles sur GitHub.

Lorsqu'un dépôt est mis à jour, il est également nécessaire de mettre à jour votre nœud. Si le numéro de version majeur ou mineur change, cette action est obligatoire, sinon les anciens nœuds seront ignorés par le réseau.

Il est possible de travailler avec des chansons manuellement et par programme. Chaque nœud lance un serveur pour diverses tâches. En visitant le point d'accès par défaut, vous obtiendrez une interface pour travailler avec la musique. Par exemple, vous pouvez accéder à le nœud racine (le lien peut ne plus être pertinent plus tard, les nœuds d'entrée sont également accessibles via Telegram, ou consulter les mises à jour sur GitHub).

Ainsi, vous pouvez rechercher et télécharger des chansons dans le stockage. Le téléchargement de chansons peut se faire en deux modes : normal et modéré. Le deuxième mode signifie qu'une personne, et non un programme, gère le processus. Si vous cochez cette case lors de l'ajout, vous devrez résoudre un captcha. Les chansons peuvent être ajoutées avec des priorités -1, 0 ou 1. La priorité 1 ne peut être donnée qu'en mode modéré. Les priorités sont nécessaires pour que le stockage prenne des décisions plus efficaces lorsque vous essayez de remplacer une chanson existante par une nouvelle. Plus la priorité est élevée, plus vous aurez de chances de remplacer le fichier existant. Cela aide à lutter contre le spam et augmente la qualité des chansons téléchargées.

Si vous commencez à ajouter des chansons dans le stockage, essayez d'attacher des images (couverture), même si ce champ n'est pas obligatoire. Dans 99 % des cas, les premières images sur Google en fonction des titres de chansons sont des couvertures d'albums.

En termes techniques, voici comment les fichiers sont ajoutés, en deux mots :

• Le client reçoit l'adresse d'un nœud libre, qui deviendra coordonnateur pendant un certain temps.
• La fonction d'ajout de chanson (par une personne ou par code) est déclenchée, une demande d'ajout est envoyée au point d'accès du coordonnateur.
• Le coordonnateur calcule combien de doublons doivent être conservés (paramètre configurable).
• Les nœuds les plus appropriés pour le stockage sont recherchés.
• Le fichier est directement envoyé à ces nœuds.

Voici comment les fichiers sont récupérés techniquement :

• Le client reçoit l'adresse d'un nœud libre, qui deviendra coordonnateur pendant un certain temps.
• La fonction d'obtention de chanson (par une personne ou par code) est déclenchée, une demande d'obtention est envoyée au point d'accès du coordonnateur.
• Le coordonnateur vérifie la présence du lien dans le cache. S'il existe et qu'il est actif, il est immédiatement renvoyé au client, sinon les nœuds sont interrogés pour vérifier leur disponibilité.
• Le fichier est en cours de récupération via le lien, si trouvé.

Alternatives pour les créateurs de musique

Je me suis toujours demandé comment évaluer objectivement le prix de nombreuses œuvres créatives. Pourquoi, par exemple, une personne fixe-t-elle le prix de son album musical à 10 $ ? Ou à 20 $ ou à 100 $. Quel est l'algorithme ? Quand, par exemple, nous parlons d'un produit physique ou même de nombreux types de services, nous pouvons au moins calculer le coût de production et partir de là.

Ok, supposons qu'on fixe le prix à 10 $. Est-ce vraiment efficace ? Supposons que j'écoute l'album quelque part ou une chanson de celui-ci et que je souhaite remercier l'artiste. Mais selon mes impressions et mes capacités, 3 $ est mon plafond. Que faire alors ? Il est probable que je ne ferai rien, comme la plupart des gens.

En fixant un prix fixe pour un travail créatif, tu te limites simplement, tu ne permets pas à un plus grand nombre de personnes de t'envoyer moins d'argent, ce qui pourrait cumulativement être plus important que ce que ceux qui achètent à ton prix fixe. Je pense que la créativité est justement ce domaine où les dons devraient, en premier lieu, prédominer. Pour cela, il faut :

• Apprendre aux gens à remercier de cette manière. Les créateurs doivent montrer clairement qu'ils aimeraient recevoir des dons, en ajoutant des liens vers différents moyens de paiement, etc.
• Il faut plus de mécanismes pour simplifier et renforcer ces processus. Par exemple, créer un site global où les dons pour la créativité pourraient être faits via des liens d'auteur.

  Disons que le lien est à peu près comme ça :

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

  Si l'on se limite aux musiciens, alors :

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

  L'interprète doit vérifier son pseudo et s'y rattacher.

  Dans le client museria, nous ajoutons une fonction de génération de ce type de lien, et tous les projets utilisant le stockage peuvent placer sur leurs sites/applications des boutons pour des dons avec ces liens à côté des chansons. Les utilisateurs ont la possibilité de faire des dons très rapidement et facilement. Évidemment, cette approche peut être utilisée dans n'importe quel projet et catégorie de créativité, pas seulement à travers le stockage.

Pourquoi, en particulier pour toi, un stockage musical, et comment y participer ?

• Si tu travailles sur un projet lié à la musique ou si tu prévois d'en créer un, c'est pour cela que tout cela a été conçu. Tu peux utiliser museria pour stocker et obtenir des chansons, augmentant le flux de chansons en ligne. Si tu as la possibilité de créer et de maintenir au moins un nœud, ce sera la meilleure contribution au développement du réseau.
• Peut-être es-tu prêt à assumer un autre rôle : aider avec le code, ou remplir et modérer la base de données, diffuser des informations sur le projet à tes connaissances, etc.
• Peut-être que l'idée t'a plu et que tu es prêt à aider financièrement pour que tout cela vive et se développe. Plus il y aura de nœuds, plus il y aura de chansons.
• Ou peut-être qu'à un moment donné, tu auras simplement besoin de trouver et de télécharger une chanson. Tu pourras le faire très facilement, par exemple, via un bot Telegram.

Le projet est actuellement à un stade très précoce. Un réseau test a été lancé, les nœuds peuvent souvent redémarrer, nécessiter des mises à jour, etc. En l'absence de problèmes critiques pendant la période d'évaluation, ce même réseau sera transformé en réseau principal.

Pour voir les informations sur un nœud de l'extérieur : le nombre de chansons, l'espace libre, etc., tu peux te rendre sur un lien de type http://node-address/status ou http://node-address/status?pretty

Mes contacts :

• @ortex
• mywebstreet@gmail.com
• Groupe Telegram en anglais.
• Et le site qui a donné naissance à toute cette idée.

Source : habr.com