En dag besluttede jeg at skrive en applikation til at vælge musik til mig selv, så jeg kunne lytte til det hjemme, ude og under træning osv. Og at alt dette skulle fungere i en strøm med minimal involvering fra min side. Jeg kom op med arkitekturen, skitserede prototypen, og endte op med et „lille problem“.
Men jeg forstod ikke, hvor jeg skulle få filerne til sangene fra. På det tidspunkt havde Vkontakte allerede lukket sit API, og på de store musikportaler var der også stilstand, selv sangene blev givet i bidder for ikke at blive masseret. Der var kun nogle enkelte engangs-websteder med tonsvis af reklamer og skrald, samt forskellige tvivlsomme programmer til at grabbe og andre „snavsede“ løsninger. Kort sagt, der var ingen reelle gode løsninger. Man kan selvfølgelig købe et abonnement på Yandex Music eller lignende. Men igen, der er ikke noget åbent offentligt API, og du har ikke adgang til musikken programmæssigt. Flere store virksomheder har i bund og grund begrænset andres adgang til musikken. Hvorfor skete det hele? Da jeg dykkede dybere, blev det klart, at det primære problem ligger i ophavsretten. Den nuværende løsning i form af abonnementer tilfredsstiller mange kommercielle forfattere af musikværker og disse virksomheder. Samtidig er ikke-kommerciel og betinget kommerciel musik også med i den generelle liste. Enten betaler du for alt, eller også lytter du slet ikke til noget.
Og jeg begyndte at tænke over, hvad jeg skulle gøre med det hele. Hvordan kan man organisere frit distribution af musik? Hvad ville jeg gøre, hvis jeg selv beskæftigede mig med musikproduktion og ville tjene penge på det? Ville jeg kunne lide, at mine sange blev distribueret på piratmanér? Hvilke alternative løsninger er der overhovedet?
Resultatet er, at der er opstået to hovedproblemer, som skal løses:
- Organisering af fri distribution af musik på metoder, der er bekvemme for de fleste mennesker, herunder programmatiske.
- Tilbud af alternativer til musikskabere for at tjene penge
Globalt decentralt musiklager
Oprindeligt forsøgte jeg at finde eksisterende løsninger og skabe alt baseret på dem. Efter lidt tid med at lede, fangede det første min opmærksomhed . Jeg begyndte at gennemføre min idé, men efter noget tid opdagede jeg flere kritiske problemer med denne løsning:
- Ipfs — et lager for alt og ingenting. Her finnes bilder, musikk, videoer og hva som helst. Generelt sett er det en stor, planetarisk "søppeldynge". Derfor, når du starter din node, får du umiddelbart en enorm belastning. Maskinen lider.
- En slags uferdig mekanisme for å samle "søppel". Jeg vet ikke hvordan det er nå, men på det tidspunktet, hvis du i konfigurasjonen spesifiserte at du ville begrense lagringen til ti gigabyte data, så betydde det ingenting. Lagringen vokste, og ignorerte mange konfigurasjonsparametre. Til slutt måtte man ha en enorm mengde harddiskplass, mens ipfs klarte å kvitte seg med det unødvendige.
- På tidspunktet for bruken av biblioteket (jeg vet ikke hvordan det er nå), var det ikke implementert tidsavbrudd for klienten. Du sender en forespørsel om å motta en fil, og hvis den ikke finnes, henger du bare. Selvfølgelig fant folk på forskjellige omveier som delvis løste problemet, men dette var bare nødløsninger. Slike ting bør være innebygget.
Det var også mange små problemer, og inntrykket som ble dannet var entydig: dette kan ikke brukes til prosjektet. Jeg fortsatte letingen etter lagring, undersøkte forskjellige alternativer, men fant ingen passende.
Til slutt bestemte jeg meg for å prøve å skrive et desentralisert lagringssystem selv. La det ikke være interplanetært, men det vil løse den spesifikke oppgaven.
Slik ble det til , , , , .
spreadable — er det primære, laveste laget som gjør det mulig å koble noder til et nettverk. Det inneholder en algoritme som jeg per nå har implementert delvis med tanke på omtrent 10000 servere. Den fullstendige versjonen av algoritmen er mye mer komplisert å implementere og ville krevd flere måneder til (kanskje mer).
Jeg vil ikke gå i detalj om spreadable i denne artikkelen, men heller skrive en egen senere. Her vil jeg bare nevne noen spesielle trekk:
- Det fungerer via http/https.
- Du kan opprette et eget nettverk for en spesifikk oppgave, noe som betydelig vil redusere belastningen på hvert enkelt prosjekt, sammenlignet med hvis de alle var i ett nettverk.
- Mekanismen med tidsavbrudd og andre detaljer var opprinnelig planlagt. Og det fungerer for alle metoder, både i klienten og i noden. Du kan fleksibelt administrere parametrene fra din applikasjon.
- Biblioteket er skrevet i Node.js. Problemer med ydeevnen bliver kompenseret af den decentrale natur. Belastningen kan 'spredes' ved at øge antallet af noder. Til gengæld er der mange fordele: et stort fællesskab, enkelhed og brugervenlighed, isomorfisk klient, fravær af eksterne afhængigheder osv.
storacle — er et lag, der nedarves fra spreadable, som muliggør lagring af filer på netværket. Hver fil har sin egen hash baseret på indholdet, som den senere kan hentes på. Filerne opdeles ikke i blokke, men opbevares hele.
metastocle — et lag, der nedarves fra spreadable, som tillader lagring af data i netværket, men ikke filer. Grænsefladen minder om NoSQL-databaser. Man kan for eksempel tilføje en fil til storacle, få dens hash og skrive den i metastocle med tilknytning til noget.
museria — nedarves fra storacle og metastocle. Dette lag er direkte ansvarligt for opbevaring af musik. Lagringen arbejder kun med mp3-filer og ID3-tags.
Som 'nøgle' til sangen bruges dens fulde navn i form af Kunstner (TPE1) — Titel (TIT2). For eksempel:
- Brimstone — The Burden
- Hi-rez — Lost My Way (feat. Emilio Rojas, Dani Devinci)
Man kan få en maksimal detaljeret forståelse af, hvordan sangtitler dannes . Man skal kigge på funktionen utils.beautifySongTitle().
Et match af nøgler defineres som en bestemt procentdel indstillet i nodens indstillinger. For eksempel betyder værdien 0,85, at hvis sammenligningsfunktionen for nøgler (sangtitler) finder lighed på mere end 85%, så er det den samme sang.
Algoritmen til at bestemme ligheden findes også der, i funktionen utils.getSongSimilarity().
Coveret til sangen, til senere opnåelse, skal også knyttes gennem tags (APIC). I værktøjerne (utils) findes alle nødvendige metoder til at hente og behandle tags.
Et eksempel på arbejdet med lageret gennem klienten kan ses i .
Alle de ovennævnte lag er selvforsynende og kan bruges særskilt som lavere lag i andre projekter. For eksempel er der allerede nu tanker om at lave et lag til opbevaring af bøger.
museria-global — er et allerede konfigureret git-repositorium til at starte sin egen node i det globale musiknetværk. Klon det, npm i && npm start, og det er stort set det hele. Man kan konfigurere det mere detaljeret, starte det i Docker osv. Der er detaljeret information tilgængelig på .
Når et repository opdateres, skal din node også opdateres. Hvis hoved- eller minorversionsnummeret ændres, er denne handling obligatorisk, ellers vil ældre noder blive ignoreret af netværket.
Du kan arbejde med sange både manuelt og programmatisk. Hver node starter en server til forskellige opgaver. Når du besøger den standard endpoint, får du en brugergrænseflade til at arbejde med musik. For eksempel kan du besøge (linket kan være forældet senere, indgangsnoder kan også fås i , eller du kan se opdateringer på GitHub).
På den måde kan du søge og downloade sange til lageret. Upload af sange kan finde sted i to tilstande: normal og modereret. Den anden tilstand betyder, at arbejdet udføres af et menneske og ikke et program. Hvis du sætter dette flueben ved tilføjelse, skal du løse en captcha. Sange kan tilføjes med prioriteter -1, 0 eller 1. Prioritet 1 kan kun sættes i den modererede tilstand. Prioriteterne er nødvendige, så lageret kan træffe en mere effektiv beslutning om, hvad der skal gøres, når du forsøger at erstatte en eksisterende sang med en ny. Jo højere prioritet, desto større sandsynlighed for at du overskriver den eksisterende fil. Dette hjælper med at bekæmpe spam og øger kvaliteten af de uploadede sange.
Hvis du begynder at tilføje sange til lageret, skal du forsøge at vedhæfte billeder (cover), selvom dette felt ikke er obligatorisk. I 99 % af tilfældene er de første billeder i Google, når man søger med sangtitler, albumcovers.
Hvordan filerne teknisk tilføjes, i grove træk:
- Klienten modtager adressen til en ledig node, som i et stykke tid vil blive koordinator.
- Funktionen til at tilføje en sang (af et menneske eller kode) udløses, forespørgslen sendes til koordinatorens endpoint.
- Koordinatoren beregner, hvor mange duplikater der skal gemmes (konfigurerbar parameter).
- De mest passende noder til opbevaring findes.
- Filene sendes direkte til disse noder.
Hvordan filer teknisk hentes:
- Klienten modtager adressen til en ledig node, som i et stykke tid vil blive koordinator.
- Funktionen til at hente en sang (af et menneske eller kode) udløses, forespørgslen sendes til koordinatorens endpoint.
- Koordinatoren tjekker, om der er en link i cachen. Hvis der er, og det fungerer, returneres det straks til klienten, ellers forespørges noderne om deres tilgængelighed.
- Filen hentes fra linket, hvis et sådant findes.
Alternativer for musikskabere
Jeg har altid været interesseret i, hvordan man objektivt kan vurdere prisen på mange kreative værker. Hvorfor sætter en person for eksempel sit musikalbum til 10$? Eller 20$ eller 100$. Hvor er algoritmen? Når vi taler om et fysisk produkt, eller endda mange typer tjenester, kan vi i det mindste regne omkostningerne og tage udgangspunkt i det.
Okay, lad os sige, at prisen er sat til 10$. Er det effektivt? Lad os sige, at jeg har lyttet til et album et sted eller en sang derfra og besluttede at give lidt som tak. Men efter min egen opfattelse og mine egne muligheder er 3$ mit loft. Hvad gør man så? Sandsynligvis vil jeg bare ikke gøre noget, ligesom de fleste mennesker.
Ved at sætte en fast pris for kreativt arbejde begrænser man sig selv, man giver ikke et større antal mennesker mulighed for at sende lesser beløb, som i sum kan være mere imponerende end dem, der køber til den pris, man har fastsat. Jeg mener, at kreativitet netop er det område, hvor donationer først og fremmest skal være styrende. For dette kræves der:
- At lære folk at takke på denne måde. Skaberne skal tydeligt vise, at de ønsker at modtage donationer og tilføje links til forskellige betalingsmetoder overalt.
- Der skal være flere mekanismer til at forenkle og styrke disse processer. For eksempel at oprette et globalt website, hvor man kan donere for kreativitet ved hjælp af forfatterlinks.
Lad os sige, at linket ser ungefär sådan ud:
http://someartistsdonationsite.site/category/artist?external-infoHvis vi snæver det ned til musikere, så:
http://someartistsdonationsite.com/music/miyagi?song=blablaKunstneren skal verificere sit kaldenavn og knytte det til sig.
I klienten museria tilføjer vi en funktion til at generere et sådant link, og alle projekter, der bruger lageret, kan placere donation buttons med disse links på deres websites/appliceringer ved siden af sangene. Brugerne har mulighed for hurtigt og let at donere. Naturligvis kan denne tilgang anvendes i ethvert projekt og kreativ kategori, ikke kun gennem lageret.
Hvorfor, netop for dig, er musiklageret vigtigt, og hvordan kan man deltage i det?
- Hvis du arbejder på et projekt relateret til musik, eller planlægger at oprette et, så er det hele blevet tænkt i den retning. Du kan bruge museria til at gemme og hente sange, hvilket øger strømmen af sange online. Hvis du desuden har mulighed for at oprette og vedligeholde mindst én egen node, vil det være det bedste bidrag til udviklingen af netværket.
- Måske er du klar til at påtage dig en anden rolle: hjælpe med koden, eller udfylde og moderere databasen, sprede information om projektet til dine bekendte osv.
- Måske kunne du lide idéen, og du er klar til at støtte økonomisk, så dette kan eksistere og udvikle sig. Jo flere noder, jo flere sange.
- Eller måske får du bare behov for at finde og downloade en sang på et tidspunkt. Du kan gøre dette meget enkelt, for eksempel via .
Projektet er i øjeblikket i den tidlige fase. Testnettet er startet, noderne kan ofte genstarte, kræve opdateringer osv. Hvis der ikke opstår kritiske problemer i løbet af evalueringsperioden, vil dette net transformeres til hovednettet.
Du kan se information om en node udefra: antallet af sange, ledig plads osv. ved hjælp af et link i formatet http://node-address/status eller http://node-address/status?pretty
Mine kontaktoplysninger:
Kilde: habr.com
