Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori Oggi ho un super ospite come spesso in queste settimane ma questo è veramente un super super ospite quindi prima di annunciarlo il mio compito è quello di ricordarvi rapidamente i nostri contatti info@gitbar.it o @brainrepo sono i modi canonici quelli che non utilizza nessuno per registrare registrare.Io tra l'altro mi sono dimenticato di lanciare la registrazione di Fallback quindi voi state sentendo questa cosa e io in questo momento ho cliccato rec.Dicevo i modi canonici sono info@github.it @brainrepo su twitter e poi il nostro gruppo telegram che si sta avvicinando inesorabile agli 800 iscritti.Ma siamo ancora pochi perché io vedo gli ascolti del podcast quindi c'è ancora qualcuno che ci ascolta qualche centinaia di persone che ci ascolta che non si è ancora scritto il gruppo telegramma allora cosa aspettate detto questo vi presento il super ospite di oggi benvenuti su github il podcast dedicato al mondo dei full stack developer i mezzo artigiani mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Parliamo di una rock star poco conosciuta in Italia in realtà, ma il cui lavoro gira su tanti tool che usiamo tutti i giorni.Parliamo infatti di Lorenzo Miniero, uno dei founder e dei creatori di Janus Server.Ciao Lorenzo! Ciao ciao, grazie per l'invito.Guarda, grazie a te per essere venuto.È da tempo che cerco qualcuno che ci illumini, ci spieghi, ci faccia capire bene o comunque ci faccia capire come funziona WebRTC e chi meglio di te può aiutarci in questo percorso anche perché noi siamo umili software engineer che vengono buona parte dal web quindi è un argomento quasi mistico per noi webRTC no? è un argomento quasi mistico per per parecchie persone quindi in realtà si è una è una tecnologia particolare che però mi ha affascinato sin dal primo momento anche perché io vengo da un da un background un po' più VoIP più che di web development e quindi diciamo è stata una un'evoluzione interessante delle tecnologie di comunicazione in tempo reale sicuramente.Ma la domanda è come è iniziato tutto cioè come è partita questa esplorazione verso il mondo VoIP e poi questo protocollo e quali sono le difficoltà che hai avuto nell'entrare in questo mondo? Sì, il mio background era principalmente appunto nelle tecnologie di comunicazione in tempo reale quindi soprattutto in ambito VoIP perché quando mi sono laureato parecchi parecchi anni fa io lavoravo su ad esempio su applicazioni tipo asterisk quindi centralini telefonici per realizzare applicazioni di audio e videoconferenza quindi quello è quello sul quale feci la tesi, lavorando con un ente di standardizzazione per implementare di nuovo i protocolli e quindi questo era diciamo il nostro contesto principale quindi lavorare nell'ambito di videoconferenze utilizzando protocolli standard che uscissero dagli etf, l'internet engineering task force e quindi protocolli come SIP, RTP e quant'altro che chi ha familiarità con il VOIP conosce sicuramente.Il problema di queste tecnologie appunto era che come tutte le applicazioni di comunicazione in tempo reale li chiedevano soprattutto qualche tempo fa un'applicazione nativa quindi o avevi un telefono hardware o dovevi installarti un soft phone ad esempio un 3cx o un qualcosa del genere per farti la videochiamata VoIP.Li ricordo avevano delle UI inguardabili.Esistono ancora le UI sono ancora altrettanto inguardabili però appunto il problema era appunto quello che ti serviva proprio un'applicazione nativa per fare questo e quindi ad esempio se volevi farti la videoconferenza ad esempio semplicemente nel browser dovevi per forza di cose crearti un plugin nativo per il browser per comunicare quindi era il motivo per il quale tutti utilizzavano flash ad esempio all'epoca utilizzavano software come red5 o altri per realizzare scenari di videoconferenza ma appunto il problema principale era appunto la necessità di avere questo plugin installato nel browser che per tutti significava un lavoro enorme perché appunto macromedia per fare il plugin flash doveva fare 100 versioni diverse del plugin per almeno tre sistemi operativi diversi poi magari a 32 a 64 bit poi magari come gestisci le applicazioni mobile insomma si usciva pazzi poi chi non lo faceva con flash magari lo faceva con le applet java, era un casino e quindi per cercare di realizzare, di fare quello che lo scenario più semplice possibile una semplice videochiamata nel browser gli enti di standardizzazione hanno cominciato a pensare ma perché non proviamo a realizzare delle api più semplici quindi invece di dover utilizzare un'applicazione nativa mettiamo tutto il cuore, i protocolli all'interno del browser e poi esponiamo delle api come facciamo per tutto il resto del mondo web quindi ad esempio se ci pensi web midi, web audio, sono tutte tecnologie che con il web hanno se vogliamo poco a che fare però in realtà sono cose che adesso tramite API web puoi utilizzare in maniera molto semplice e quindi diciamo che era nato così quindi loro volevano semplicemente realizzare una sorta di clone di skype però all'interno all'interno del browser e quindi che fosse utilizzabile semplicemente con delle API javascript e quindi molto semplice per sviluppatori web da utilizzare ma anche molto semplice realizzare applicazioni più carine configurabili e modulari utilizzando semplicemente delle...avvantaggiandoti di tutto il mondo web e del mondo VoIP allo stesso momento che è il cuore principale della della problematica di WebRTC è che appunto una sorta di Frankenstein di due mondi che fino a quel momento avevano avuto poche interazioni perché hai il mondo VoIP che ha tutti i suoi protocolli che sono molto complessi e diciamo tutti i protocolli per trovare un modo per metterti in contatto per scambiare pacchetti in tempo reale per codificare e riprodurre qualcosa in real time e così via e dall'altro il mondo web che ha le sue complessità e che invece ha delle sue caratteristiche anche per quanto riguarda le comunicazioni perché diciamo per uno sviluppatore web ha più senso fare riferimento ad una ad esempio una specifica porta per comunicare con un web server con una tecnologia di tipo VoIP invece parti dal presupposto che due entità possono mettersi in comunicazione peer-to-peer fondamentalmente che è esattamente il modo in cui nacque WebRTC all'epoca e quindi ci sono problematiche diverse per come mettere in contatto due utenti e quindi diciamo che sin dal primo momento questo è stato il problema principale cioè far capire agli sviluppatori web cosa era questa specie di mostro dal cuore VoIP che stava cercando di entrare nel mondo web e allo stesso tempo per gli sviluppatori VoIP che avevano una formazione di tipo completamente diverso cercare di approcciarsi al mondo web che è appunto molto piastruso per chi non ci ha mai avuto a che fare.Quindi questa è stata un po' la sfida principale da questo punto di vista.Hai risvegliato dei ricordi che ormai erano quasi assopiti, mi hai ritirato fuori il Red 5 che era uno dei miei primi tentativi di tirar su una web tv utilizzandolo.Ricordo all'epoca si utilizzava tantissimo anche Silverlight di Microsoft con quell'obiettivo.E di Java c'era java effects forse, comunque qualcosa del genere sul browser insomma era un macello poi arriva zio steve jobs inizia ad ammazzare flash segue una ruota gli altri e quindi i browser si adattano.La prima domanda che volevo farti è quanto in realtà la facilità di utilizzo della parte web api è stata il successo di webRTC? è difficile rispondere perché in realtà le api di webRTC sono un po' più complesse di quello che dovrebbero essere perché sono state un successo parziale diciamo che giusto per spiegare un po' la storia di WebRTC e come funziona diciamo che è stato il lavoro congiunto di due enti di standardizzazione diversi da un lato hai l'IETF che è appunto l'ente di standardizzazione che standardizza tutti i protocolli di rete quindi quello che si scambia su internet proprio dal punto di vista protocollare e quindi loro si sono occupati di tutta la parte del core e VoIP di WebRTC quindi che protocolli si utilizzano, come li metti in comunicazione, come negozi una sessione tutte queste problematiche e assieme all'IETF il W3C che è quello che si occupa di tutta la parte di standardizzazione delle API web invece e quindi loro si sono occupati di come interfacciarti al motore web RTC che vive nel browser utilizzando appunto delle API fatte in javascript utilizzando un approccio che si chiama JSEP e quindi diciamo che il il tentativo principale era quello di portare avanti questi due sforzi paralleli e realizzati in maniera separata con l'idea di realizzare qualcosa che poi convergesse alla fine il problema è che la natura dei protocolli di webartistia del web in generale è sufficientemente complessa che non è stato abbastanza semplice realizzare delle API che fossero veramente semplici da utilizzare anche in ambito web che pure è uno dei motivi principali per il quale alcuni sviluppatori web hanno difficoltà con WebRTC perché diciamo ci sono c'è bisogna capire ad esempio come funziona il concetto di negoziazione di una sessione WebRTC che è un concetto che non ha molti eguali nell'ambito del web proprio perché è un paradigma completamente diverso dove tu fai un'offerta e ricevi una risposta questa offerta e risposta devono essere matchate in qualche modo scambi altre informazioni e alla fine ottieni una sessione multimediale di qualche tipo questo tipo di paradigma è un tipo di paradigma che gli sviluppatori web non hanno mai utilizzato comunque raramente utilizzano perché anche quando si utilizzavano appunto software come dicevi red5 o silverlight eccetera per realizzare comunicazioni in tempo reale erano sempre realizzate in maniera diversa, tu facevi riferimento ad un server e semplicemente creavi degli stream e li smistavi in giro dal punto di vista di WebRTC puoi fare le stesse cose ma devi calarti in una mentalità che è abbastanza diversa quindi sicuramente però diciamo che da un lato c'è c'è il fatto che comunque queste API WebRTC sono un po più complesse quindi devi calarti un po' nella mentalità però sono sicuramente approcciabile quindi sicuramente la possibilità di poter realizzare in maniera semplice una videochiamata, una videoconferenza o una qualsiasi altra applicazione in tempo reale all'interno del browser senza doverti implementare tu tutti i protocolli è stato sicuramente un incentivo enorme per gli sviluppatori insomma per cercare di sporcarsi le mani e capire un po' come funzionava e diciamo è alla radice del successo di WebRTC se vogliamo perché ad esempio anche noi in questo momento stiamo per realizzare questo podcast stiamo utilizzando un'applicazione che usa WebRTC che significa che non abbiamo dovuto installare dei client particolari, lo zoom della situazione così via, tutte e due abbiamo aperto un browser adesso stiamo chiacchierando fra di noi e funziona tutto magicamente quindi questo è una evoluzione è enorme rispetto a dieci anni fa dove appunto dovevi installarti 100 plugin diversi preoccuparti di problemi di sicurezza di flash che chissà che stava combinando sulla sulla tua macchina e così via adesso hai un motore molto potente flessibile all'interno del browser e puoi lavorarci e farci un po quello che vuoi domanda prima di chiederti magari di fermarci una di e provare a raccontarci con parole un po' alla nostra altezza come funziona WebRTC quindi dovrei proprio fare un WebRTC 101 for dummies ma sono sicuro che riuscirai nell'obiettivo.Volevo chiederti, c'hai anticipato che WebRTC ha una pletora di utilizzi, abbiamo parlato delle applicazioni di videoconferencing, hai citato alcune attività di simil broadcasting e la domanda è tra tutte questo tipo di applicazioni ce n'è qualcuna strana molto particolare che ti viene in mente? Tra l'altro saluto anche Luca che si unitò alla nostra chiacchierata.Ciao Luca.Ciao, a pene il tempo, ormai questo bar è come casa mia entro ed esco quando mi pare.Web Artistici, ho appena chiesto a Lorenzo se hai in mente degli usi strani del protocollo, un po' diversi o comunque particolari rispetto alla classica applicazione di videoconferencing e di broadcasting.Sì ci sono ci sono parecchi casi d'uso e diciamo dal punto di vista personale ne ho incontrati parecchio anche perché il software che abbiamo realizzato Janus è nato appunto come un software se vogliamo un po general purpose e quindi che si presta a parecchi usi diversi e questo ha stuzzicato l'interesse di parecchi sviluppatori quindi parecchi degli utilizzi diciamo poco ortodossi che ho visto di Janus sono venuti proprio da utenti che utilizzavano in maniera poco ortodossa e sicuramente non in modi che avevo previsto che sarebbe stato utilizzato.Ci sono parecchi casi d'uso interessanti perché, per esempio, hai citato, ci sono i scenari un po' tradizionali come il videoconferencing, il VoIP, il broadcasting e così via, però c'è stata una forte componente gaming negli ultimi anni anni perché per esempio Stadia utilizza se vogliamo WebRTC dietro le quinte che comunque è una cosa una cosa parecchio interessante perché appunto ci permette di videogiocare con bassissima latenza in streaming che è una cosa che fino a poco tempo fa si credeva poco possibile ma ci sono anche scenari poi particolari perché per esempio c'è stato c'è stato Mozilla che lo utilizzava per fare realtà aumentata o virtual reality o cose del genere ci sono scenari di internet of things ci sono altre applicazioni, non so se conoscete applicazioni alla gather town dove vai in giro con questo omino in pratica immaginatevi un mondo tipo il gioco del super nintendo dove hai l'omino che va in giro e per ogni omino che vedete in realtà un partecipante che sta girando in questo mondo virtuale appena ti avvicini ad un tot di persone parte una piccola videoconferenza nell'auto insomma in pratica giri in questo mondo virtuale per chiacchierare con le persone questo è un altro caso d'uso dove webRTC è utilizzato parecchio ma anche scenari musicali e così via.In questo caso, questa è una mia curiosità, webRTC è utilizzato per la parte di conferenza quando ti avvicini quindi per la parte di stream ma anche per la distribuzione dell'informazione della posizione degli omini o quell'informazione viaggia su un altro canale? diciamo c'è la possibilità di fare entrambe le cose perché quello che non tutti sanno è che webRTC nasce soprattutto per la trasmissione di audio e video in tempo reale però ha anche il concetto di data channel e il data channel ti permette di creare un canale di comunicazione sempre peer-to-peer dove però puoi trasmettere dati di tipo arbitrario quindi può essere testo può essere dato binario e così via che significa che lo puoi utilizzare come ad esempio un'alternativa alle websocket ma che viaggia sullo stesso canale di audio e video per trasmettere altre informazioni quindi ci sono alcuni che lo usano per trasportare informazioni collaterali allo stream audio e video quindi ad esempio potrebbe essere dei sottotitoli in tempo reale, caption o qualche altra cosa può essere informazioni di geolocalizzazione può essere qualsiasi tipo di informazione che puoi inviare diciamo che in linea di principio è un qualcosa che puoi mettere ad esempio c'era uno sviluppatore giapponese che utilizzava qualcosa di simile per per fare lo streaming di lui che suonava con una tastierina e in pratica poi questa tastiera era collegata a un sintetizzatore poi mandava in streaming l'audio sintetizzato però assieme all'audio sintetizzato e al suo video che suonava mandava anche le informazioni midi delle note che stava suonando e quindi chi riceveva lo stream poteva ricostruire proprio sulla tastellina virtuale i tasti che erano suonati e cose del genere.Sì, sì, ci sono parecchie possibilità da questo punto di vista.Io vengo da un mondo musicale, un eone fa, una vita e mezzo fa, e per un attimo ho immaginato tu a casa tua, io a casa mia, tu che mi mandi lo stream, lo stream media e non so se si può sincronizzare in qualche modo, io che ci attacco il mio plugin e tu che mi suoni i miei sample.Vabbè qua rischiamo di fare notte perché su questo potrei parlarne per ore, anche perché non so se conoscete FOSDEM, FOSDEM è una delle conferenze sull'open source più famose in Europa e un paio anni fa ho fatto una presentazione proprio su come usare WebRTC per la musica in generale quindi partiva proprio dal presupposto, la maggior parte degli utilizzi di WebRTC sono quelli là un po' più tradizionali, tra virgoletti noiosi, perché non utilizzarlo anche invece in scenari di entertainment, come possiamo aiutare i musicisti con WebRTC che quindi può essere semplicemente come mandiamo in streaming un concerto in tempo reale, come facciamo lezioni musicali con WebRTC, ma anche come suoniamo insieme con WebRTC, oppure come facciamo un concerto però permettendo l'interazione con un audience da casa, quindi tutti questi scenari che diciamo sono dal mio punto di vista parecchi interessanti anche perché diciamo io sono un musicista molto molto amatoriale quindi mi piace scrivere musica e lavorare con la musica e quindi diciamo quando posso cerco di cercare di mettere insieme questi due mondi.Infatti realizzai anche un piccolo prototipo di un'applicazione di Jam Session fatta in WebRTC che diciamo è ancora lì come progettino nel cassetto ma spero prima o poi di riprenderlo per fare qualcosa di simile a quello che ipotizzavi.Dai, vero, bellissimo.Mi è sembrato di vedere proprio oggi un tool che da browser permetteva lo scambio di file all'interno della stessa rete locale tra più macchine.Stavo cercando un modo per passarmi i file dal Mac alla macchina arch senza installare niente e mi è sembrato di vedere qualcosa del genere in quel caso L'approccio classico prevederebbe l'utilizzo del data channel come dicevi prima Sì in quel caso soprattutto se è effettivamente peer-to-peer e poi su questo magari torniamo fra un minuto perché diciamo la il concetto di peer-to-peer è uno di quei concetti che confondono un po' un po gli utenti soprattutto quando c'è un server di mezzo Nel caso del Peer to Peer è uno dei possibili utilizzi dei Data Channel magari hai bisogno di un web server di riferimento solo per permetterti di metterti in comunicazione con l'altro peer quindi per scambiarti informazioni di segnalazione per scambiarti le informazioni di creazione della sessione ma una volta che vi siete trovati poi create il canale peer to peer del web server, me lo potete dimenticare se vogliamo e quindi in questo caso i Data Channel ti possono aiutare per trasferire dati peer-to-peer fra i due utenti nella stessa rete o anche in reti diversi se hanno modo per mettersi in contatto fra di loro direttamente fra loro quindi senza necessità di fare ad esempio prima l'upload di un server da qualche parte e poi il download dall'altra parte Abbiamo parlato di WebRTC come protocollo peer-to-peer e poi abbiamo parlato un paio di volte di server e già io mi sono perso perché per me il concetto di server io sono abbastanza ignorante in termini diretti, ho passato gli esami non so come all'università quindi ammetto la mia completa ignoranza però mi confonde no? perché se parliamo di peer-to-peer io immagino due pari che si scambiano i pacchetti senza la necessità di un server però poi vedo Janus Server e mi dico ma se WebRTC è un protocollo peer-to-peer qual è il ruolo del server? per cui la mia domanda è come funziona alla fine il protocollo e eventualmente qual è il ruolo che il server gioca in questa visione complessiva? Per spiegare questo devo fare un piccolo passo indietro come ti dicevo il cuore di WebRTC nasce comunque dal VoIP e in ambito VoIP avevi il famoso concetto cosiddetto trapezoide dove diciamo ipotizzandolo in maniera più semplice hai due entità che vogliono parlare fra di loro quindi ad esempio immaginati un chiamante un chiamato tu che vuoi chiamare ad esempio luca al telefono e se tu vuoi chiamare luca al telefono di solito funzionava che tu hai un certo indirizzo di luca per comunicare però per parlare con luca mi fai una richiesta di segnalazione verso un server di riferimento, il server di riferimento contatta Luca, vi scambiate delle informazioni tramite questo canale e poi alla fine diciamo queste informazioni vi permettono alla fine di creare un canale di comunicazione diretto per scambiarvi i pacchetti audio video e così via e diciamo che questo è il concetto molto ad alto livello di come si stabilisce una sessione in ambito VoIP se sostituisci il server di segnalazione del VoIP con un web server diciamo già sei un passo più vicino a capire WebRTC perché in questo caso se io voglio chiamare te ad esempio farò riferimento ad un web server perché ho bisogno di un canale di segnalazione diciamo pubblicamente raggiungibile in qualche modo io invierò delle informazioni al server, il server le invierà a te, tu invierai una risposta il server le invierà a me e ci siamo scambiati delle informazioni in questo modo e quindi da questo punto di vista io e te siamo due peer che vogliono comunicare e facciamo riferimento ad un web server per la comunicazione e diciamo non approfondire troppo il concetto, cioè cosa ci scambiamo può diventare un po' troppo tecnico un po' troppo noioso diciamo che proprio per spiegarlo in parole semplici diciamo ci sono uno scambio di informazioni di negoziazione quindi ad esempio si parte sempre dal concetto di offerta e risposta offer answer viene chiamato quindi uno dei due peer fa sempre una offer e l'altro peer farà la answer e diciamo che il concetto di base è che io nella mia offer descriverò il tipo di sessione che voglio fare quindi ti dico magari voglio fare una videochiamata quindi voglio un canale audio e voglio un canale video in questa mia descrizione di sessione dirò anche per l'audio supporto il codec opus il codec g711 per il video supporto vp8 e h264 queste sono le mie opzioni di comunicazione questa è la sessione che io vorrei fare questo oggetto tramite il web server arriva a te tu crei una risposta che diciamo cerca di matchare questa offerta quindi magari io ti ho offerto audio e video tu il video non lo vuoi quindi magari dici no facciamo una chiamata solo audio ad esempio io ti ho offerto opus e g711 per l'audio ti dici io supporto solo opus e g711 non lo voglio perché la qualità del telefono non mi piace mi manderai una risposta io ricevo questa risposta dove c'è solo audio e c'è la scelta specifica del codec che abbiamo deciso di utilizzare questo ha creato una negoziazione fra di noi quindi anche da questo punto di vista questo è un concetto che è un po' diverso da come funziona di solito nel mondo del web development dove diciamo ci sono risorse un po più definite con le quali lavorare in questo caso hai invece una comunicazione di tipo molto più fluido quindi hai delle capability da entrambe le parti che in qualche modo devono convergere devono essere matchate per creare la specifica sessione e quindi diciamo che una volta che abbiamo creato questo canale di comunicazione lato signaling quindi semplicemente per comunicazione di che comprende anche informazioni di raggiungibilità quindi magari io ti dico tutti gli indirizzi IP al quale sono raggiungibili tu fai lo stesso i nostri browser poi utilizzano queste informazioni per provare a mettersi in contatto per provare a metterci in contatto direttamente alla fine una volta che questo è stato fatto creiamo un canale di nuova reazione per tupire e quindi ci scambiamo audio in tempo reale in questo caso solo audio perché magari abbiamo scartato il video diciamo che una delle delle cause principali di confusione come dicevi appunto il concetto di peer in questo caso e dal punto di vista di webrtc il peer non è altro che un endpoint che conosce i protocolli webrtc e che sa parlare come un endpoint webrtc si aspetta che debba parlare quindi in parecchi casi il browser è un peer però non è detto che sia l'unico peer un altro dei peer con i quali puoi comunicare potrebbe essere un altro implementazione di webRTC che non è un browser che può essere un server che può essere magari una videocamera che supporta webRTC nativamente e così via quindi webRTC ti mette a disposizione la possibilità di mettere in comunicazione due peer ma se uno dei peer è il server questo ti apre più opportunità perché in questo caso io sto creando un canale di comunicazione col server se altri fanno lo stesso il server può in qualche modo metterci in contatto fra di noi che significa che una chiacchierata tipo quella che stiamo facendo noi dove ci sono tre flussi diversi che stanno comunicando fra di loro in questo caso noi non stiamo realizzando una comunicazione peer-to-peer effettivamente non stiamo creando una full mesh fra di noi ma stiamo facendo tutti riferimento allo stesso server e quindi creiamo varie comunicazioni peer-to-peer fra noi ed il server tutti noi tre facciamo la stessa cosa e su questi canali peer-to-peer che sono stati creati poi viaggiano effettivamente i dati e vengono rimbalzati dal server e quindi redirezionati dove devono andare quindi da questo punto di vista diciamo l'utilizzo di un server di mezzo ti permette di realizzare topologie più complesse di quelle che potresti fare solo con la topologia peer-to-peer tradizionale perché chiaramente è impossibile fare una conferenza con mille persone facendola tutta peer-to-peer senza un server di appoggio perché nessuno ha la banda per inviare il proprio video mille volte a mille persone diverse diciamo lo mandi una volta sulla dun server e poi il server si preoccupa di smistare il tutto quindi in questo caso il peer-to-peer ti permette di creare vari hop di comunicazione vari salti che arrivano al server il server poi si preoccupa di smistare secondo logiche che possono essere diverse perché anche da questo punto di vista le topologie di comunicazione possono essere diverse che può essere una conferenza dove il video viene solo girato, una conferenza dove il video invece viene mixato e poi girato agli altri può essere una comunicazione molti a molti, uno a molti, uno ad uno diciamo da questo punto di vista ci sono proprio la vastità e la diversità di utilizzi delle varie topologie che hai a disposizione è proprio uno dei vantaggi principali di WebRTC perché una volta che ti sei calato un po' nella mentalità di "posso creare ogni tipo di topologia che mi interessa" diventa più semplice mapparlo ad uno specifico caso d'uso che hai in mente quindi immaginavamo ad esempio lo scenario di broadcasting è uno scenario dove c'è uno stream che viene pubblicato e poi viene distribuito potenzialmente a milioni di utenti in questo caso significa io pubblico uno stream verso il server il server magari fa a cascata, lo mette a disposizione di altri server arriva a 100 o 1000 server diversi, i miei utenti li faccio collegare ad uno qualsiasi di questo server e quindi l'unico stream che avevo pubblicato diventa uno stream disponibile ad una platea infinitamente più ampia di utenti che potrei servire utilizzando semplicemente i browser senza alcun server di mezzo e quindi diciamo il tutto si moltiplica e si applica anche a tutti i diversi casi d'uso che puoi realizzare con WebRTC in genere Non so se mi sono spiegato abbastanza bene o se è tutto più complesso.Non ti sento però scusami, penso che stiai uto.Oh sorry.È stato abbastanza chiaro.Ti riprendi che sei riuscito a generare un'immagine e per me quando si riesce a generare un'immagine la comprensione è molto più semplice.per un attimo se luca non ha domande farti una domanda relativa proprio all'ambito broadcasting io immagino che il broadcasting possiamo farlo prendendo uno stream web rtc ma volendo il nostro server può anche poi dispacciare altri protocolli quindi prendere quello come ingresso fare una certa conversione non so immaginare come e poi uscire con altri protocolli e la mia domanda è che differenza o quali sono le peculiarità di WebRTC, Dash o HLS? Sì, diciamo che soprattutto Dash, HLS e così via, quelli sono i protocolli che dal punto di vista tradizionale sono quelli più utilizzati in assoluto in ambito del broadcasting perché sono quelli che utilizzano ad esempio Twitch youtube live e così via quindi diciamo che sono gli sicuramente gli standard de facto utilizzati dovunque e diciamo che hanno una propria letteratura insomma alle spalle insomma c'è un sacco di lavoro che ha permesso poi di realizzare architetture molto scalabili da questo punto di vista lo svantaggio principale almeno dal mio punto di vista di queste tecnologie sono i delay perché diciamo che sono tecnologie che funzionano benissimo tramite l'uso di cdn ti permettono di scalare a milioni di utenti con facilità però diciamo sotto un tot di secondi non ci vai mai quindi è il motivo per il quale se guardi la partita su su nauti vuo su da zone sei sempre 30 secondi o un minuto dietro anche se stai effettivamente guardando qualcosa che in teoria dovrebbe essere in tempo reale quindi magari tu guardi la partita poi c'è il pub sotto casa che la guarda in diretta la gente esulta e tu stai ancora 30 secondi fa insomma e ti girano un po' le scatole se vogliamo.Infatti questo fu il motivo principale per il quale io cominciai a lavorare proprio su questi argomenti per la mia tesi di dottorato all'epoca.Quindi all'epoca stavamo lavorando in ambito web RTC per vari motivi quindi in ambito voip conferencing e così del genere, quindi cominciamo a ragionare anche per scenari più di tipo di broadcasting invece.Quindi come possiamo cercare di utilizzare una tecnologia nuova e più innovativa come WebRTC per cercare di abbattere invece queste latenze quindi magari catturi qualcosa ora e chi sta guardando il contenuto da casa lo vede in tempi molto minori quindi sotto al secondo ma idealmente anche parecchio sotto al secondo quindi nel range di qualche centinaio di millisecondi e non di più e diciamo che l'idea alla base era proprio che diciamo le tecnologie web RTC sono nate proprio per questo sono nate per scenario di comunicazione in tempo reale quindi sono nati per la chiacchierata in tempo reale però possono essere utilizzati anche in questo caso quindi dal punto di vista della tecnologia più o meno ci siamo il problema appunto come dicevi sono sono soprattutto due problemi diversi uno è il problema dell'ingestion quindi come faccio a fornire un contenuto via webRTC ad un server che poi lo distribuirà questo perché appunto le varie soluzioni che conosciamo come OBS o Streamyard o XSpirit o altre alla fine utilizzano tutti protocolli diversi per pubblicare quindi di solito utilizzano un protocollo chiamato RTMP per fare l'ingestion e quindi poi distribuiscono alle CDN in quel modo e l'altro problema, chiaramente una volta gestito il problema dell'ingestion, è distribuire invece quindi se ho un contenuto contribuito, non si sa come, rtmp, webrtc o quant'altro se lo voglio distribuire via webrtc come faccio? come lo scalo? come ottengo gli stessi numeri che posso utilizzare con una cdn tradizionale? e diciamo che per la parte di ingestion c'è già un lavoro di standardizzazione che è in atto al quale sto partecipando anche io con dei prototipi e che stanno lavorando proprio su una un semplice protocollo di segnalazione per realizzare un canale di ingestion per WebRTC l'idea alla base è che magari tu ti prendi il tuo OBS di turno e nella configurazione di OBS invece di un server RTMP puoi mettere un server WebRTC per pubblicare e quindi l'idea è che OBS crei un canale di comunicazione via WebRTC verso il server e poi quindi può pubblicare i dati in quel modo quindi utilizzando un protocollo diverso e quindi permettendoti di fare la tua ingestion in quel modo e poi una volta che arriva al server lì puoi distribuirlo tramite HLS o Dash tramite architetture tradizionali se vuoi ma puoi anche distribuirlo via webRTC se vuoi e questo protocollo di ingestion si chiama WIP come la frusta in inglese fondamentalmente W H I P ed è un protocollo nato proprio ultimamente, ci ho fatto un paio di presentazioni proprio recentemente poi magari vi posso dare qualche link se fosse interessante perché ho spiegato quali sono le problematiche e come si può come si può gestire e chiaramente quello che fece al tempo del dottorato era lavorare invece più sulla parte di distribuzione che è quella diciamo un po' più delicata dal punto di vista delle architetture perché come dicevo le cdn che utilizzano protocolli tipo dash o hls hanno comunque una lunga storia alle spalle diciamo sono sono tecnologie ormai rodate quindi diciamo è molto semplice crearti vari vari server per per popolare la sua cdn e distribuirlo con web artisti diciamo il mondo è un po le tecnologie utilizzate sono molto diverse quindi ci sono problematiche diverse da gestire quindi all'epoca lavorai su una potenziale architettura che poi abbiamo un po rielaborato soprattutto per farla funzionare con con questo nuovo protocollo chiamato WIP però diciamo è potenzialmente uno degli sviluppi più interessanti di WebRTC anche perché ci sono molte molte aziende che stanno cominciando a studiare come utilizzare WebRTC in questo ambito perché lo stesso Dash che poi ha un suo ente di centralizzazione che lavora sul protocollo sta lavorando su una variante per utilizzare WebRTC assieme a Dash quindi anche loro sanno che comunque diciamo con quelle tecnologie sotto un tot numero di secondi non arriverai mai e quindi devono per forza di cose utilizzare web artesì o tecnologie comunque più reattive se vogliono abbattere consideravelmente i tempi di latenza e per tutti quelli che insomma usano da zone per guardarsi le partite ogni settimana diciamo che poter guardare una partita con ritardi minori a due minuti diciamo potrebbe essere una Sicuramente una cosa particolarmente interessante.E salutiamo tutti i nostri amici di The Zone, e so che nel gruppo ce n'è diversi.No, perdona l'ignoranza, più di una volta mi è capitato di vedere dei live streaming con protocolli standard, adesso non ricordo quali siano, ma uno di quelli che hai citato, che avevano una caratteristica che era la qualità adattiva, no? perché la rete è un'incognita grande e tutto dipende dalla mia qualità di rete dalla qualità di rete alla quale collegate il server, da tanti parametri che sono fuori dal nostro controllo.Adesso se WebRTC è un protocollo che in qualche modo prioritizza la comunicazione quanto più real-time possibile come fa a gestire il trade off tra qualità e delay? Sì diciamo anche qui ci sarebbe parecchio da spiegare anche che ci sono parecchie parecchie soluzioni che lavorano contemporaneamente quindi da un lato c'è il fatto che WebRTC nasce utilizzando diciamo come protocollo di livello transporto udp che quindi significa non ci interessa che il pacchetto arrivi ma deve arrivare il prima possibile se vogliamo e poi su questo protocollo di trasporto che è non affidabile per definizione diciamo la suite di protocolli webartistica ha creato dei meccanismi di semi affidabilità se vogliamo quindi diciamo che qualche meccanismo per cercare di assicurarti che i pacchetti arrivino a destinazione c'è ci sono meccanismi di trasmissione ci sono meccanismi di bandwidth estimation per per fare in modo che tu quanto generatore di dati sai qual è la banda che ha a disposizione in qualsiasi momento in maniera tale che puoi adattare l'encoder di conseguenza chiaramente questo ti copre diciamo la parte di ingestion quindi sai che sicuramente al server in qualche modo il tuo flusso arriva come deve arrivare e diventa un problema di tipo diverso quando poi questo flusso lo devi far arrivare a parecchie persone diverse che possono avere banda completamente diversa quindi c'è chi ha il gigabit a casa e chi invece sta collegato con con la lavatrice se vogliamo quindi diciamo che ci sono...devi preoccuparti di queste problematiche da questo punto di vista diciamo da un lato webRTC comunque soprattutto quando non fai transcodifica di nessun tipo significa che quello che stai mandando quello è quello che riceveranno tutti quindi diventa un po più complicato adattare però ci sono due tecniche diverse che puoi utilizzare in WebRTC, una molto utilizzata al momento, una la useremo a breve e sono il Simulcast LSVC lo scalable video coding.Il Simulcast fondamentalmente parte dal presupposto che quando tu invi il tuo video verso un server o verso una destinazione normalmente mandi una sola qualità che può essere ad esempio 720p ad una certa banda però in realtà col simulcast puoi mandare tre versioni diverse del tuo contributo video quindi significa che all'interno della stessa sessione sta in realtà mandando ad esempio un flusso ad alta qualità, uno media qualità e uno bassa qualità.Sono tre flussi separati che viaggiano in parallelo arrivano al server e poi il server decide quale mandare ai partecipanti coinvolti quindi a chi ha la banda buona mandiamo lo stream a bassa qualità a quello che sta guardando la partita dal telefonino ma andiamo invece magari lo stream ad esempio a media o più bassa qualità o così via diciamo da un primo strumento di smistamento intelligente al server in pratica mette a disposizione del server tre flussi diversi senza che appunto devi lavorare di transcodifica per i flussi coinvolti quindi questo è già un primo strumento che è molto utilizzato anche in ambito conferencing perché diciamo è uno strumento molto efficace di disseminazione adattativa dei contenuti perché significa che se io ho tre risoluzioni diverse per lo stesso partecipante a seconda delle necessità posso possiamo inviare l'uno o l'altro ad un partecipante magari partecipante può ricevere il flusso a bassa qualità perché ha poca banda o perché magari quel video verrà messo in un angolino per per 20 minuti e se sta là in un angolino non abbiamo bisogno di un flusso ad alta definizione sarebbe uno spreco di banda basta il video a bassa risoluzione per ottenere lo stesso effetto lo scalable video coding funziona in maniera un po diversa perché in quel caso diciamo il concetto è lo stesso continui a mandare diciamo risoluzioni diverse del tuo video ma sono tutte inviate nel contesto dello stesso video che stai inviando quindi è semplicemente un video che è codificato, se mi passate la terminologia un po' diciamo non rigorosa, sfoglia di cipolla se vogliamo.Quindi avete il cuore della cipolla che è il flusso a bassa definizione, c'è un layer esterno che è a media definizione poi un altro layer esterno ancora che è la cipolla completa che è il flusso ad alta definizione.Quindi se io ti mando tutta la cipolla stai effettivamente ricevendo il flusso ad alta qualità.Se io comincio a levare alcuni layer e ti mando solo parte del pacchetto dello stream che sto ricevendo, ricevi lo stesso video ma a qualità minore quindi a risoluzione minore.Se ci levo altri layer ancora ricevi un flusso che invece è quello più bassa definizione possibile ma ancora fruibile.Questa è l'idea principale e lo stesso puoi fare anche con il frame rate quindi posso mandarti tutti alterati ai frame al secondo ad esempio oppure posso dimezzare il frame rate magari te ne mando solo 15 e tu comunque vedi il video alla stessa risoluzione ma lo vedi un po' più magari scattoso ma comunque lo vedi alla stessa risoluzione soprattutto consumando molta meno banda quindi di nuovo ti dà altri strumenti a disposizione.E questo diciamo dal punto di vista delle tecnologie è un po' più complesso ma è una delle direzioni nelle quali WebRTC si sta andando parecchio soprattutto grazie ad un nuovo codec che si chiama AV1 di cui forse avrete sentito parlare.è un codec video che sarà royalty free, che è royalty free, al quale hanno contribuito tutte le più grandi aziende, compresa ad esempio Netflix, tanto per darvi un'idea.quindi comunque è sicuramente un codec sul quale tutti stanno investendo e che ha svc come parte del codec stesso.già ci sono esperimenti per farlo lavorare anche in ambito real time in WebRTC.Figo.Volevo farti una domanda sui codec però prima mi piacerebbe farla precedere da un'altra.Cosa c'è in materia di...adesso dico una parola che odio ma è così...di DRM è sicurezza e criptaggio dei flussi.Sì diciamo che non c'è una cosa strettamente legata al DRM in web artissiva ora è proprio anche se diciamo ci sono tecnologie simili che possono essere utilizzate per fare qualcosa del genere quindi ad esempio e questo è legato anche al concetto di peer-to-peer e di hop by hop di cui vi parlavo prima quindi vi vi dicevo che quando c'è un server di mezzo creiamo varie comunicazioni peer to peer tra noi ed il server che poi ci permettono di smistare i flussi e così via diciamo che in linea generale proprio per il fatto che tutte queste comunicazioni peer to peer sono in realtà hop by hop quindi le nostre comunicazioni arrivano fino al server e poi il server le smista significa che dal punto di vista della dell'encrypting webRTC nasce per essere nativamente criptato end to end però se il nostro end to end arriva al server in realtà arriva al server lì viene decryptato quindi all'interno del server il flusso è in chiaro e poi il server lo lo encrypta di nuovo per inviarlo agli altri partecipanti quindi da questo punto di vista è un encryption hop by hop e quindi da questo punto di vista se vuoi fare invece una vera encryption end to end anche nel contesto di un server di mezzo quindi nel caso di conferenze o nel caso anche di broadcasting c'è una tecnologia alternativa che si chiama i cosiddetti insertable frames.Gli insertable frames sono una tecnologia che in ambito webRTC è nata per scenari generici quindi non solo l'encryption ma che ha trovato nell'encryption il suo caso principe se vogliamo e e l'idea è che tramite queste Insertable Frames puoi fare in modo che prima che una frame venga mandata via WebRTC quindi hai catturato un'immagine con la webcam, il browser la sta codificando e la vuole mandare dall'altra parte una volta che l'ha codificata utilizzando il codec, prima di inviarla la fa risalire all'ambito applicativo ad esempio nella tua applicazione in JavaScript e lì puoi decidere di farci qualcosa e questo qualcosa che puoi fare è magari un ulteriore layer di encryption però a livello applicativo quindi magari questa frame che stiamo per mandare prima di inviarla via WebRTC e via RTP la cryptiamo in un modo che conosciamo solo magari io, te e Luca e ci siamo scambiati delle chiavi lato applicazione, lato signaling quindi un layer che non comunica con il layer WebRTC e di cui il server WebRTC non sa niente il server web rtc riesce solo a decriptare il layer hop by hop ma non riesce a decriptare il payload dovere proprio il payload dovere proprio arriva intatto a destinazione ad entrambi e quindi solo voi potete decriptarlo utilizzando le informazioni che ci siamo scambiati questa è diciamo in parole poverissime come funzionano questi insertable frames e questa tecnologia è diciamo è proprio alla base del concetto se vogliamo anche di dire DRM nel contesto del broadcasting perché se utilizzi questo tipo di di encryption anche in maniera dinamica quindi magari con delle chiavi che vengono aggiornate continuamente mentre il flusso sta andando e devi fare in modo chiaramente che chi riceve lo stream è sempre diciamo al corrente delle chiavi corrette da utilizzare in questo modo puoi realizzare uno stream che sia e che se anche magari qualcuno riesce a ricevere lo stream in qualche modo tramite magari riesce a convincere un server a inviargli lo stream se non ha accesso a questa chiave questo video non lo può decryptare quindi non ci può fare nulla però diciamo non dicevo che uno pseudo DRM perché non funziona proprio esattamente come DRM all'interno del browser dove comunque hai dei vincoli molto più stretti su quello che puoi fare con i media una volta che sono riprodotti nell'elemento video ad esempio con WebRTC, con gli insertable frames, una volta che l'hai decodificato diventa un flusso che riproduci ad esempio in un elemento HTML5 video e diciamo lo smanettone di turno se vogliamo da questo elemento può comunque catturare qualcosa quindi diciamo c'è un po' di lavoro da fare in questa direzione ma sicuramente ci sono degli strumenti già a disposizione.Chiaro, bello.Ti giuro mi si sta piano piano spannando un'immagine.Vedo che Luca ha qualcosa da dire.No, a me mi si sta aprendo un mondo, un mondo che ignoravo fino a qualche minuto fa, o meglio ne vedevo una piccola una piccola parte, però ci sono un sacco di cose interessanti.No, c'è una domanda che mi stava arronzando da un quarto d'ora, da quando hai parlato del tuo progetto di musica, di jam session, queste cose qui, hai parlato tu stesso di latenza, Weber e ti dici "sì, non credo ne sia immune", quindi volevo capire in qualche modo come lo si risolve, perché io avevo visto anche un servizio da qualche parte, forse era il tuo, uno dei tuoi, non lo so, che prometteva il fatto di poter suonare in live con delle persone.Quel servizio ha detto "vabbè, non è possibile perché per quanto puoi abbattere la latenza, un minimo c'è e quel minimo nella musica io strimpello la chitarra, un millisecondo, due millisecondi già ti fa storcere occhio, naso e soprattutto l'orecchio.Volevo capire come era affrontato il...giusto per curiosità...No, questo è uno scenario che mi interessa molto anche perché appunto come dicevo anche io suono quindi mi interessava proprio anche dal punto di vista personale l'idea e diciamo che quello che ho provato a fare con il prototipo era appunto cercare innanzitutto di identificare dove sono le principali problematiche per quanto riguarda la latenza perché diciamo che ci sono ci sono vari punti diversi nei quali viene aggiunta la latenza diciamo non sempre sono immediatamente riconoscibili quindi per esempio c'è latenza già nella fase di cattura ma anche nella fase di codifica perché per quanto riguarda la parte web RTC per esempio di nuovo non mi voglio non voglio diventare troppo tecnico però giusto per darvi un'idea quando inviamo pacchetti audio all'interno di WebRTC, considerato che l'audio viene sempre partizionato in sample per secondo, quindi ad esempio i 48 kHz sono i tuoi 48.000 sample che hai in un certo secondo, quando invi i dati in real time via WebRTC stai frazionando questi sample che invierai, quindi significa che la prima cosa che fai quando quando crei una sessione WebRTC è decidere quanti millisecondi di audio vuoi catturare prima di inviarli dall'altra parte quindi dal punto di vista di webRTC soprattutto per l'audio inviare un flusso audio in tempo reale significa catturare 8 millisecondi e inviarli in pacchetti consecutivi in maniera tale che poi il ricevitore dall'altra parte riceve questa sequenza li mette in ordine in un suo buffer e poi le riproduce in maniera in maniera ordinata se vogliamo e quindi sicuramente c'è una prima latenza che viene proprio da questa prima decisione quindi quanti millisecondi stiamo inviando che in ambito VoIP sono diciamo uno standard quasi de facto sono i 20 millisecondi quindi mandi sempre blocchetti di 20 millisecondi alla volta il che significa che comunque parti già dal presupposto che una cosa che stai ascoltando in questo momento è stata catturata almeno 20 millisecondi fa perché il primo pacchetto il primo sample che senti e che ricevi in questo pacchetto in realtà l'ultimo sample che è stato catturato in questa sequenza di 20 millisecondi quindi c'è già questa cattura qua poi diciamo c'è la codifica ti porta via un minimo di tempo in più poi devi metterci la trasmissione la trasmissione su rete che insomma ha le sue latenze a volte difficilmente prevedibili e poi ci sono tutte le latenze legate alla fase di cattura e riproduzione che sono più legate al sistema operativo e alle tecnologie che sono utilizzate lì.Nel prototipo che avevo realizzato all'epoca il primo passo che avevo fatto era quello di utilizzare ad esempio un sistema audio a bassa latenza.Io sono un utente Linux in particolare e su Linux c'è un framework che si chiama Jack che ti permette di realizzare che nasce fondamentalmente proprio per la produzione musicale quindi è quello per quale lo uso soprattutto io quando nel mio tempo libero ma visto che nasce soprattutto per quello quindi per permetterti di gestire flussi audio a bassissima latenza all'interno del sistema operativo significa che se tu riesci già ad abbattere un po di tempi lì quindi riesci ad abbattere i tempi di cattura e di riproduzione usando jack piuttosto qualche altra cosa utilizzando magari un'applicazione nativa invece del browser perché il browser ha dei suoi buffer interni e una sua manipolazione dell'audio che non sempre si sposano bene con con utilizzi di tipo musicale quindi utilizzi jack download che potrebbe essere asio su windows o altre tecnologie su mac diciamo questo è lo scenario che volevo provare a realizzare utilizzi un'applicazione nativa dove magari puoi lavorare un po di più sui tempi di cattura e di latenza anche di webrtc quindi magari configurando lo stack webrtc in modo da non bufferizzare nulla appena catturi qualcosa manda subito e così via diciamo questi erano i primi esperimenti che avevo provato a fare per cercare di capire se almeno ci avvicinavamo a qualcosa di utilizzabile e poi insomma in questo caso diciamo una volta che abbattuto questi due tempi qua il tempo principale diventa quello di trasmissione sulla rete quindi chiaramente più distante sei più ci sono problemi se magari stai suonando con qualcuno che è a Roma o qualcuno che a Chicago chiaramente i tempi sono completamente diversi diciamo che con utenti relativamente vicini di solito hai tempi di trasmissione relativamente bassi però se passi attraverso un server devi comunque considerare il fatto che ci sono un paio di hop da fare quindi comunque devi prima raggiungere il server e il server deve raggiungere il tuo peer quindi è uno dei motivi per il quale questo prototipo è ancora lì in un cassetto perché ho cominciato a lavorarci poi insomma c'erano entravano mille variabili in gioco stavo lì a provarlo da solo quindi insomma non c'era poco che si poteva fare però è stato interessante dal punto di vista dell'analisi delle problematiche che poi ci sono anche molte soluzioni che diciamo ti permettono di fare jam session online che utilizzano ognuno un approccio diverso tipo mi sembra che sia jamulus che ti permette di utilizzare un clock sul server ad esempio in quel caso sei tu che ti devi adattare al fatto che il clock il quale devi fare riferimento non è quello locale dal quale stai facendo riferimento ma quello che ti invia il server che cerca di sincronizzarvi tutti contemporaneamente quindi diciamo ci sono tecniche diverse da questo punto di vista però sicuramente almeno dal mio punto di vista webRTC in questo caso può aiutare almeno dal punto di vista protocollare diciamo che ci sono pochi protocolli che ti permettono di trasmettere audio altrettanto velocemente come WebRTC e quindi quello era un primo esperimento che volevo fare.Però finora appunto relativamente fallito, poi vedremo se in futuro uscirà qualcosa di più decente.Sì, io devo dire che nella mia esperienza precedente ho avuto questo tipo di problemi per quanto riguardava la comunicazione radio.non comunicazione radio intesa in senso classico ma per esempio durante la pandemia di covid io ho ripreso a fare quello che facevo da adolescente quindi trasmettere in una radio locale.Peccato che mi trovo oggi a Lione e la radio locale stava in Sardegna e molti dei tool che ho provato a utilizzare avevano una sorta di half duplex per cui quando io parlavo non potevo ricevere la stessa qualità e la musica che invece il regista metteva in regia quindi ci sono anche questo tipo di problematiche che però da quello che ci dicevi con WebRTC possiamo risolvere perché semplicemente facciamo due canali e risolviamo il problema giusto o compreso bene? sì esattamente diciamo che questo potrebbe essere un perfetto caso d'uso per esempio per un'applicazione webRTC e so che ci sono molti che hanno utilizzato webRTC proprio come tecnologie anche per per show radiofonici ad esempio quindi tecnologie di supporto alla realizzazione di show radiofonici ma anche per interfacciarti con studi di produzione di qualsiasi tipo perché in in quel caso WebRTC ti permette di trasmettere audio e video in maniera abbastanza rapida e quindi in quel caso diventa solo un problema come lo metto a disposizione di una cabina di regia ad esempio per poi farci qualcosa ad esempio mandarlo in broadcasting tramite tecnologie come appunto tv o radio o quant'altro.Uno dei due elementi di WebRTC, come abbiamo ripetuto più volte in questo episodio, è il server e il browser.Detto che, e questo mi piace dirlo perché anche oggi mi sono scontrato, Safari è il nuovo Internet Explorer.E visto che tu hai già diversi anni, che ti sei scontrato con i limiti e le incongruenze dell'implementazione dei vari browser.Qual è stata appunto l'esperienza da questo punto di vista? è stata semplice? i browser hanno implementato tutto subito bene? o hai fatto scendere qualche qualche santo dal cielo mentre lavoravi a Janus Server? è la domanda immediatamente successiva perché vogliamo sapere cosa fa e come lo fa.No, santi ne sono piovuti a catinelle quello sicuramente però diciamo che non posso neanche lamentarmi troppo perché diciamo che sin dal primo giorno diciamo che WebRTC è stato molto utilizzabile proprio dal day one se vogliamo quindi era possibile realizzare scenari di comunicazione anche proprio con la primissima versione che uscì che comunque una cosa che non bisognava dare per scontata chiaramente poi visto che era una tecnologia in evoluzione anche dal punto di vista della standardizzazione perché abbiamo parlato di ETF e W3C che lavoravano in parallelo per per lavorare su aspetti diversi chiaramente le cose cambiavano in continuazione anche lì quindi cambiava una specifica nel protocollo, cambiava una API e quindi ti trovavi in quelle situazioni di limbo dove magari un browser implementava una versione, un browser ne implementava un'altra e quindi dovevi un po' uscire pazzo.Poi chiaramente c'erano quelle volte dove andavi a dormire la sera che funzionava tutto bene, il giorno dopo usciva l'aggiornamento di Chrome e si scassava tutto, non funzionava più niente.Quindi erano tempi interessanti, sicuramente non ci siamo mai annoiati, però diciamo alla fine ci troviamo ora in un momento storico dove le incompatibilità sono relativamente poche, però ci sono stati quei browser che hanno rotto un po' le scatole più degli altri.Perché chiaramente c'era Chrome, che era diciamo quello più all'avanguardia perché google era diciamo il proponente principale di webrtc c'era firefox che abbastanza rapidamente si è messa al passo anche se almeno inizialmente avevano delle incompatibilità di comunicazione quindi in quanto server dovevi essere pronto a gestire entrambe poi c'era appunto edge, edge prima di diventare chrome 2.0 che era quasi inutilizzabile, Safari che insomma ha tutte le sue problematiche.Diciamo le problematiche principali di Safari al momento più che dal punto di vista delle API sono che Apple ha una diciamo una sua concezione di quali codec bisogna implementare in generale perché in linea generale diciamo in WebRTC ci sono dei codec che tutti gli end point devono implementare da standard questo per garantire un minimo di interoperabilità fra le implementazioni quindi vi ho parlato all'inizio del concetto di negoziazione che magari abbiamo delle capability e ci dobbiamo mettere d'accordo per fare in modo che diciamo ci sia almeno un livello base di comunicazione ci sono dei codec che tutti devono implementare quindi per l'audio tutti devono implementare opus per il video tutti devono implementare vp8 ed h264 in maniera tale che diciamo in un modo o nell'altro riusciamo sempre ad incontrarci, magari non con la qualità migliore possibile, ma ci vediamo.E diciamo per un bel po' Apple aveva deciso che VP8 non lo voleva implementare e qui VP8 era alla fine il codec che utilizzavano quasi tutti perché era Royalty Free rispetto ad H264 poi più o meno si è convinta piano piano diciamo qualcuno ha fornito delle patch, ci hanno messo un sacco di tempo, beh lo facciamo poi hanno cominciato a mettere H265 ma l'hanno messo solo loro perché H265 non lo vuole nessuno perché dal punto di vista dell'eye sensing è ancora più incasinato poi insomma vari problemi col data channel insomma cambiavano parecchi pezzi di implementazione utilizzando decisioni a volte un po' unilaterali e quindi dal punto di vista delle problematiche soprattutto per gli sviluppatori web era un problema lavorare con Safari perché le API che implementavano non sempre funzionavano allo stesso modo modo di come funzionavano in chrome o come funzionavano in firefox e così via diciamo che da alcuni punti di vista è ancora un po' un problema perché ci sono alcune applicazioni web RTC che ad esempio ti dicono devi utilizzare per forza chrome non puoi utilizzare firefox o altri semplicemente perché chrome implementa delle cose anche chrome implementa delle cose a modo suo che magari non sono precisamente standard ma sulle quali molto fanno affidamento e magari gli altri browser non lo fanno diciamo da questo punto di vista bisogna essere un po' preparati però non è più il problema che c'era inizialmente.Diciamo adesso vado a dormire più tranquillo sapendo che molto difficilmente domani si scasserà tutto, insomma deve succedere proprio insomma all'ira di dio per causare veri problemi in ambito web artisti al momento.Diciamo parecchi scenari almeno basici li fai con tutti i browser senza tanti problemi.bellissimo mi hai ricordato tempi ormai andati, i miei primi passi al lavoro dove il sito tirrenia girava solo con internet, il sito tirrenia per le agenzie di viaggi girava solo con internet explorer, quella versione, altrimenti si scassava tutto.però adesso parliamo del tuo bambino di Janus.La domanda è cosa è Janus? Un po' abbiamo anticipato alcune cose.Perché l'hai chiamato Janus? E a livello architetturale so che hai preso una decisione che è quella di sviluppare un sistema pluggable.Quindi perché? Quali sono stati i trade off? Insomma in questa domanda abbiamo un'altra oretta di chiacchierata.Sì, partiamo dal nome che è la cosa più interessante.L'ho chiamato Janus perché Janus viene dal jano bifronte, quindi anche nell'ambito delle tecnologie è un nome che di solito esce spesso, soprattutto nell'ambito dei gateway, perché è un modo semplice per dire "hai un qualcosa che ti permette di parlare a due mondi diversi", quindi un mostro a due facce che quindi ti permette di comunicare con due mondi completamente diversi ma dal punto di vista della mitologia romana Giano era anche il dio delle transizioni quindi era il dio insomma che di gennaio si chiama così per per Giano se vogliamo quindi era il dio che guardava da un lato al passato l'anno che era appena finito e da un l'altro guardava al futuro quindi l'anno che stava per venire e quindi ci piaceva anche questo come idea appunto delle tecnologie preesistenti come quella del VoIP, da un lato quindi il passato e il futuro che era WebRTC e tutto quello che ci puoi fare e quindi inizialmente lo chiamammo Giano anche perché originariamente Gianos nasceva soprattutto come gateway prima piuttosto che come server anche se poi è diventato rapidamente un server molto più generico proprio perché l'idea principale era quello di permettere di utilizzare WebRTC con tecnologie tra virgolette legacy quindi ad esempio infrastrutture VoIP basate su SIP oppure interfacciarti con telecamere di videosorveglianza basate su RTSP anche quelle diciamo ancora diffuse ma comunque una tecnologia più vecchiotta perché RTSP è in giro da parecchi anni quindi quella era l'idea principale e diciamo che era c'era anche diciamo l'idea alla base della della tesi di dottorato di cui parlavo prima perché Janus è nato proprio in quel periodo lì quindi anche in quel caso io volevo cercare di realizzare uno streaming su larga scala di una di una sorgente che non fosse originata via WebRTC ma fosse invece ad esempio un semplice flusso RTP che potevo generare con FFmpeg, tanto per dire oggi streamer, che magari anche all'epoca non sapevano nulla di WebRTC e quindi anche in quel caso c'era una tecnologia preesistente che volevo realizzare e mettere a disposizione di WebRTC.quindi questo è diciamo come nacque il nome in generale e Janus è stato concepito appunto con un'architettura plugable, modulare, è una cosa che abbiamo fatto volontariamente proprio perché all'epoca soprattutto prima che nascesse Janus già stavamo lavorando con WebRTC utilizzando modificando soprattutto tool open source esistenti quindi all'epoca in particolare avevamo una nostra applicazione di videoconferenza che era basata in parte su asterisk per la parte di audio, in parte su un progetto che si chiamava Linkia che adesso si chiama Leecode per la parte di video, insomma era un po anche lì un frankenstein di diverse cose e quello che volevamo fare era invece realizzare piuttosto che realizzare un'ulteriore applicazione molto verticale quindi un'applicazione che facesse solo gateway zip, che facesse solo videoconferenza o che facesse solo questo o solo quest'altro abbiamo pensato perché non realizzare invece un'applicazione che ha un suo core webRTC quindi la parte webRTC la implementiamo una volta sola e ce la implementiamo in questo core che quindi sa implementare il peer webRTC, sa insomma come comunicare con un browser ma poi cosa fare con i flussi audio e video veri e propri lo lasciamo decidere invece a dei plugin quindi riusciamo magari ci facciamo un plugin che ci permette di parlare con mondo SIP ci facciamo un'applicazione per fare le videoconferenze, ci facciamo un audio mixer, ci facciamo un'applicazione per fare semplice streaming ma tutti hanno in comune il fatto che utilizzano il core WebRTC e quindi da questo punto di vista questo tipo di architettura modulare significa che comunque disaccoppiavamo la parte di WebRTC vera e propria dalla logica applicativa quindi cosa fare con i flussi audio e video.E' una cosa che ci permetteva quindi anche allo stesso momento di estenderlo se volevamo.Quindi se domani esce un nuovo caso d'uso che non è realizzabile con i plug-in che esistono al momento, ci creiamo un nuovo plug-in e ci lavoriamo su.Il motivo principale per il quale poi col tempo abbiamo scritto anche un plug-in per crearti una tua logica in Lua o in JavaScript se vogliamo.quindi sono due linguaggi di programmazione molto più semplici da utilizzare e molto più semplici anche da scriptare da questo punto di vista e quindi diciamo nacque proprio con questa idea inizialmente proprio per una necessità proprio perché avevamo questa applicazione di conferencing che utilizzava tecnologie diverse e utilizzava server diversi che volevamo realizzare tutte con un solo server invece quindi avevamo un due o tre casi d'uso in mente abbiamo realizzato dei plugin di riferimento e poi questi plugin di riferimento sono diventati abbastanza generici da poter essere utilizzati in contesti completamente diversi da quelli che avevamo immaginato all'epoca perché appunto siamo partiti che volevamo fare la videoconferenza ma adesso c'è gente che ci fa broadcasting, internet of things, ci fanno i learning, webinar, applicazioni di tipo musicale, telemedicina praticamente ci sono stati migliaia di casi d'uso diversi che sono stati favoriti proprio dalla scelta di realizzare un'architettura che fosse più generica piuttosto che veramente verticale come altri avevano invece scelto di fare.Domanda, ce lo siamo detti fuori episodio, quindi te lo chiedo sapendo che c'è una risposta.Pensando a prodotti commerciali che usano o hanno usato WebRTC che utilizziamo tutti i giorni, puoi darci qualche nome? Perché in realtà ne hai citato un paio.Io ho detto "ah, scusami non WebRTC, Giano" che utilizzano Giano sotto il cofano o hanno utilizzato Giano sotto il cofano.Mi ha dato un paio di nomi e mi si è aperto un mondo, no? No, alcuni nomi, soprattutto in passato, erano parecchio interessanti anche perché diciamo erano queste mega aziende di cui magari avevo sempre solo sentito parlare poi alla fine scopri che utilizzano il tuo software, sicuramente sono soddisfazioni.Diciamo il primo nome veramente grande che utilizzò Janus e che sicuramente ha contribuito anche un po' al nostro successo all'epoca fu Slack, quindi questo era soprattutto i primi anni di Janus, Slack aveva una sua funzionalità di videoconferenza integrata e utilizzava Janus dietro le quinte quindi fu sicuramente il primo deployment a larghissima scala di Janus perché comunque Slack era utilizzato in tutto il mondo da credo milioni di utenti centinaia di migliaia di utenti quindi era sicuramente un deployment larghissimo che per loro comunque sembrava funzionare abbastanza bene c'è stata Microsoft ad esempio che ha utilizzato Janus come parte delle loro tecnologie per mixer.Mixer era un servizio di streaming che era integrato con Xbox che utilizzava un protocollo un po' diverso e utilizzava Janus per la parte WebRTC sulla quale era basata.La stessa Mozilla utilizzava Janus per fare scenari tipo di augmented reality in un progetto che si chiamava Hubs.Anche adesso ci sono parecchie aziende, uno di cui credo si possa si possa parlare perché diciamo era un po' è girato già qualche notizia insomma che lo faceva era Twitter, non so se conoscete Twitter Spaces, la funzionalità che vi permette di fare tipo di audio podcast in tempo reale e loro utilizzano Janus per la parte di chiacchierata vera e propria, poi la distribuzione non so come la fanno, ma sicuramente utilizzano Janus come parte di quella tecnologia.E ci sono anche altre di cui purtroppo non posso parlare perché ci sono alcuni NDA in ballo, perché ci sono casi nomi anche belli grossi che purtroppo mi devo mordere la lingua e non posso fare, però ci sono nomi parecchio interessanti.sì ci sono parecchie aziende grandi e piccole che usano Janus tutti i giorni, alcune anche in Italia perché per esempio ci sono aziende tipo Voicemark, Tonethesis che utilizzano Janus come parte dei loro prodotti, che sono aziende che magari potreste avere più familiarità perché sono più nell'ambito del nostro territorio ma comunque ci sono aziende in tutto il mondo che utilizzano Janus per svariati usi e ogni volta che sento di un nuovo caso d'uso particolare sono sempre intrigato mi ricordo ancora che la prima volta che rimasi sconvolto dall'utilizzo di Janus che aveva fatto qualcuno era uno sviluppatore che poi ho conosciuto che aveva utilizzato Janus per controllare un drone da remoto in qualche modo quindi aveva fatto una crocchia utilizzando Janus e G-Streamer e poi guidava questo drone in giro per la casa facendo in modo che guardava il video dal drone e dal browser grazie a Janus quindi era un primo scenario particolarmente intrigante che sicuramente mi sorprese all'epoca perché non pensavo neanche che fosse possibile invece adesso è una cosa abbastanza comune sì, perché ti ho fatto questa domanda in realtà? Perchè quello che ti chiedo è ti è capitato nella tua esperienza a questo punto di da maintainer open source, di avere un tool utilizzato dai grandi che sensazione ne hai avuto da maintainer? Nel senso hai visto un incremento di contribution, hai visto un incremento di issue è cambiata qualcosa nella community attorno a Janus? Diciamo che qui ci sono risposte diverse a seconda delle parti coinvolte Diciamo che in genere usi così grandi hanno innanzitutto un impatto dal punto di vista della visibilità perché noi avevamo un nostro piccolo successo all'epoca però chiaramente quando uscì la notizia che Slack usava Janus, insomma era una cosa che loro non avevano rivelato, c'era stato uno sviluppatore giapponese che aveva fatto reverse engineering, aveva trovato Janus scritto da tutte le parti e quindi ha capito che ci utilizzava e quindi scrisse un blog post e quindi divenne un po' di pubblico dominio.Quindi quello sicuramente contribuì diciamo ad un primo successo perché diciamo che chiaramente quando, soprattutto per un progetto open source nuovo, quando vedi un'azienda di quelle dimensioni che diciamo in qualche modo si fida del prodotto sicuramente aiuta anche altri a superare certi bias e cercare di capire se può essere utilizzabile anche per loro.In linea generale non credo che ci siano stati contributi particolari da parte di grandissime aziende diciamo la maggior parte dei contributi noi l'abbiamo avuti e continuiamo ad averli da utenti più generici della Pettaforno quindi aziende di medie dimensioni o anche contributor individuali quindi diciamo da questo punto di vista è la community in generale che ha contribuito parecchio al successo di Janus quindi non ci ho mai visto dei contributi particolari da parte di grandi aziende ma più che altro dalla community in generale.Diciamo che quello da un certo punto di vista secondo me è stato il successo principale di Janus almeno per come la vedo io perché in realtà noi inizialmente non sapevamo neanche se metterlo a disposizione come open source o meno.In realtà ragionavamo sulla possibilità magari di metterlo a disposizione come soluzione proprietaria, farci magari qualche euro in più e così via in realtà decidemmo poi di pubblicarlo come open source ed è stata diciamo sempre che è stata la migliore decisione che abbiamo mai fatto perché in realtà una volta che si apre la community una volta che tutti possono utilizzarlo e farci un po quello che vogliono cominci a ricevere contributi parecchio interessanti perché magari trovi persone che ti risolvono problemi che tu da solo non avresti mai mai risolto ci sono problemi che ti trovano problemi che da solo non avresti mai trovato sono continuamente stimoli per migliorare ed incrementare il lavoro sul migliorare il lavoro che stai facendo sul prodotto in generale quindi in linea generale sono molto contento della community non non credo che l'impatto sulla community delle grandi aziende sia stato particolarmente rilevante anche perché la maggior parte delle volte non sappiamo neanche che ci stanno utilizzando se non magari quando quando ti contattano per qualche consulenza o perché magari appunto come nel caso di Slack qualcuno scopre che ti stavano utilizzando.Allora a questo punto ho due domande esattamente conseguenti da questo.Monetizzazione.Voi avete una società che ha un nome bellissimo e lo pronuncerò all'italiana che è qualcosa tipo "Miteco" giusto? E oggi come fa un'azienda piccola il cui software però gira nei giganti quindi sostiene sulle sue spalle anche i giganti a monetizzare sostenere e quando dico monetizzare non dico fare gozziliardi di profitti ma quantomeno pagare lo sforzo l'effort e il lavoro fatto.Si apre una piccola parentesi sul nome dell'azienda in realtà in teoria doveva essere diciamo quando abbiamo inventato il nome volevamo che fosse pronunciato mitico che sarebbe appunto mitico una parola molto italiana e all'età ci abbiamo messo quella h di mezzo che ha rovinato tutto perché chiaramente h si pronuncia eco quindi tutti hanno cominciato a dire miteco miteco miteco ci siamo arresi e chiamiamo miteco anche noi però c'è quel piccolo barlume nel quale speriamo ancora che prima o poi mitico diventi il nome col quale tutti ci conoscono Scherzi a parte comunque, dal punto di vista della monetizzazione ci sono parecchie cose da dire anche perché è una problematica comune a parecchi progetti open source in genere, ci sono vari modi in cui puoi monetizzare un prodotto open source.Noi siamo partiti soprattutto inizialmente con le consulenze vere e proprie quindi metti a disposizione il software, metti a disposizione la documentazione, ci sono sempre aziende che magari per un qualche motivo per un altro hanno bisogno del tuo aiuto per realizzare qualcosa perché magari sanno che gli serve web artissima non sanno ad esempio che topologia utilizzare oppure gli servono dei prototipi delle proof of concept per realizzare uno scenario che hanno in mente vogliono sapere come possono utilizzare Janus per fare delle cose oppure magari vogliono un nuovo plugin in Janus che non c'è oppure aggiungere una funzionalità in Janus, che non c'è e così via.Quindi sicuramente risposta numero uno consulenze perché quella è una delle colonne sulle quali parecchi progetti open source si appoggiano.Supporto commerciale è un altro un altro tipo di attività che forniamo anche in questo caso noi abbiamo dei canali di supporto best effort che sono una community su google groups e github vero e proprio dove vive il progetto quindi puoi aprire una issue oppure puoi fornire una contribution e noi cerchiamo di gestire le problematiche risolvere i problemi quando possiamo insomma è un best effort perché chiaramente magari siamo impegnati su altre attività allo stesso momento e allo stesso momento forniamo appunto anche canali di supporto commerciale dove magari c'è un ticketing system privato oppure siamo in un canale slack con gli sviluppatori per aiutarli quando serve e così via quindi questo è sicuramente un'altra source sorgente di revenue abbastanza importante.Per un periodo avevamo considerato anche le cosiddette donazioni che sono un'altra delle strategie di monetizzazione che alcune aziende usano però insomma per vari motivo abbiamo scelto di non farlo innanzitutto perché può creare delle ambiguità dal punto di vista delle aspettative nel senso che nel momento stesso che qualcuno fa una donazione magari può aspettarsi un trattamento di riguardo rispetto a chi invece scrive solo sulla community per chiedere una mano in realtà la donazione almeno dal punto di vista teorico è invece un qualcosa per il quale non ti aspetti nulla in cambio quindi da questo punto di vista abbiamo deciso di non introdurre questa ambiguità quindi se vuoi effettivamente aiutarci e ottenere qualcosa in cambio consulenza e supporto commerciale sono le cose da utilizzare.In realtà però abbiamo anche un paio di altri canali di qualche altra sorgente di revenue alternativa una è la licenza commerciale perché comunque Janus è un prodotto che è rilasciato sotto licenza gpl versione 3 che solitamente permette l'utilizzo, dico sempre non sono un avvocato però da questo punto di vista che io sappia può essere utilizzato praticamente in quasi tutti gli ambiti senza tanti problemi però ci sono delle aziende magari con avvocati un po più preoccupati e ansiosi che magari sono diciamo un po più resti ad affidarsi esplicitamente alla gpl versione 3 e quindi magari scelgono di comprare una licenza commerciale per avere un po' più di libertà.Ad esempio facevo l'esempio di Microsoft prima con Mixer.Microsoft aveva una licenza commerciale in questo in questo contesto.E poi abbiamo anche...diciamo noi non realizziamo veri e propri prodotti perché appunto Janus è fondamentalmente un software business to business.Quindi è una cosa sulla quale puoi costruire il prodotto ma non abbiamo il nostro prodotto come potrebbe essere Jitsi se vogliamo.Jitsi è un'applicazione che è vendibile chiave in mano così com'è noi non abbiamo un'applicazione specifica basata su Janus mettiamo a disposizione più il server vero e proprio però in realtà abbiamo realizzato una sorta di servizio che ci rivendiamo che è quello dei virtual event quindi noi soprattutto prima della pandemia facevamo soprattutto la fornivamo supporto alla partecipazione remota a vari eventi il che significa che prendevamo l'aereo, andavamo dove si teneva la conferenza, mettevamo il nostro materiale, quindi telecamere, interfacciamento con il mixer e così via, mandavamo in streaming via WebRTC l'evento e permettevamo anche alle persone da casa di presentare o fare domande e così via, quindi realizzando il tutto tramite WebRTC.Arrivata la pandemia chiaramente questo non è stato più possibile, abbiamo fatto tutto all'interno, abbiamo realizzato una soluzione di virtual event completamente virtuale appunto quindi scenario alla hop in se vogliamo quindi quello di permetterti di fare una una conferenza completamente online dove 2-3 persone parlano ad una platea di 500-1000-5000 utenti il tutto permettendo ancora a chiunque di mettersi in coda fare domande e così via e adesso è questo è un servizio che ci rivendiamo più per soluzioni ad hoc quindi non è una soluzione dove magari vai sul sito e dici voglio comprare cinque giorni di conferenza per fare x y e z ma in realtà sono soluzioni che noi costruiamo proprio secondo le necessità dell'interessato quindi per esempio gli etf di cui parlavo prima che è un ente di standardizzazione per i protocolli su internet noi forniamo proprio la partecipazione remota per tutti i meeting IETF, lo facciamo già da una da una decina d'anni ormai, secondo me uno dei motivi principali per il quale siamo siamo molto più noti all'estero che in Italia, semplicemente perché agli IETF partecipano aziende di tutti i tipi utilizzano il nostro software per partecipare ai meeting IETF e quindi diciamo il nome in questo modo un po' un po rimane ma lo facciamo anche per meeting ripe e per altri meeting e così via di solito adattando la piattaforma agli specifici requisiti della dell'azienda quindi magari ognuno ha il suo sistema di autenticazione qualcuno fa il polling in un certo modo qualcuno vuole interfacciarsi con un altro servizio qualcuno vuole il capturing e così via in pratica adattiamo a seconda delle necessità quindi da questo punto di vista questo è molto più simile ad un prodotto rispetto alle consulenze sul prodotto sul progetto open source vero e proprio però è comunque una parte importante delle nostre attività sicuramente chiaro chiaro e questo dimostra appunto il fatto che voi siete la dimostrazione del fatto che di open source in qualche modo si possa si possa vivere c'è ancora tanto da fare in termini di consapevolezza spesso quando si parla dei grandi mammut e domanda c'è mai stata la tentazione di utilizzare un approccio alla alla google? questa è una provocazione, alla java questa è una provocazione qualche puntata fa abbiamo avuto Michele Riva e parlavamo del del mondo delle consulenze.Dicevamo che ci sono alcuni prodotti che sono fatti per venderti la consulenza.Bruto da dire, ma per alcuni prodotti anche comprensibile perché qualcuno deve pur pagarla questa cosa.A questo punto come gestire questo trade-off? Non è facile, nel senso rendo le cose più semplici possibile, lavoro per avere una dev experience migliore per chi andrà a scrivere i plug in o comunque ci vado un po più leggero lascio un po più di complessità in modo che mi chiamino e io possa riempirmi il frigo perché anche questo mese sai devo mangiare.No questa è una domanda parecchio interessante io ho pensato parecchio in tutti questi anni ad esempio soprattutto la scelta della licenza all'inizio fu mezzo dramma perché anche lì devi cominci a pensare c'è una licenza che magari mi permette di incentivare magari i contributi piuttosto che chi prende la roba e scappa e cose del genere infatti per esempio noi penso la prima settimana lasciamo Janus con una licenza che era AGPL la Ferro GPL versione 3 che poi abbiamo scoperto è una licenza che è considerata tipo la kriptonite da tutte le aziende perché una licenza super virale diciamo molto problematica e quindi passiamo alla gpl versione trigger un po più accessibile diciamo che è una cosa un po problematica però è gestibile insomma quello sicuramente.Sì e tra l'altro volevo chiederti...guardiamo per un attimo quello che è successo a elastic no col suo sistema che si è ritrovata io non prendo le parti né di ews dei grandi né di elastic cerco di guardare in modo più obiettivo possibile la questione elastic aveva necessità di monetizzare di fare il profit perché aveva realizzata una tecnologia e AWS utilizzava la tecnologia in una qualche parte la migliorava pure con dei contributi e monetizzava a un'altra unità di grandezza un'altra scala quella cosa a quel punto Elastic ha cambiato licenza io non entro nel merito del abbia fatto bene abbia fatto male ma l'effetto che ha avuto questo cambio di licenza nella community un cambio di licenza che posso dire in qualche modo stimolato anche dal cercare di rendere sostenibile lo sviluppo di quel prodotto e la community ha reagito abbastanza male quindi la mia domanda è magari non direttamente riferita a Janus da maintainer open source hai paura nel meccanismo del cambiare la licenza nel meccanismo del far incazzare la community, nel meccanismo come diceva il buon Salvatore Sanfilippo del dare o non dare qualcosa che ti arriva via issue quindi ti richiedono una feature, la faccio, non la faccio, quale faccio? Sì diciamo che ci sono modi diversi di reagire perché per esempio anche dal punto di vista del come dicevi prima come incentivo le consulenze e cose del genere puoi scrivere poca documentazione ma ne puoi scrivere anche troppa perché anche l'eccesso di informazioni a volte è diciamo problematico da gestire per l'utilizzatore finale perché magari tu inondi talmente di tante informazioni le persone che alla fine si trovano appunto annegati in un mare di informazioni quindi comunque da te vengono per cercare di capire come di trovare il bandolo della matassa.Da questo punto di vista diciamo ci sono strategie diverse, noi non abbiamo mai seguito una strategia particolare, nel senso che scriviamo la documentazione quando creiamo una nuova feature ma senza preoccuparci troppo del se è troppo dettagliata o troppo poco, scriviamo quella che secondo noi ha senso e poi c'è chi trova questa informazione abbastanza per fare tutto per conto loro e c'è chi invece poi ci contatta per qualche informazione in più.Dal punto di vista appunto dell'utilizzare invece le licenze come strumenti per favorire o meno questo tipo di circostanze chiaramente io come te insomma capisco se mi metto nei panni di elastic search ma anche di altri prodotti che hanno fatto la stessa scelta all'epoca io li capisco benissimo perché alla fine anche io nel mio piccolissimo insomma con Janus alla fine ci sono i colossi che appunto che ci hanno utilizzato Ci hanno mai calcolato insomma non ci hanno mai neanche contattato magari neanche sappiamo che ci usano Ma neanche un articolo nel tech blog no? Esatto sì No, infatti già sarebbe una cosa interessante Anche il poter dire per esempio "ah il colosso ABC sta usando Janus" è una cosa...anche la pubblicità è una forma di contributi se vogliamo perché appunto vi facevo l'esempio di Slack prima Slack ha aperto comunque una un bel vaso di Pandora all'epoca quindi da questo punto di vista io con Slack un po' sono incacchiato un po' sono diciamo soddisfatto lo stesso perché sicuramente sono contento che ci hanno utilizzato e che ci ha aperto un sacco di porte dall'altro lato penso "ma avete i gazzilioni di dollari" un briciolo di consulenza, supporto, magari un problema che trovavate magari ce le potevate dare, mille lire anche a noi che stavamo crescendo ma alla fine questo vale per Slack ma vale per per tanti altri insomma quindi quando scopro di aziende che magari sono state vendute per milioni di euro che magari che so per certo che magari usano già uno stile di retro le quinte anche là mi girano le scatole perché magari loro fanno i milioni con il mio lavoro e io se voglio comprare casa devo fare il mutuo tanto per farvi l'esempio studio quindi sicuramente lavorare nell'open source non si naviga nel loro però diciamo neanche mi posso lamentare insomma sicuramente come diceva Mauro il piatto in tavola lo portiamo le famiglie le nutriamo quindi le soddisfazioni ce le togliamo quindi comunque alla fine si tratta anche di di trovare il giusto equilibrio perché diciamo insistere troppo sul trovare la licenza perfetta per fare quello che vogliamo alla fine è effettivamente controproducente perché li capisco dal punto di vista emotivo però posso capire anche la community che si arrabbia perché così come impatti l'amazon di turno, impatti la piccola azienda che col tuo software metteva a disposizione un servizio adesso magari deve spendere una fetta di soldi non indifferente per loro per rivendere lo stesso servizio che in teoria è basato su un prodotto open source quindi alla fine l'open source va preso con i lati positivi e con i lati negativi.Il lato positivo è che spesso i lati positivi sono molto di più di quelli dei lati negativi e quindi vi parlavo della community, del fatto che ci sono state migliorie al software che io non avrei mai potuto fare da solo, ci sono stati un sacco di contributi, sono stati un sacco di test c'è un'attività continua c'è stata anche un'esplosione di creatività grazie a Janus della quale sarò sempre fiero e questo fa parte di tutti i lati positivi che quindi rappresentano tutte le soddisfazioni.I lati negativi è che appunto ci sono sempre quelli che appunto prendono la borsa e scappano alla fine però fa parte appunto dell'open source.L'open source è questo diciamo tu lo metti a disposizione poi chi lo prende non spetta a te deciderlo, insomma.Così come non puoi...alla fine, alla base dell'open source c'è proprio il fatto che non puoi discriminare chi beneficerà del tuo lavoro.Quindi bisogna accettare con un certo equilibrio, quindi chiaramente quando ci penso mi fumano le orecchie comunque, però magari poi penso ai lati positivi e penso che comunque le cose male non vanno e quindi...Dico vabbè, potrebbe andare peggio, insomma, quindi si va bene anche così.che poi direi che non è manco un problema di licenza, è proprio un problema di educazione cioè prendi una cosa, la usi, avvisami.sì il problema è che appunto più grande è l'azienda più ci sono mentalità diverse proprio nell'utilizzo dei software perché alcune volte il discorso è non dico che software uso perché potrei dare un vantaggio competitivo ai miei competitor che magari vogliono fare la stessa cosa e sanno che uso il software X e magari ci provano anche loro e lo fanno meglio di me oppure ci sono problematiche di natura legale oppure ci sono problematiche di...alla fine le aziende enterprise sono così complesse che alla fine non sai mai effettivamente quali sono le vere motivazioni che ci sono dietro perché magari vai alle conferenze incontri le persone che veramente ci lavorano su queste cose sono persone squisite tranquillissime ci diventi anche amico e cose del genere però poi vedi che si ritornano in contesti dove effettivamente hanno le mani legate dove magari veramente non possono neanche fare un contributo per un progetto open source perché è impedito dal punto di vista del livello aziendale un contributo open source che non sia autenticato a vari livelli manageriali che devi passare attraverso 100 livelli diversi prima che venga approvato un minimo contributo perché ogni contributo è dal punto di vista legale un qualcosa che bla bla bla e quindi alla fine proprio per questo insomma meglio lavorare magari con aziende un po più piccole dove spesso ci sono ragazzi molto bravi, smanettoni, interessanti eccetera e quindi piuttosto che preoccuparsi troppo di quello che fanno i colossi insomma.Chiaro, chiaro.E comunque a morte i vampiri dell'open source.per citare un nostro ex ospite e anche collega.Io guardavo l'orologio, in realtà avrei tipo altri tre post it di domande da fare ma abbiamo superato l'ora e mezza colpa mia che parlo troppo, bisogna affucinarmi ogni volta che apro bocca bellissimo perché in realtà sei riuscito a farci uscire dalla nostra zona di comfort senza sentire la fatica di uscirne e per questo ti ringraziamo ma non ti lasciamo ancora probabilmente la tua famiglia ti starà reclamando ma ormai sei sulle nostre sono solo tre gatti affamati, però possono aspettare.Perché un momento tipico e topico del nostro podcast è il Paese dei Balocchi, il momento in cui i nostri ospiti condividono con noi un libro, un video, un talk, qualunque cosa abbia catturato la loro attenzione e insomma sentano il piacere di condividerlo.Hai qualcosa da scerare? Forse lui sta registrando.Sì sì adesso ti sentiamo di nuovo.Ah ok, dicevo, ho qualcosa che valga la pena condividere con la nostra community.Hai qualcosa da scerare? Ma quindi dal punto di vista lavorativo o generico proprio? Qualunque cosa tu voglia.E conduco nel paese dei balocchi.Ah, il paese dei balocchi.Sì, come dicevo, mi piace molto lavorare in ambito musicale, quindi proprio per ufficio mio registro canzoni, pubblico cose e così via.Purtroppo niente di indimenticabile, se no sarei Beyoncé e sarei famosissimo.Però da questo punto di vista sono molto interessato sempre in ambito open source a tutte quelle applicazioni che ti permettono di lavorare su questi ambiti di produzione.quindi soprattutto per quelli che magari masticano un po' Linux suggerisco di lavorare, di dare un'occhiata ad un framework di cui ho parlato precedentemente che si chiama Jack che alla fine è un framework anche quello molto modulare che ti permette di mettere in comunicazione applicazioni completamente eterogenee fra di loro quindi puoi prendere un' applicazione che registra audio e attaccarla ad un'altra applicazione che che magari ti fa un processing per la chitarra e ti metti, parli e in pratica vieni distorto da questo software, praticamente in comunicazione applicazioni completamente diverse per realizzare scenari particolari e questo infatti era un topic di cui prima o poi vorrei parlare proprio al FOSDEM dove effettivamente la produzione musicale non è spesso affrontata proprio per descrivere in maniera generale un ecosistema enorme di cui si conosce poco soprattutto in ambito di linux che in realtà è parecchio interessante quindi jack come framework e tutte le varie applicazioni che possono essere utilizzate in questo contesto che secondo me soprattutto per chi ama la musica in generale può essere una un'esperienza interessante soprattutto esplorativa.vero, bellissimo.tieni presente che come parlavi di Jack, a me hai riaperto il mondo dei VST, degli audio units, sono tornati indietro di 6 anni.LV2, tutto, tutto, sì sì, c'è un mondo enorme, una volta che entri in questo mondo poi sei proprio tu che ti devi fermare perché si apre veramente un mondo.Luca, tu hai qualcosa da condividere? Ma già che ci siamo, è un balocco un po' strano perché è un ebook che deve ancora uscire, però è un'antologia, si chiama "Distopia vs.Utopia", perché lo consiglio? Soprattutto non l'ho ancora letto, però nei vari racconti che ci sono dentro c'è un racconto di un mio amico che bravo, ho letto un suo libro che si chiama "Quando scendere la notte", un altro balocco che butto così, che è carino, però in realtà avevo chiesto a questo mio amico, "Giacke, te che scrivi?" Mi ha detto "Ma perché non fai un racconto dove c'è un mondo in cui è rimasto soltanto un povero cristo programmatore, che deve reggere tutto quello che c'è nel mondo, di tutto ciò che è informatico.Parliamo di open source e di grandi colossi.Esatto, non ho la minima idea, chissà che cosa avrà fatto e alla fine ha accettato questo mio input, non ho la minima idea di che cosa abbia fatto e quindi dal 3 maggio uscirà questo book con vari racconti tra cui questo che mi sembra già parte bene cioè mi è simpatica come cosa quindi distopia versus utopia.Forse un altro piccolo balocco che posso darvi che forse può essere anche di interesse è una presentazione che ha fatto una persona che conosco un americano che era sui sui miti e sul fad del che quando si parla di open source in generale una presentazione di una mezz'oretta più o meno che è anche parecchio divertente perché lui parte da un blog post che fece un'azienda che cercava di buttare fango sull'open source e quindi poi lui lavora passo passo per per per sfatare insomma tutti questi miti e questo fad che vengono vengono buttati sull'open source in generale e quindi soprattutto visto che l'open source è stato un argomento principe anche di questa di questa conversazione può essere interessante.Assolutamente sì, bello.Mi raccomando Lorenzo e Luca se riuscite a farmi avere i link così li mettiamo direttamente nelle note dell'episodio.Io per parlarvi dei miei balocchi che sono qualcosa tipo 3, ho riaperto Amazon e tra l'altro la prima cosa che mi salta all'occhio è tipo i pannolini di mia figlia e le ricariche per il cestino della mondezza di pannolini.No, scherzi a parte.Allora, il primo balocco sono due libri e un'altra roba un po' strana.Il primo libro che ho appena iniziato ed è "Staff Engineer".Io sono ciclico, ci sono dei periodi dove mi concentro completamente sul codice e dei periodi dove mi concentro sulle persone.Sta iniziando un nuovo periodo dove mi concentro sulle persone e quindi ho recuperato questi due libri.Il primo è "Staff Engineer Leadership Beyond the Management Track" e il secondo ne abbiamo già citato che non ho ancora iniziato però è "The Manager Path" ne abbiamo già parlato in un altro episodio.Detto questo è aver ripinguato la lista di cose da leggere che immagino sarà almeno tanto quanto la mia.Vi aggiungo una cosa stupida ma che a me ha cambiato completamente la vita.Io faccio full remote, lavoro da casa e la mia scrivania non è troppo lontana dal frigo.C'è stato un periodo dove arrivavo a bermi una bottiglia e mezzo di Coca Cola perché quando sei concentrato devi avere qualcosa in bocca, devi sgranocchiare o devi bere qualcosa e questa cosa no buono per la salute.Quindi sono andato alla ricerca di una soluzione e l'ho trovata.Quello che sto bevendo mentre lavoro è l'erba mate e questa cosa mi sta piacendo tantissimo quindi mi sono ordinato da internet una bella bombiglia che è il bicchiere con il quale l'erba mate si beve, è di ceramica però ed è facilmente lavabile.Insomma provatela perché è veramente...Lorenzo ha portato e ha mostrato la sua bombiglia, fantastica! Quindi anche tu una dikted per il mate? No in realtà è solo un souvenir di quando andai in Argentina, però ho bevuto un paio di volte ma non mi considero ancora una dikted, non più un fan del tè verde in generale.Sai cosa mi piace dell'erba mate in realtà? Che io la preparo alle 9 del mattino quando inizio a lavorare e comunque aggiungo l'acqua tra una cosa e l'altra mi dura praticamente tutta la giornata e alla fine sto bevendo quasi esclusivamente acqua se poi faccio la summa e ha fatto il complete replace di 5 o 6 di Red Bull o di una bottiglia e mezzo di Coca Cola con buon beneficio per la pancia e per la salute quindi siccome la salute è importante mi sentivo di condividere questa cosa detto questo e guardando l'orologio e anche i miei occhi la stanchezza si fa sentire quindi io ringrazio infinitamente Lorenzo, grazie per essere venuto a trovarci grazie a voi per avermi ospitato e per essere stati pazienti con le mie lunghe divagazioni chiedo a Luca se ha qualcosa da dire niente per adesso devo metabolizzare tutto quello che è stato detto in un'ora e 46 minuti e poi mi verranno altre domande e faremo un'altra puntata L'ammolo di informazioni che Lorenzo ci ha dato è enorme, è veramente gigante e noi lo ringraziamo infinitamente, non solo io, di Luca, ma anche di tutta la community e gli ascoltatori di Gitbar Grazie per essere venuti a trovarci e grazie per aver realizzato un tool, un server, qualcosa che in realtà in qualche modo ci sta cambiando le vite.Infatti spero anche di aver incuriosito magari gli ascoltatori, magari avranno qualche altra idea interessante per fare qualche nuovo progettino adesso.Nelle note dell'episodio metteremo il link a Janus, il link a MITICO, spero di averlo pronunciato bene.Ci riusciremo, ci riusciremo.E tutti i riferimenti di Lorenzo.grazie davvero Lorenzo, grazie di cuore.Ciao grazie.Ciao! Gitbar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica]
