Lista Caratteristiche Primarie della prima release Tsunami

tsunami

#64

@Nellus la tua proposta sarebbe molto bella e sarebbe una soluzione, ma tieni presente che tutte le politiche di restrizione lato client non sono molto efficaci. Molto probabilmente se le restrizioni sono troppe la gente non userà tsunami optando per altri client.
Diverso sarebbe per politiche simili di upload dei client tsnunami verso altri client. Ma l’esperienza ci dice che se applicate solo localmente nei client a cui facciamo upload, le regole sono meno efficaci. Sarebbe cmq qualcosa, ma queste sono modifiche che non ci possiamo permettere con il team attuale. In futuro speriamo di avere abbastanza aiuti e sviluppatori per implementare qualcosa di simile.


#65

Tutti quelli che sono i problemi che vi state ponendo in termini di banda usata, si risolvono aumentando i metadati associati ai file; più o meno è già stato detto, ma mi sembrava opportuno sottolinearlo.
Mi limito ai due casi (IMO) più frequenti:
Sui file audio ce la si cava discretamente con: lunghezza, formato/codec, bitrate; titolo, artistia e magari album/anno confido che siano già forniti ai fini della ricerca.
Sui file video, oltre (o al posto) dei classici A/V, per ridurre simili sprechi (e tempo per l’utente!), direi che ci vogliono dei metadati per la risoluzione (anche approssimativa con un tag; e.g. 1080p), se è in 3D e per la sorgente video; per l’audio vorrei sapere (ad esempio) se è in dolby digital 5.1 o se è stereo, poi le lingue disponibili, eventuali sottotitoli, etc.
In questo modo l’utente ha ben chiaro cosa si troverà al termine e valuta solo sulla base del numero di fonti.

Ne consegue anche che una buona fetta dei fake verrebbe “sgamata” dall’assenza di tali metadati aggiuntivi… (sinceramente, fatico a credere che un torrent “fake” possa avere molte fonti… quindi, chi se li scarica ?)

Se vogliamo allontanarci un po’ dal target, si potrebbe pensare ad un servizio esterno; una sorta di catalogo (con opportune API per integrarlo con l’applicazione) che con un db chiave-valore memorizza tutte queste informazioni. La chiave potrebbe essere l’hash del file/torrent (così non ci sono problemi “legali” sul server), mentre il valore potrebbe essere un file appositamente strutturato (JSON ?)…
Il vantaggio di questa soluzione è che è più elegante e semplice; lo svantaggio è che potrebbe avere un costo il mantenimento del database (anche se non credo).

Quanto al mantenere la condivisione, purtroppo non si può fare di tutta l’erba un fascio e bisogna cercare di venire incontro alla maggior parte degli utenti.
Io rientro nel gruppo di quelli “ossessivi-compulsivi” che non vogliono una cartella “Download” con la roba alla rinfusa, ma dev’essere tutto perfettamente ordinato; e per varie ragioni, l’ubicazione di questo anti-universo a entropia zero è spesso (nel mio caso solo per video, libri e software) su un hard disk esterno… (N.B.: Non ce li metto subito; preferisco infognare la partizione di lavoro che frammentare i dischi esterni per ripensamenti successivi; e di tempo ne passa… perché io stesso non ne ho).

In generale sono contrario a limitazioni/restrizioni (come si diceva per i file rari); è meglio cercare una soluzione che vada incontro alle motivazioni che hanno spinto l’utente ad interrompere la condivisione.
Poi ognuno ha le sue… il NAS o l’hard disk esterno che dev’essere montato, l’SSD che dopo tot operazioni di I/O va preso e buttato, il file che lo ha deluso (tipico con film, musica e talvolta libri) o che è diventato obsoleto (e.g. software di cui è uscita la nuova versione, o che si è beccato il tipico RAR criptografato la cui password risiede da qualche parte su un sito pieno di adware il cui link è dentro un file di testo) e quindi ha deciso di eliminarlo, etc etc…

L’unica cosa secondo me è “istruire” gli utenti (tipo un breve video la prima volta che apri l’app; piuttosto che una serie di vignette) ed integrare un servizio di monitoraggio della condivisione:

  • Un semaforo a faccine, integrato nella GUI, che fornisce all’utente un feedback costante e visivo sulla sua “buona condotta”.
  • Un prompt che si presenta all’utente ogni qual volta che un file scaricato viene a mancare e, in base alla risposta fornita (a scelta fra un elenco consono; magari sviluppato dalla community), aggiorna il semaforo (se elimino un fake, il semaforo non “peggiora”; se sposto il file prima delle due settimane di cui si parlava prima, allora “peggiora”) sulla base di opportune metriche da definire.

#66

daccordo su un tempo minimo per il mantenimento dei files in share, ma due settimane mi sembrano decisamente troppe.


#67

@cyberangel allora sarei curioso di sapere qual è il tuo share ratio per un file di grosse dimensioni. Non ti parlo di un 12GB ma solo di un piccolisimo 2 GB e quanto ci hai messo a raggiungere tale ratio…


#68

non saprei davvero dirti. So che condivido tanto. Tuttavia ho l’hard disk pieno tra album musicali, serie televisive e film e molte cose le ho dovute spostare su un disco usb esterno (che non condivido). Se tengo per più di due settimane tutto quello che scarico non mi bastano 3 hard disk da 1 tera per tenermi tutto. qualche film lo tengo e condivido fino alla visione poi lo rimuovo. Tuttavia la mia è solo un opinione. Lungi da me influenzare le decisioni finali :slightly_smiling:


#69

“Tanto” in realtà non significa niente. Alto, magro,basso, sono tutti aggettivi che lasciano il tempo che trovano senza un termine di paragone.

Quindi in realtà sei una sanguisuga che prende piu’ di quanto condivide? Senza dati o numeri non puoi saperlo.

Come puoi dire che due settimane sono troppe? Non puoi. Poi solo dire che 2 sett di condivisione ti metterebbero’ in crisi con il tuo modo di utilizzo.

Lungi da me giudicare chicchessia senza dati. :saccente:
La prossima volta che metti un file in download controlla la seed ratio quando lo stai per cancellare per renderti conto. Se è maggiore di 1 (tipo 1.01 ecc) significa che non condividi “tanto” , ma solo che restituisci a mala pena. Per la rete non sei utile.


#70

Sai che c’è? hai ragione tu. Ritiro il mio commento e la mia umile opinione di utilizzatore. Come non detto. Chiedo scusa per la mia intromissione.


#71

Non devi chiedere scusa, interessarsi è il primo passo per capire. Pero’ spero che ti sia ora chiaro che hai molte sicurezze fin ora infondate.
E tutto questo indipendentemente dal fatto che mettere un tempo fisso per lo share non sia una buona idea e adattabile a tutte le situazioni, come abbiamo scritto già molto tempo fa in questo thread.


#72

Gusto per dimostrare a me stesso che so ancora postare sul forum, avrei una domanda: a che punto è il progetto?


#73

Dovevamo e volevamo dare notizie fresche molto presto, ma già che lo hai chiesto:
http://forum.adunanza.net/t/aggiornamenti-sullo-sviluppo-del-progetto-tsunami-adunanza/4818/22?u=hammon


#74

La scorsa settimana ho discusso la fattibilità con @biuken di una feature possibile:
Automatizzare lo share di tsunami e creare una modalità di funzionamento con settaggi preipostati :grin:.
Tsunami sharerebbe i file in maniera autonoma semplificando la vita alla gente…
In questo modo si potrebbero avere piu’ release durature nel tempo.

L’idea è di decidere la modalità “collezionista, normale o releaser (manuale) etc” all’installazione di Tsunami e decidere una sorta di cache o spazio percentuale da dedidicare al programma.
Ci assicureremmo così che ognuno shari sempre qualcosa e con semplicità.

Dobbiamo discuterne ancora con il devteam ma è un’idea che mi stuzzica da tempo e vorrei sapere che ne pensate.

p.s. Abbiamo anche aggiornato lo stato dei lavori sulle caratteristiche.


Aggiornamenti sullo sviluppo del Progetto Tsunami AdunanzA
#75

Se poi lo share dovesse avere una finestra sua e non condividere la finestra dei downloads sarebbe estremamente figo!


#76

Non capisco di cosa stai parlando Alex. :astonished:


#77

Penso che intenda fare due sezioni. Una per i download attivi ed una esclusivamente per il seeding.


#78

Ma dato che la GUI non c’è e non è ancora definitiva e probabilmente la cache gestirà tutto in auto quindi la sezione share perderà molta importanza se ci sarà.


Aggiornamenti sullo sviluppo del Progetto Tsunami AdunanzA
#79

Ciao a tutti ragazzi :saluta:
Per mia modesta opinione le penalizzazioni hanno sempre sortito un decadimento lento ma inesorabile del concetto che si vuole esprimere. Quindi probabilmente si dovrebbe puntare piu sulla meritocrazia quindi partendo da “0” piu condividi e maggiore punteggio acquisisci nella velocizzare i tuoi download. Cosi facendo si agevola l’intera struttura…
Ovviamente la penalizzazione dovrebbe essere implementata e mantenuta (forse a tempo) per tutte le persone che utilizzano il software diversamente da come è stato concepito. :occhiolino:


#80

OK quindi chiedo qui. Non sono richieste,per il momento,ma vorrei solo capire se queste funzione comodissime saranno implementate anche in Tsunami.

  1. Cartelle di salvataggio associate alle categorie (o etichette,è lo stesso) con riconoscimento automatico dei files (eMule Adunanza)
  2. Possibilità di spostare e rinominare i files all’interno dei torrent quando il torrent è ancora attivo (qbittorrent)

#81

Dopo la prima release pubblica vaglieremo le feature-request.
Per il momento i dev sono impegnati sulla nuova rete DHT di Tsunami.


#82

Pensavo che un’idea di base su funzioni già viste (quindi non proprio request) ci fosse già.
Se si è connessi alla rete DHT si possono trovare i files di utenti che usano un qualsiasi programma che ha la rete DHT (Dc++) oppure sempre solo i client torrent che ce l’hanno?


#83

Ciao a tutti, non so se se ne è già discusso, ma sono previsti porting (sotto forma di app fatte e finite, non robe demenziali tipo amule da installare da riga di comando come negli anni 80) per le marche più diffuse di Nas (tipo Synology/Qnap)?

Io e credo tanti altri come me avremmo veramente TANTA roba da condividere, ma tenere il PC acceso 24/7 per tenere condivise le cartelle sul Nas (che, lui si, è sempre acceso) per quanto mi riguarda è fuori discussione. Io stesso ho smesso da anni di utilizzare emule adunanza perché la download station di Synology non si connette alla rete kadu.

Secondo me ancora prima di pensare a porting per linux/mobile sarebbe più utile pensare a chi ha un Nas.

Grazie e scusate l’intrusione.