Ik besloot ooit een applicatie te schrijven om muziek voor mezelf te selecteren en er thuis/op straat/tijdens het sporten, enzovoort, naar te luisteren. En dit alles in één stream te laten werken, met minimale deelname van mijn kant. Ik bedacht een architectuur, schetste een prototype en stuitte uiteindelijk op een "klein probleempje".
En het is onduidelijk waar de muziekbestanden zelf te vinden zijn. Tegen die tijd had VKontakte zijn API al gesloten en op grote muziekportals is alles ook doof, zelfs nummers worden in stukjes aangeboden zodat ze niet worden geparseerd. Er waren alleen een paar individuele eendaagse sites met een hoop reclame en allerlei rommel, allerlei dubieuze grabberprogramma's en andere "vuile" opties. Over het algemeen geen enkele echt goede oplossing. Natuurlijk kun je een abonnement nemen op wat Yandex-muziek of iets dergelijks. Maar nogmaals, er is nergens een openbare API en je hebt geen programmatische toegang tot muziek. Verschillende grote bedrijven hebben de toegang tot muziek zelfs voor anderen beperkt. Waarom is dit überhaupt gebeurd? Na verder onderzoek werd duidelijk dat het grootste probleem het auteursrecht is. De huidige oplossing in de vorm van abonnementen is geschikt voor veel commerciële auteurs van muziekwerken en diezelfde bedrijven. Tegelijkertijd vallen niet-commerciële en voorwaardelijk commerciële muziek ook in de algemene lijst. Je betaalt voor alles, of luistert helemaal nergens naar.
En ik begon na te denken over wat ik met dit alles aan moest. Hoe kan ik gratis muziekdistributie organiseren? Wat zou ik doen als ik zelf muziek maak en er geld mee wil verdienen? Zou ik het leuk vinden als mijn nummers illegaal worden verspreid? Welke alternatieve oplossing is er?
Hierdoor ontstonden twee grote problemen die opgelost moesten worden:
- Het organiseren van de gratis distributie van muziek met methoden die voor de meeste mensen handig zijn, inclusief software.
- Het bieden van alternatieven voor muziekmakers om geld te verdienen
Wereldwijde gedecentraliseerde muziekopslag
In eerste instantie probeerde ik bestaande oplossingen te vinden en daar alles op te baseren. Na een tijdje zoeken viel mijn oog op de eerste oplossing. Ik begon mijn idee uit te voeren, maar na verloop van tijd ontdekte ik een aantal cruciale problemen in deze oplossing:
- Ipfs is een opslag voor alles. Er zijn afbeeldingen, muziek, video en alles wat je maar kunt bedenken. In feite is het een grote planetaire "vuilnisbelt". Daarom krijg je bij het opstarten van je node meteen een enorme lading. De machine kronkelt van de pijn.
- Een onafgewerkt mechanisme voor garbage collection. Ik weet niet hoe het er nu voor staat, maar destijds betekende het niets als je in de configuratie aangaf dat je de opslagruimte wilde beperken tot tien gigabyte aan data. De opslagruimte groeide, ondanks veel configuratieparameters. Daardoor moest je een enorme reserve aan harde schijven hebben totdat ipfs erachter kwam hoe je onnodige data kon dumpen.
- Toen de bibliotheek nog in gebruik was (ik weet niet hoe het nu is), had de client geen time-outs geïmplementeerd. Je stuurt een verzoek om een bestand op te halen, en als het er niet is, loop je vast. Natuurlijk hebben mensen allerlei oplossingen bedacht die het probleem gedeeltelijk oplosten, maar dit waren slechts hulpmiddelen. Zulke dingen zouden standaard moeten zijn.
Er waren nog steeds veel kleine probleempjes, de indruk was duidelijk: dit is niet bruikbaar voor het project. Ik bleef zoeken naar een opslagplaats, bestudeerde verschillende opties, maar vond niets geschikts.
Uiteindelijk besloot ik dat het de moeite waard was om zelf een gedecentraliseerde opslag te schrijven. Laat het niet doen alsof het interplanetair is, maar het zal een specifieke taak oplossen.
Zo is het gelopen , , , , .
smeerbaar — dit is de basislaag, de onderste laag, waarmee je knooppunten in een netwerk kunt verbinden. Het bevat een algoritme dat ik gedeeltelijk heb geïmplementeerd voor ongeveer 10000 servers. De volledige versie van het algoritme is veel lastiger te implementeren en zou enkele maanden (misschien meer) extra kosten.
Ik zal Spreadable in dit artikel niet in detail beschrijven, ik schrijf er later nog wel een apart artikel over. Ik noem hier slechts enkele kenmerken:
- Werkt via http/https.
- U kunt een apart netwerk voor een specifieke taak maken. Hierdoor wordt de belasting van elk afzonderlijk project aanzienlijk verlaagd in vergelijking met wanneer alle projecten op hetzelfde netwerk zouden zitten.
- Aanvankelijk werd een mechanisme met time-outs en andere kleine dingetjes bedacht. Dit werkt voor alle methoden, zowel in de client als in de node. Je kunt de parameters flexibel beheren vanuit je applicatie.
- De bibliotheek is geschreven in NodeJS. De problemen met de stackprestaties worden gecompenseerd door het gedecentraliseerde karakter. De belasting kan worden "verspreid" door het aantal nodes te verhogen. Daartegenover staan vele voordelen: een enorme community, eenvoud en gebruiksgemak, een isomorfe client, geen externe afhankelijkheden, enzovoort.
opbergruimte — is een laag die is overgenomen van Spreadable en waarmee bestanden op het netwerk kunnen worden opgeslagen. Elk bestand heeft een eigen hash op basis van de inhoud, waarmee het later kan worden verkregen. Bestanden worden niet in blokken verdeeld, maar in hun geheel opgeslagen.
metastacle — een laag overgenomen van Spreadable, waarmee gegevens, maar geen bestanden, op het netwerk kunnen worden opgeslagen. De interface is vergelijkbaar met die van NoSQL-databases. Je kunt bijvoorbeeld een bestand toevoegen aan Storacle, de hash ervan ophalen en het met een link naar Metastocle wegschrijven.
museum — overgenomen van storacle en metastocle. Deze laag is direct verantwoordelijk voor het opslaan van muziek. De opslag werkt alleen met mp3-bestanden en id3-tags.
De volledige titel van een lied wordt gebruikt als ‘sleutel’ voor het lied. Kunstenaar (TPE1) - Titel (TIT2). Bijvoorbeeld:
- Zwavel - De last
- Hi-rez - Lost My Way (feat. Emilio Rojas, Dani Devinci)
Hoe songtitels tot stand komen, kun je tot in detail nagaan Je moet naar de functie kijken utils.beautifySongTitle().
Een sleutelmatch is een percentage dat is gedefinieerd in de knooppuntinstellingen. Een waarde van 0.85 betekent bijvoorbeeld dat als de sleutelvergelijkingsfunctie (titels van nummers) een overeenkomst van meer dan 85% heeft gevonden, het om hetzelfde nummer gaat.
Het algoritme voor het bepalen van gelijkenis is er, in de functie utils.getSongSimilarity().
De cover van het liedje, die later teruggevonden kan worden, is ook toegevoegd via tags (APIC). Hulpprogramma's bevatten alle benodigde methoden voor het verkrijgen en verwerken van tags.
Een voorbeeld van het werken met opslag via de client is te zien in .
Alle bovenstaande lagen zijn zelfvoorzienend en kunnen afzonderlijk als onderste lagen voor andere projecten worden gebruikt. Ik heb bijvoorbeeld al een idee om een laag te maken voor het opbergen van boeken.
museum-globaal — is een vooraf geconfigureerde Git-repository voor het runnen van je eigen knooppunt in het wereldwijde muzieknetwerk. Klonen, npm i && npm Start en dat is alles. Je kunt het gedetailleerder configureren, uitvoeren in Docker, enz. Gedetailleerde informatie is beschikbaar op .
Wanneer de repository wordt bijgewerkt, moet u uw node bijwerken. Als het primaire of secundaire versienummer verandert, is deze actie verplicht, anders worden oude nodes door het netwerk genegeerd.
Je kunt handmatig en programmatisch met muziek werken. Elk knooppunt start een server voor verschillende taken. Wanneer je het standaard eindpunt bezoekt, krijg je onder andere een interface voor het werken met muziek. Je kunt bijvoorbeeld naar (de link is later mogelijk niet meer relevant, de invoerknooppunten kunnen ook worden verkregen in , of bekijk updates op github).
Zo kun je nummers zoeken en uploaden naar de repository. Het uploaden van nummers kan in twee modi: normaal en gemodereerd. De tweede modus houdt in dat een persoon, en niet een programma, het werk doet. Als je dit vakje aanvinkt tijdens het toevoegen, moet je de captcha oplossen. Nummers kunnen worden toegevoegd met prioriteiten van -1, 0 of 1. Prioriteit 1 kan alleen worden ingesteld in de gemodereerde modus. Prioriteiten zijn nodig zodat de repository effectiever kan beslissen wat er moet gebeuren wanneer je een bestaand nummer probeert te vervangen door een nieuw nummer. Hoe hoger de prioriteit, hoe groter de kans dat je het bestaande bestand overschrijft. Dit helpt spam te bestrijden en verhoogt de kwaliteit van de nummers die je uploadt.
Als je nummers aan de repository toevoegt, probeer dan afbeeldingen (cover) toe te voegen, hoewel dit veld niet verplicht is. In 99% van de gevallen zijn de eerste afbeeldingen in Google op basis van de titel van een nummer albumhoezen.
Hoe bestanden technisch worden toegevoegd, in een notendop:
- De cliënt ontvangt het adres van een vrij knooppunt, dat voor een bepaalde tijd de rol van coördinator op zich neemt.
- De functie om een nummer toe te voegen wordt geactiveerd (door een persoon of code) en er wordt een verzoek gedaan om het nummer toe te voegen aan het coördinator-eindpunt.
- De coördinator berekent hoeveel duplicaten er bewaard moeten worden (configureerbare parameter).
- Er wordt gezocht naar de meest geschikte knooppunten voor bewaring.
- Het bestand gaat rechtstreeks naar deze knooppunten.
Hoe bestanden technisch worden verkregen:
- De cliënt ontvangt het adres van een vrij knooppunt, dat voor een bepaalde tijd de rol van coördinator op zich neemt.
- De functie voor het ontvangen van een liedje wordt geactiveerd (door een persoon of code); er wordt een verzoek tot ontvangst gedaan aan het coördinator-eindpunt.
- De coördinator controleert of er een link in de cache aanwezig is. Als er een link is en deze werkt, wordt deze direct teruggestuurd naar de client. Zo niet, dan wordt de beschikbaarheid van de nodes opgevraagd.
- Het bestand wordt opgehaald via een link, als die gevonden wordt.
Alternatieven voor muziekmakers
Ik ben altijd geïnteresseerd geweest in de vraag hoe je de kosten van veel creatieve werken objectief kunt beoordelen. Waarom biedt iemand bijvoorbeeld zijn muziekalbum te koop aan voor $ 10? Of voor $ 20 of voor $ 100? Waar is het algoritme? Wanneer we het bijvoorbeeld hebben over een fysiek product, of zelfs over allerlei soorten diensten, kunnen we op zijn minst de kostprijs berekenen en daar dan op voortbouwen.
Oké, laten we zeggen dat ze $10 inzetten. Is dat echt zo effectief? Stel dat ik ergens naar een album of een nummer luister en besluit mijn dankbaarheid te tonen. Maar volgens mijn gevoel en mijn eigen mogelijkheden is $3 mijn plafond. Dus wat moet ik doen? Waarschijnlijk doe ik gewoon helemaal niets, zoals de meeste mensen.
Door een vaste prijs voor creatief werk vast te stellen, beperk je jezelf simpelweg. Je staat niet toe dat een groot aantal mensen je minder geld stuurt, wat in totaal indrukwekkender kan zijn dan degenen die kopen tegen de door jou vastgestelde prijs. Het lijkt me dat creativiteit precies het gebied is waar donaties voorop zouden moeten staan. Om dit te bereiken, moet je:
- Leer mensen op deze manier te bedanken. Makers zouden zelf duidelijk moeten aangeven dat ze graag donaties willen ontvangen, overal links naar verschillende betaalmethoden moeten toevoegen, enzovoort.
- We hebben meer mechanismen nodig om deze processen te vereenvoudigen en te versterken. Bijvoorbeeld door een soort wereldwijde website te creëren waar je kunt doneren voor creativiteit met behulp van auteurslinks.
Stel dat de link er zo uitziet:
http://someartistsdonationsite.site/category/artist?external-infoAls we het beperken tot muzikanten:
http://someartistsdonationsite.com/music/miyagi?song=blablaDe artiest moet zijn bijnaam verifiëren en er een naam aan koppelen.
We voegen een functie toe om een dergelijke link naar de Museria-client te genereren. Alle projecten die de opslag gebruiken, kunnen donatieknoppen met deze links naast de nummers op hun websites/apps plaatsen. Gebruikers kunnen zo heel snel en eenvoudig een donatie doen. Uiteraard kan deze aanpak in elk project en elke creatieve categorie worden gebruikt, niet alleen via de opslag.
Waarom u een muziekopslag nodig hebt en hoe u kunt deelnemen
- Als je aan een muziekproject werkt of van plan bent er een te maken, dan is dit waar het om draaide. Je kunt museria gebruiken om nummers op te slaan en op te halen, waardoor de stroom van nummers op het netwerk toeneemt. Als je de mogelijkheid hebt om minstens één eigen knooppunt op te zetten en te onderhouden, dan is dit de beste bijdrage aan de ontwikkeling van het netwerk.
- Misschien bent u er klaar voor om een andere rol op u te nemen: helpen met de code, of de database vullen en modereren, informatie over het project verspreiden naar uw vrienden, etc.
- Misschien vind je het idee leuk en ben je bereid financieel bij te dragen, zodat dit allemaal tot leven komt en zich ontwikkelt. Hoe meer knooppunten, hoe meer nummers.
- Of je moet gewoon op een gegeven moment een nummer zoeken en downloaden. Dat kan heel eenvoudig, bijvoorbeeld via .
Het project bevindt zich momenteel in de beginfase. Er is een testnetwerk gelanceerd, nodes kunnen regelmatig opnieuw opstarten, updates vereisen, enz. Indien er zich tijdens de evaluatieperiode geen kritieke problemen voordoen, wordt ditzelfde netwerk omgevormd tot het hoofdnetwerk.
U kunt informatie over een knooppunt van buitenaf bekijken: aantal nummers, vrije ruimte, enz., met behulp van een koppeling van het volgende type http://node-address/status of http://node-address/status?pretty
Mijn contacten:
Bron: www.habr.com
