🥇Museria — detsentraliseeritud muusika salvestus

Kord mõtlesin ma kirjutada rakenduse, et valida muusikat enda jaoks ja kuulata kodus/väljas/trenni ajal jne. Ja et kõik see toimiks voos, minimaalse osa minu osalusel. Mõtlesin välja arhitektuuri, visandasin prototüübi ja lõppkokkuvõttes sattusin silmitsi ühe "väikese probleemiga".

Kust võiks nende laulude faile võtta, on arusaamatu. Selleks ajaks oli Vkontakte juba API sulgenud ja suuremates muusikaportaalides oli samuti vaikus, isegi lood antakse ära osade kaupa, et ei saaks eraldada. Alles jäid mingid üksikud petturlikud ühepäevakülastused, kus on tonn reklaami ja igasugust prügi, kahtlased grabber-ide ja muud "mustad" variandid. Ühesõnaga, ühtegi tõeliselt head lahendust ei olnud. Loomulikult võib osta tellimuse mõne Yandex Muusika või muu sarnase teenuse jaoks. Kuid jälle, seal ei ole kuskil avalikku API ja sul ei ole juurdepääsu muusikale programmiliselt. Mõned suured ettevõtted on sisuliselt piiranud teiste ligipääsu muusikale. Miks see üldse nii juhtus? Sügavamale kaevates sai selgeks, et peamine probleem on autoriõigustes. Praegune lahendus tellimuste näol sobib paljudele kommertsalustele muusikateoste autoritele ja nendele ettevõtetele. Samuti satub äravõetava muusika hulka ka mittekommertslik ja tinglikult kommertslik muusika. Kas maksad kõigi eest või ei kuula üldse midagi.

Ja hakkasin mõtlema, mida sellega kõigega teha. Kuidas korraldada muusika vabalt levitamist? Mis ma teeksin, kui ma ise muusika loomisega tegeleksin ja sooviksin sellega raha teenida? Kas mulle meeldiks, kui mu laule hakaks salaja jagama? Millised alternatiivsed lahendused võiksid olla?

Loomulikult on kaks peamist probleemi, millega tuleb tegeleda:

Muusika vabaks levitamiseks mugavate meetodite, sealhulgas tarkvarade kaudu korraldamine.
Alternatiivsete võimaluste pakkumine muusika loojatele raha teenimiseks.

Globaalselt jaotatud muusika salvestus.

Esialgu proovisin leida olemasolevaid lahendusi ja ehitada kõik selle põhjal. Pärast mõnda aega otsimist jäi mulle silma ipfs. Alustasin oma idee rakendamist, kuid mõne aja pärast avastasin selles lahenduses mitmeid kriitilisi probleeme:

Ipfs on kõikehõlmav salvestuslahendus. Siin on nii pildid, muusika, videod kui ka kõik muu. Ühesõnaga suur planeetaarne „prügila“. Seetõttu, kui sa oma sõlme käivitad, saad kohe tohutu koormuse. Masin lihtsalt väänleb valu tõttu.
Mõni poolik «prügimehhanism». Ei tea, kuidas selle olukorra praegune seis on, aga siis, kui sa konfiguratsioonis määrasid, et soovid salvestust piirata kümne gigabaidiga, ei tähendanud see midagi. Salvestus laienes, ignoreerides paljusid konfiguratsiooniparameetreid. Tulemusena pidi olema tohutu kõvakettaruumi varu, kuni ipfs suudab aru saada, kuidas ebavajalikku eemaldada.
Raamatukogu kasutamise ajal (ei tea, kuidas praegu on) ei olnud kliendil aja piire. Saadad faili saamise taotluse ja kui seda ei ole, siis lihtsalt ripud. Loomulikult on inimesed välja mõelnud igasuguseid ümbersõite, mis osaliselt probleemi lahendasid, kuid need olid ikkagi ajutised lahendused. Sellised asjad peaksid olema välja pakutud juba algselt.

Lisaks oli palju väikeseid probleeme, üldine mulje oli selgelt negatiivne: seda ei saa projekti jaoks kasutada. Jätkasin salvestuslahenduste otsimist, uurisin erinevaid variante, kuid ei leidnud sobivat.

Lõpuks otsustasin, et võiks proovida ise detsentraliseeritud salvestust kirjutada. Olgu, et see ei püüa mitte mingil juhul olla interplanetaarne, aga see lahendab konkreetselt antud ülesande.

Nii see sündis spreadable, storacle, metastocle, museria, museria-global.

spreadable — see on põhikiht, mis ühendab sõlmed võrguks. Sellesse on sisse ehitatud algoritm, mille olen seni osaliselt ellu viinud ligikaudu 10 000 serveri jaoks. Algoritmi täisversioon on tunduvalt keerulisem ja selle elluviimine võtaks veel mitu kuud (võib-olla rohkem).

Ma ei hakka seda spreadable siin põhjalikult kirjeldama, parem kirjutaksin sellest eraldi hiljem. Siin mainin ainult mõningaid eripärasid:

Töötleb http/https kaudu.
Saate luua eraldi võrgu konkreetse ülesande jaoks, mis vähendab iga projekti koormust võrreldes sellega, kui need kõik oleksid ühes võrgus.
Alguses on ette nähtud mehhanismidega ajapiirangud ja muud pisiasjad. See toimib kõikide meetodite jaoks, nii kliendis kui ka sõlmes. Parameetreid on võimalik paindlikult hallata oma rakendusest.
Raamatukogu on kirjutatud nodejs-is. Jõudluse probleeme kompenseerib detsentraliseeritud iseloom. Koormust saab 'jaotada' sõlmede arvu suurendamisega. Vastutasuks on palju eeliseid: suur ühiskond, töö lihtsus ja mugavus, isomorfne klient, välist sõltuvuste puudumine jne.

storacle — see, miseldav layer, mis võimaldab andmete salvestamist võrgus. Iga faili sisu põhjal on tal oma RÜM ja seda saab hiljem uuesti kätte saada. Failid ei jaotu plokkideks, vaid salvestatakse tervikuna.

metastocle — layer, mis pärineb spreadable'ist ja võimaldab andmete salvestamist võrgus, kuid mitte faile. Liides sarnaneb nosql andmebaasidele. Näiteks saab faili lisada storaclesse, saada selle RÜM ja salvestada metastoclesse mõnele külge.

museria — pärineb storacle'ist ja metastocle'ist. See layer vastutab otseselt muusika salvestamise eest. Laukas töötab ainult mp3 failidega ja id3 siltidega.

Laulu „võtmena” kasutatakse selle täisnimi kujul Esitaja (TPE1) — Pealkiri (TIT2). Näiteks:

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

Maksimaalne teave selle kohta, kuidas laulude nimetused kujunevad, on saadaval siin. Tuleb vaadata funktsiooni utils.beautifySongTitle().

Võtmete (laulude nimede) sarnasuse määramine arvestab node'i seadistustes määratud protsentidega. Näiteks väärtus 0.85 tähendab, et kui võrdlusfunktsioon tuvastab võtmete (laulude) sarnasuse üle 85%, siis on see sama laul.

Sarnasuse määramise algoritm on seal sama, funktsioonis utils.getSongSimilarity().

Laulude katte, mis on edasise saamise jaoks, peab ka olema seotud siltide kaudu (APIC). Utiliitides (utils) on kõik vajalikud meetodid siltide saamiseks ja töötlemiseks.

Näidet selle kohta, kuidas salvestusega kliendi kaudu töötada, saab vaadata readme.

Kõik eespool nimetatud kihid on iseseisvad ja saavad olla eraldi kasutusel kui madalamad kihid teiste projektide jaoks. Näiteks on juba mõte luua kihiga raamatute hoidmise jaoks.

museria-global — see on juba konfigureeritud git-repositoorium enda sõlme käivitamiseks globaalsetes muusika võrkudes. Kloonige, npm i && npm start ja põhimõtteliselt kõik. Saate seadistada detailsemalt, käivitada Dockeris jne. Täiendav teave on saadaval GitHubis.

Kui repositoorium uuendatakse, tuleb ka oma sõlm uuendada. Kui muudetakse peamist või alamversiooni numbrit, on see toiming kohustuslik, vastasel juhul ignoreeritakse vanu sõlmi võrgus.

Lauludega saab töötada käsitsi ja programmiliselt. Iga sõlm käivitab serveri erinevate ülesannete jaoks. Sealhulgas, kui külastate vaikimisi lõpp-punkti, saate liidese muusikaga töötamiseks. Näiteks, võite külastada juurknot (link võib hiljem kehtetuks muutuda, sisenemisallikaid saab samuti saada telegrammis, või vaadata uuendusi githubis).

Nii saate otsida ja laadida laule salvestusse. Laulude üleslaadimine võib toimuda kahes režiimis: tavaline ja pärastmoderatsioon. Viimane tähendab, et tööd teeb inimene, mitte programm. Ja kui lisate selle märkeruudu, peate lahendama CAPTCHA. Laule saab lisada prioriteetidega -1, 0 või 1. Prioriteet 1 võib olla ainult pärastmoderatsioonirežiimis. Prioriteedid on vajalikud, et salvestus saaks tõhusamalt otsustada, mida teha, kui proovite olemasolevat laulu uuega asendada. Mida kõrgem on prioriteet, seda rohkem on võimalusi, et kirjutate olemasoleva faili üle. See aitab võidelda rämpsposti vastu ja suurendab üleslaaditavate laulude kvaliteeti.

Kui hakkate laule salvestusse lisama, proovige ka pilte (kaane) lisada, kuigi see väli ei ole kohustuslik. 99% juhtudest on esimesed pildid Google’is laulunimede järgi albumikaaned.

Kuidas failide lisamine tehniliselt toimub, kahel sõnal:

Kliendile antakse vaba sõlme aadress, mis mingiks ajaks muutub koordinaatoriks.
Aktiveeritakse laulu lisamise funktsioon (inimese või koodi poolt), toimub päring lisamiseks koordinaatori lõpp-punkti.
Koordinaator arvutab, kui palju koopiaid on vaja salvestada (konfigureeritav parameeter).
Otsitakse kõige sobivamaid sõlmi salvestamiseks.
Fail saadetakse nendele sõlmedele.

Kuidas failide hankimine tehniliselt toimub:

Kliendile antakse vaba sõlme aadress, mis mingiks ajaks muutub koordinaatoriks.
Aktiveeritakse laulu saamise funktsioon (inimese või koodi poolt), toimub päring saamiseks koordinaatori lõpp-punkti.
Koordinaator kontrollib, kas link on vahemälus olemas. Kui see on olemas ja töötab, tagastatakse see kohe kliendile, vastasel juhul küsitakse sõlmedelt olemasolu kohta.
Faili hankimine toimub lingi kaudu, kui selline leiti.

Alternatiivid muusikategijatele

Mind sempre on mindestus, kuidas üldiselt saab objektiivselt hinnata paljude loominguliste teoste hinda? Miks, näiteks, inimene paneb oma muusikalbumi hinnaks 10$? Või 20$ või 100$. Kus on algoritm? Kui me näiteks räägime mingist füüsilisest tootest või isegi paljusid teenuseid, siis saame vähemalt arvutada tootmiskulu ja sellest alustada.

Okei, oletame, et 10$ on seatud. Kas see on tõeliselt efektiivne? Oletame, et ma kuulasin albumit kuskil või seal on laul ja otsustasin tänada. Kuid minu tunnetuste ja isiklike võimaluste kohaselt on 3$ minu piir. Kuidas siis olla? Tõenäoliselt ma ei tee midagi, nagu enamik inimesi.

Müües mingi fikseeritud hinna loomingulise töö eest, piirad end lihtsalt, ei anna suuremale hulgale inimestele võimalust anda sulle väiksemaid summa, mis kokku võib olla muljetavaldavam kui need, kes ostavad sinu seatud hinnaga. Minu arust on looming just see valdkond, kus peaksid kõigepealt domineerima annetused. Selleks on vajalik:

Õpetage inimesi tänama just niimoodi. Loomehed peaksid selgelt näitama, et nad soovivad toetusi, lisama igale poole lingid erinevatele makseviisidele jne.
Vajame rohkem mehhanisme nende protsesside lihtsustamiseks ja tugevdamiseks. Näiteks luua globaalne veebisait, kuhu saab loomingut toetada autorite linkide kaudu.
Oletame, et link on umbes selline:
http://someartistsdonationsite.site/category/artist?external-info
Kui kitsendame muusikutele, siis:
http://someartistsdonationsite.com/music/miyagi?song=blabla
Esitaja peab kinnitama oma nimesildi ja sellega seotud olema.
Lisame klienti museria funktsiooni sellise lingi genereerimiseks, ja kõik projektid, mis kasutavad salvestusruumi, saavad paigutada oma veebisaitidele/rakendustesse toetuse nuppe nende lingidega koos laulude kõrval. Kasutajatel on võimalus väga kiiresti ja lihtsalt toetust teha. Loomulikult saab seda lähenemist kasutada igas projektis ja loomingukategoorias, mitte ainult salvestusruumi kaudu.

Miks on just sulle vajalik muusikaruumi, ja kuidas saad selles osaleda?

Kui töötad muusikaga seotud projekti kallal või plaanid sellise loomist, siis just selleks see kõik ongi mõeldud. Sa saad kasutada museriat laulude salvestamiseks ja hankimiseks, suurendades laulude voogu võrgus. Kui sul on samas võimalus tõsta ja hoida vähemalt üht oma sõlme, siis see oleks parim panus võrgu arengusse.
Võib-olla oled sa valmis võtma endale mõne muu rolli: aidata koodi kirjutada, täita ja modereerida baasi, levitada projekti teavet oma tuttavatele jne.
Võib-olla meeldis sulle idee ja oled valmis aitama rahaliselt, et kõik see elaks ja areneks. Mida rohkem sõlmi, seda rohkem laule.
Või vajad sa lihtsalt mingil hetkel laulu leidmiseks ja allalaadimiseks. Sa saad seda teha väga lihtsalt, näiteks läbi telegraafiboti.

Projekt on hetkel kõige algusjärgus. On käivitatud testvõrk, sõlmed võivad tihti taaskäivituda, vajada värskendusi jne. Kui hindamisperioodil ei esine kriitilisi probleeme, muudetakse see sama võrk põhivõrguks.

Välise node info vaatamiseks: laulude arv, vaba koht jne, saad külastada linki, mis näeb välja nagu http://node-address/status või http://node-address/status?pretty

Minu kontaktid:

Allikas: habr.com