Jednou jsem se rozhodl napsat aplikaci pro výběr hudby, kterou bych mohl poslouchat doma, venku, při tréninku atd. A abych to všechno mohl mít v jednom toku s minimálním zapojením z mé strany. Vymyslel jsem architekturu, nakreslil prototyp a nakonec jsem narazil na jeden "malý problém".
Ale nebylo jasné, odkud vzít samotné soubory písní. Do té doby VKontakte již uzavřelo API, na velkých hudebních portálech to také ztichlo, dokonce i písně se poskytovaly po částech, aby se nedaly parsovat. Zůstávaly pouze nějaké jednorázové weby s tuny reklamy a různými nepořádky, různé pochybené programy-grabbery a další "špinavé" varianty. Ve zkratce, žádné skutečně dobré řešení. Samozřejmě, mohu si zakoupit předplatné na nějakou Yandex Music nebo podobné. Ale opět, nikde tam není otevřené veřejné API a nemáš přístup k hudbě programově. Několik velkých společností v podstatě omezilo ostatní v přístupu k hudbě. Proč se to vůbec stalo? Když jsem se ponořil hlouběji, bylo jasné, že hlavní problém spočívá v autorských právech. Současné řešení v podobě předplatného vyhovuje mnoha komerčním autorům hudebních děl a těmto společnostem. Přitom nekomerční a podmíněně komerční hudba také patří do obecného seznamu. Buď platíš za všechno, nebo neslyšíš vůbec nic.
A začal jsem přemýšlet, co s tím vším dělat. Jak mohu organizovat volné šíření hudby? Co bych dělal, kdybych sám vytvářel hudbu a chtěl na tom vydělávat? Líbilo by se mi, kdyby se moje písně začaly šířit pirátsky? Jaké vůbec existuje alternativní řešení?
Nakonec se objevily dvě hlavní problémy, které je třeba řešit:
- Organizace volného šíření hudby pohodlnými metodami pro většinu lidí, včetně programových.
- Nabídka alternativ pro tvůrce hudby na výdělek
Globální decentralizované úložiště hudby
Zpočátku jsem se pokusil najít existující řešení a postavit vše na tohoto základu. Po určité době hledání mě jako první zaujalo . Začal jsem realizaci své myšlenky, ale po chvíli jsem zjistil několik kritických problémů s tímto řešením:
- Ipfs — úložiště pro všechno a všude. Obsahuje obrázky, hudbu, videa a cokoliv jiného. Ve zjednodušeném slova smyslu jde o velkou planetární "skládkou". Proto když spustíte svůj uzel, ihned čelíte obrovské zátěži. Stroj se doslova zmítá v bolesti.
- Jakýsi nedokončený mechanismus na shromažďování "odpadu". Nevím, jak je to teď, ale v té době, pokud jste v konfiguraci uvedli, že chcete omezit úložiště na deset gigabajtů dat, to vůbec nic neznamenalo. Úložiště se rozrůstalo, ignorujíc mnohé konfigurační parametry. Nakonec bylo nutné mít obrovský prostor na pevném disku, než IPFS přijde na to, jak se zbavit nepotřebného.
- V době používání knihovny (nevím, jak je to teď) u klienta nebyly implementovány timeouty. Pošle se žádost na získání souboru, a pokud tam není, tak prostě visíte. Samozřejmě, lidé přišli s různými obchvaty, které částečně vyřešily problém, ale byla to jen pomocná řešení. Takové věci by měly být standardně zahrnuty.
Bylo také mnoho menších problémů, dojem jsem měl tehdy jednoznačný: tohle nemůžete použít pro projekt. Pokračoval jsem v hledání úložiště, zkoumali různé možnosti, ale nakonec jsem nic vhodného nenašel.
Nakonec jsem se rozhodl, že zkusím napsat decentralizované úložiště sám. Ačkoliv se nebude ucházet o roli meziplanetárního, bude řešit konkrétní úkol.
Takto vznikly , , , , .
spreadable — je to hlavní, nejnižší vrstva, která umožňuje spojit uzly do sítě. Obsahuje algoritmus, který jsem zatím implementoval částečně pro přibližně 10 000 serverů. Plná verze algoritmu je mnohem složitější na realizaci a vyžadovala by ještě několik dalších měsíců (možná i více).
Podrobně spreadable v tomto článku popisovat nebudu, raději napíšu zvlášť někdy. Zde pouze zdůrazním některé vlastnosti:
- Funguje přes http/https.
- Je možné vytvářet samostatnou síť pro konkrétní úkol, což výrazně sníží zátěž na každý jednotlivý projekt, než kdyby byly všechny v jedné síti.
- Původně byl promyšlen mechanismus s timeouty a dalšími drobnostmi. A to funguje pro všechny metody, jak v klientovi, tak v uzlu. Lze flexibilně řídit parametry z vlastní aplikace.
- Knihovna je napsaná v nodejs. Problémy s výkonem stacku jsou kompenzovány decentralizovanou povahou. Zátěž lze "rozložit", zvýšením počtu uzlů. Na oplátku je zde mnoho výhod: obrovská komunita, jednoduchost a pohodlnost práce, izomorfní klient, absence externích závislostí atd.
storacle — to je vrstva dědící od spreadable, která umožňuje ukládat soubory v síti. Každý soubor má svůj hash podle obsahu, podle kterého jej lze později získat. Soubory nejsou rozděleny na bloky, ale uchovávají se v celku.
metastocle — vrstva dědící od spreadable, která umožňuje ukládat v síti data, ale nikoli soubory. Rozhraní je podobné nosql databázím. Můžete například přidat soubor do storacle, získat jeho hash a zapsat do metastocle s vazbou na něco.
museria — dědí od storacle a metastocle. Tato vrstva se přímo odpovídá za ukládání hudby. Úložiště pracuje pouze s mp3 soubory a id3 tagy.
Jako "klíč" k písni se používá její úplný název ve formě Interpret (TPE1) — Název (TIT2). Například:
- Brimstone — The Burden
- Hi-rez — Lost My Way (feat. Emilio Rojas, Dani Devinci)
Maximálně podrobně se lze dozvědět, jak se formují názvy písní . Je třeba se podívat na funkci utils.beautifySongTitle().
Shodou na klíčích je považováno za procento stanovené v nastavení uzlu. Například hodnota 0.85 znamená, že pokud funkce porovnání klíčů (názvů písní) zjistí podobnost větší než 85%, pak se jedná o tutéž píseň.
Algoritmus pro určení podobnosti je také tam, ve funkci utils.getSongSimilarity().
Obal k písni, pro následné získání, se také připojí přes tagy (APIC). V utilitách (utils) jsou všechny potřebné metody pro získání a zpracování tagů.
Příklad práce s úložištěm přes klienta lze vidět v .
Všechny výše uvedené vrstvy jsou samostatné a mohou být použity samostatně jako nižší vrstvy pro jiné projekty. Například již teď existuje myšlenka vytvořit vrstvu pro ukládání knih.
museria-global — to je již nakonfigurované git-repozitář pro spuštění vlastního uzlu v globální síti hudby. Klonujete, npm i && npm start a v podstatě je to všechno. Můžete nastavit podrobněji, spustit v dockeru a atd. Podrobné informace jsou na .
Když je repozitář aktualizován, musíte také aktualizovat svůj uzel. Pokud se mění hlavní nebo vedlejší číslo verze, je tento krok povinný, jinak budou staré uzly ignorovány sítí.
S písněmi lze pracovat ručně a programově. Každý uzel spouští server pro různé úkoly. Například při návštěvě výchozího koncového bodu získáte rozhraní pro práci s hudbou. Můžete například navštívit (odkaz může být později neaktuální, vstupní uzly lze také získat v , nebo sledovat aktualizace na GitHubu.
Takto můžete vyhledávat a stahovat písně do úložiště. Stahování písní může probíhat ve dvou režimech: běžném a moderovaném. Druhý režim znamená, že práci provádí člověk, nikoli program. A pokud zaškrtnete tuto volbu při přidávání, bude nutné vyřešit CAPTCHA. Písně lze přidávat s prioritami -1, 0 nebo 1. Prioritu 1 lze nastavit pouze v moderovaném režimu. Priority jsou důležité pro to, aby úložiště efektivněji rozhodovalo, co dělat, když se snažíte nahradit již existující píseň novou. Čím vyšší priorita, tím větší šance, že přepíšete existující soubor. To pomáhá bojovat proti spamu a zvyšuje kvalitu nahrávaných písní.
Pokud začnete přidávat písně do úložiště, snažte se připojit i obrázky (obaly), i když toto pole není povinné. V 99 % případů jsou první obrázky na Googlu podle názvů písní obaly alb.
Jak technicky probíhá přidávání souborů, stručně řečeno:
- Klient získá adresu volného uzlu, který se na nějakou dobu stane koordinátorem.
- Spustí se funkce přidání písně (člověkem nebo kódem), dojde k požadavku na přidání na koncový bod koordinátora.
- Koordinátor vypočítá, kolik duplicit je potřeba uchovat (konfigurovatelný parametr).
- Hledají se nejvhodnější uzly pro uložení.
- Soubor se přímo odesílá na tyto uzly.
Jak technicky probíhá získávání souborů:
- Klient získá adresu volného uzlu, který se na nějakou dobu stane koordinátorem.
- Spustí se funkce získání písně (člověkem nebo kódem), dojde k požadavku na získání na koncový bod koordinátora.
- Koordinátor kontroluje přítomnost odkazu v mezipaměti. Pokud takový existuje a je funkční, okamžitě se vrátí klientovi, jinak se dotazují uzly na přítomnost.
- Probíhá stahování souboru podle odkazu, pokud byl nalezen.
Alternativy pro hudební tvůrce
Vždy mě zajímal otázka, jak lze objektivně ocenit hodnotu mnoha tvůrčích děl? Proč například člověk stanoví cenu svého hudebního alba na 10 $? Nebo na 20 $ či 100 $? Kde je algoritmus? Když mluvíme o nějakém fyzickém produktu nebo dokonce o mnoha typech služeb, můžeme alespoň spočítat náklady a vycházet z toho.
Dobře, dejme tomu, že jsme stanovili cenu na 10 $. Je to opravdu efektivní? Představme si, že jsem poslouchal album nebo skladbu a chtěl bych poděkovat. Ale podle mých pocitů a vlastních možností je 3 $ mým stropem. A co teď? Pravděpodobně prostě nic neudělám, stejně jako většina lidí.
Stanovením nějaké pevné ceny za tvůrčí práci se jednoduše omezuješ a nedáváš větší části lidí možnost poslat ti méně peněz, které se v součtu mohou ukázat jako výraznější, než když koupí podle ceny, kterou jsi stanovil. Mělo by se mi zdát, že umění je přesně ta oblast, kde by měly primárně fungovat dary. K tomu je třeba:
- Naučit lidi dávat díky tímto způsobem. Tvůrci by to měli jasně ukazovat, že by rádi dostávali dary, přidávat odkazy na různé platební metody atd.
- Potřebujeme více mechanismů k usnadnění a posílení těchto procesů. Například vytvořit nějaký globální web, kam lze posílat dary za umění pomocí autorských odkazů.
Představme si, že odkaz vypadá asi takto:
http://someartistsdonationsite.site/category/artist?external-infoPokud to zúžíme na hudebníky, pak:
http://someartistsdonationsite.com/music/miyagi?song=blablaInterpret se musí ověřit a připojit k svému přezdívce.
Do klienta museria přidáme funkci generování podobného odkazu, a všechny projekty využívající úložiště mohou umístit na své weby/aplikace tlačítka pro dary s těmito odkazy vedle písní. Uživatelé mají možnost velmi rychle a snadno udělat dar. Tento přístup samozřejmě lze použít v jakémkoli projektu a kategorii umění, nejen prostřednictvím úložiště.
Proč, právě tobě, hudební úložiště, a jak se na tom můžeš podílet?
- Pokud pracuješ na projektu spojeném s hudbou nebo plánuješ takový vytvořit, je to přesně to, k čemu to celé bylo zamýšleno. Můžeš využít museria k uchovávání a získávání písní, což zvyšuje tok písní na internetu. Pokud máš navíc možnost vytvořit a udržovat alespoň jeden svůj vlastní uzel, bude to nejlepší příspěvek k rozvoji sítě.
- Možná jsi připraven vzít na sebe jinou roli: pomoci s kódem, nebo vyplňovat a moderovat databázi, šířit informace o projektu mezi svými známými atd.
- Možná se ti myšlenka zalíbila a jsi ochoten pomoci materiálně, aby to všechno žilo a rozvíjelo se. Čím více uzlů, tím více písní.
- Nebo možná v určitém okamžiku potřebuješ najít a stáhnout píseň. Můžeš to udělat velmi jednoduše, například přes .
Projekt je nyní ve svém nejranějším stádiu. Byla spuštěna testovací síť, uzly se často restartují, vyžadují aktualizace atd. V případě, že během hodnotícího období nebudou žádné závažné problémy, tato síť se transformuje na hlavní.
Informace o uzlu zvenčí: počet písní, volné místo atd., můžeš najít na odkazu ve tvaru http://node-address/status nebo http://node-address/status?pretty
Mé kontakty:
Zdroj: habr.com
