Topic: [IDEA] Tutto-fare a Bitcoin / Multisig / Escrow / Feedback (Read 7854 times)

Qualcosa del genere è arrivato: Rein (ancora poco usabile per l'utente finale, ma già operativo).

Rimando alla discussione dedicata.

Per renderlo più aderente a questa discussione probabilmente basterebbe affiancarlo a qualche sistema di geolocalizzazione e WebGIS; niente di troppo difficile se lo si fa in modo centralizzato (anche solo per una fase iniziale).

Per la chat forse basta il sistema di comunicazione interno di Rein; in alternativa si potrebbe pensare a Tox.

Sarebbe insomma da mettere insieme Rein, OSM/Leaflet/Apache/PostGIS/[...] e forse Tox. Un bel progettino.

Ciao!

Servizii da poco aperti:
http://te-le-trasporto.com/
https://www.supermercato24.it
http://www.foodracers.com/

In GB questa cosa è all'ordine del giorno, speriamo anche in Italia nel prossimo futuro è un buon metodo per uscire dalla disoccupazione.


Cordiali saluti.

Il mio post intendeva sottolineare che definita la differenza tra Servizi Standard e Servizi Specifici si puo' procedere allo sviluppo della piattaforma se c'e' intenzione in tal senso.

Lo farei se avessi incentivo ma non l'ho al momento.

Io parto sempre dall'assunto la Scienza e' certa e di conseguenza si ottengono definizioni assolute (da qui la definizione dell'entita' Servizio).

Ultimamente ho approfondito le mie lacune in campo di fisica quantistica e mi sono reso conto che la Scienza e' certa e' una definizione pre 1924 (Ipotesi di de Broglie - https://it.wikipedia.org/wiki/Ipotesi_di_de_Broglie).

Nella Vita non si finisce mai di imparare.

Ringrazio comunque l'utente HostFat che buttando benzina al fuoco ha fatto emergere queste lacune.


Cordiali saluti.

http://www.bloomberg.com/news/articles/2015-09-13/baidu-s-li-says-investors-don-t-get-china-s-coming-internet-boom

Questo articolo mi sembra in qualche modo rilevante

Ora devo dire la mia idea che in realta' e' un fastidio:
la discussione l'ho improntata da un punto di vista tecnico, quindi ci tengo che resti in questo modo fino a che non si raggiunge un obbiettivo. Per raggiungere un obbiettivo il sarcasmo e' la risorsa meno indicata da utilizzare.

La mia idea per sviluppare un tale sistema l'ho gia' spiegata e non mi ripeto ovviamente non conoscendo la preparazione tecnica del lettore.

Quello che serve per andare avanti nella definizione di un tale sistema e' identificare la differenza tra Servizi Standard e Servizi Specifici.

Identificata questa differenza si riesce a procedere con la definizione della entita' Servizio che l'Utilizzatore del Servizio (U) scambia con l'Offritore del Servizio (O).

Per farla piu' semplice: la piattaforma e' uno scambio di Servizi da U ad O.
(O) Offritore del Servizio: mette a disposizione un servizio attraverso la piattaforma.
(U) Utilizzatore del Servizio: consuma il servizio attraverso la piattaforma.

Vabbe' mi sono ripetuto...

Tralasciando la mia ripetizione continuiamo come ho intenzione di sviluppare una piattaforma di scambio servizi: per definire l'entita' servizio serve capire quali sono le proprieta' che questa entita' possiede, come gia' scritto io ho identificato due tipi di servizio: Servizio Standard e Servizio Specifico.

La mia identificazione e' basata sulle proprieta' che i servizi possiedono appunto.

Delinare una netta differenza tra servizio standard e servizio specifico permette di definire le proprieta' dell'entita' servizio, che e' l'entita' fondamentale che si scambiano gli utenti della Ns. piattaforma.

Queste sono le basi dei database relazionali. Quando ho tempo magari scrivo di piu'...

Per definire una piattaforma io parto sempre dal Database (approccio Bottom-Up): se comprendo i dati come vengono rappresentati si comprende come sviluppare l'applicazione.

Altri hanno un approccio Top-Down: partono dalla UI e descrivono il funzionamento dell'applicazione. Realizzare un'applicazione Top-Down e' molto piu' complesso e bisogna avere un'ottima conoscenza di quello "che sta sotto" altrimenti si rischia di tralasciare un sacco di dettagli utili allo sviluppo di un'applicazione completa come si vuole fare in questo caso.

Fino a che non perfeziono il mio sviluppo Bottom-Up non mi avventuro in uno sviluppo Top-Down. L'esperienza si fa' partendo dal basso non dall'alto.

Siccome questa' e' una piattaforma per lo scambio di Servizi parto a definire le proprieta' del Servizio appunto: delinare una netta differenza tra servizio standard e servizio specifico permette di definire le proprieta' dell'entita' servizio, che e' l'entita' fondamentale che si scambiano gli utenti della Ns. piattaforma.

Definite le proprieta' dell'entita' servizio si puo' procedere oltre con lo sviluppo della piattaforma.

Nota personale: quando si definisce l'entita' servizio il 90% del lavoro e' fatto essendo l'entita' servizio, l'entita' principale su cui si muove tutta la piattaforma.

Spero nessuno ne approfitti per rubarmi l'idea: ad ogni modo non ho fatto altro che usare una metodologia per lo sviluppo di database relazionali, quindi non potete veramente rubarmi niente da questo punto di vista.

"Grazie."

Cordiali saluti.

Questo e' quello che ho detto anch'io all'autore del Post (HostFat):


Il sarcasmo nelle discussioni non aiuta mai: quindi se evita il sarcasmo sarebbe costruttivo per questa discussione.

Grazie.


La discussione non l'ho aperta io: se evita di confondere le parti e' piu' utile alla discussione.

Grazie.

In linea generale se volete la mia opinione: O si procede ordinati o non arriviamo da nessuna parte. Ma cerco sempre di evitare la mia opinione, perche' nel Fascismo e' meglio lasciare apertura alle interpretazioni/idee altrui ed io sono il Duce.

Grazie.

Buona domenica sera.

Ah, beh, certo: se si dispone di una squadra di individui dotati di poteri extrasensoriali (tipo i pregog di Minority Report) forse (forse!) si può implementare anche un oracolo utilizzabile per questo scopo.

FacendoLe i più sinceri auguri di buono sviluppo, Le porgo i miei ossequi.

Esatto! Ma nemmeno io ho detto che bisogna utilizzare un Oracolo generico!

?!?

Perche' se dico di usare un Oracolo Lei pensa che io stia parlando di un Oracolo generico?!?

L'Oracolo e' una tecnica informatica: si puo' implementare per le proprie esigenze!

?!?

(Riflessione Personale: Chi diavolo ha mai parlato di Oracoli generici?!?)

Buona Domenica e colgo l'occasione per porgerLe i piu' sentiti Distinti saluti.

Grazie!

Sì, ma ti dice quando un evento noto (o matematicamente modellabile) è accaduto. Mica può sapere se effettivamente il signor Peppino è andato alla tale lavanderia di un certo paesino a ritirare il bucato della signora Marcella.

Altrettanto!

L'oracolo indica quando un evento e' accaduto.

Buona Domenica.

Cosa c'entrano gli oracoli?

Le parti coinvolte nello scambio del servizio sono:
1) Utente 1 che vuole utilizzare il servizio
2) Fornitore del servizio
3) Utente 2 che effettua il servizio per l'Utente 1 prendendolo dal Fornitore
4) Escrow o Oracolo?!? per gestire il pagamento del servizio dall'Utente 1 all'Utente 2

La cosa fondamentale e' la UI, tutto il sistema viene gestito da Oracoli.

Una discussione interessante sugli Oracoli la potete trovare qua:
https://bitcointalksearch.org/topic/oraclizeit-smart-contracts-today-958619

L'Oracolo è la scelta.

Non credo che si avvicini a ciò che penso io, credo che BitHalo sia più simile ad Open Bazaar.
Quello che immagino io non è qualcosa di simile alle solite "pagine gialle", bisogna appunto guardare getmagicnow.com e il video che ho messo per capire.

L'utente non deve vedere nessuna lista, deve solo scrivere cosa vuole.
Il servizio deve metterlo in contatti con i vari "tutto-fare" che si scannerebbero per proporre il prezzo migliore, come avviene sugli exchange.
Poi sempre l'utente sceglierebbe fra quelli con il prezzo per lui migliore alcuni con cui avviare una discussione privata.

Mi ricorda il market di BitHalo
https://bithalo.org/update/?page_id=326

Questo era esattamente quello che cercavo di risolvere con la mia definizione di servizi standard, servizi specifici.

Se volete fare qualcosa di rivoluzionario dovete pensare i grande.

Pensate come un'applicazione "grande" si comporterebbe in quel caso, che ne so' JobRapido per esempio e pensate a come applicare a quella piattaforma grande le vostre funzionalita' rivoluzionarie.


"Se non pensate come la maggior parte della gente non risolverete mai i problemi della maggior parte della gente."


Alcuni esempi di piattaforme di ricerca lavoro che potrebbero darvi ispirazione:
-) Monster www.monster.it
-) Bakeca www.bakeca.it
-) Indeed www.indeed.com
-) JobRapido www.jobrapido.com

"Grazie."

Hmm, si, direi che potrebbe andare. L'importante è che la chat dove prima definire meglio pubblicamente cosa si vuole, la pagina delle offerte, e l'eventuale chat privata con il "tutto-fare", rimangono divise fra loro.
Le offerte dei "tutto-fare" non devono finire nella chat pubblica, che sarebbe troppo caotico.

L'idea non e' tanto del canale ma del metodo, chi vuole un servizio scrive quello che vuole apertamente, che sia email, sms o form libero (dopo aver indicato tempi e luogo in modo strutturato), chi legge interpreta e fa offerta o domanda via chat per approfondire se non capisce qualcosa.
Poi chi vende struttura offerta con: costo immediato (valuta), costo alla consegna (valuta), totale (valute), tempo ecc ecc in una tabella che l'utente ordina come meglio crede anche solo in js

Si anche l'idea di filtrare è buona.
Sul fatto del canale IRC, il problema è giusto che non sarebbe facilmente usabile per l'utente finale.
L'utente dovrebbe sempre vedere le proposte che si sovrappongono in ordine di prezzo e/o feedback e/o altri valori.

Mi viene in mente una specie ci canale IRC dove chi scrive scrive broadcast e chi legge legge in modo filtrato su parole chiave e in base alla zona (centro e raggio) dichiarato da chi scrive.
Se qualcuno e' interessato ad offrire il servizio risponde  altrimenti ignora.
EDIT: filtrato intendo anche mettere il block list eventuali parole che non interessano tipo figa, droga ecc. ecce. perché mi sa che il servizio si presta principalmente a certi servizi ....

Ricorda: se una persona sembra pazza, e' pazza davvero, oppure e' un economista.

Ripeto quelli che sono riusciti a risolvere questo problema in maniera cosi' semplice sono un Laboratorio di Ricerca della NASA.

O si procede ordinati o non arriviamo da nessuna parte.

Al massimo arriviamo a definire le specifiche per una piattaforma per consegne pizze a domicilio.

Il servizio offerto è mettere a contatto gli utenti fra loro, non ci interessa cosa vogliano fare fra loro.

Si. Quello che tu ora hai definito con l'inglesismo "taggare" io chiamo ancora servizio.

Servizi diversi vengono presentati in maniera diversa.

Io ho identificato due tipi di servizi:
1) Servizi standard
2) Servizi specifici

Se definiamo le proprieta' dei servizi riusciamo ad identificare tutte le tipologie di servizi da implementare (magari sono piu' di due! ...).

Questa e' la basa da cui poi definire la Piattaforma.

"Prima si definiscono le proprieta' del servizio offerto poi si disegna la Piattaforma che ci sta' intorno." (rif.: Pratiche di sviluppo software)

Ho studiato da Perito Capotecnico Industriale se non ho i punti fissi non riesco a procedere con ordine.

Penso che la soluzione più facile sarebbe che l'utente può si scrivere quello che vuole, ma può anche "taggare" la sua richiesta, con tag già pronti o scrivendone di suoi.

Dall'altra parte il "tutto-fare" potrebbe indicare di voler ricevere le notifiche di "tutto", oppure solo di quelle taggate in un certo modo, tipo tag "pizza", o "giardino", "lavaggio" "macchina" ecc ..
O anche semplicemente parole chiave, certo starebbe nel "tutto-fare" nel individuare prima le parole chiave più probabilmente usate dalle richieste dell'utente.

Esempio:
- L'utente scrive "Vorrei ordinare una pizza con carciofi da portare alle ore x nel posto y"
- I "tutto-fare" avrebbero precedentemente impostato di ricevere tutte le notifiche delle segnalazioni che abbiano al suo interno la parola pizza
- Da li si tornerebbe allo scontro di offerte.

Si. Ma... quello e' un servizio offerto da una Compagnia.  

Loro offrono il servizio non c'e' nessun altro: solo l'utente che richiede un servizio di qualsiasi genere e la compagnia che offre qualsiasi servizio l'utente richieda (e se guardi la Compagnia che fornisce questo servizio Plus Labs Inc. e' posizionata in un Laboratorio di Ricerca della NASA! Ci sara' un motivo... http://www.pluslabs.org/ )

Penso che il servizio debba prima di tutto mettere a contatto gli utenti, cosa poi si scambino fra loro e in qualche modo (quale servizio/oggetto) sarebbe scelto fra loro direttamente via chat.
Gli automatismi e l'uso di vari template potrebbe rendere si più automatico e veloce il servizio, ma potrebbe anche andare a limitare le offerte e il loro dinamismo.

L'idea vorrei ricordare che parte da quanto ho linkato nel primo messaggio: getmagicnow.com , dove si chiede quello che si vuole via chat/chiamata ... nessun template.

"Si"... se non definiamo le caratteristiche del servizio non riusciamo a definire la piattaforma (il servizio e' la cosa principale offerta dalla piattaforma).

So che mi capisci... ma bisogna essere precisi altrimenti va' tutto a carte 96.

Secondo me' il fattore specifico che determina un servizio piuttosto che un altro e' la velocita' di fruizione (consegna) del servizio.
1) 2 pizze e due birre: due click e le voglio a casa
2) tagliare l'erba del prato: posso prendermi 30 minuti per decidere bene i termini della cosa
3) tagliare i capelli: posso prendermi 30 minuti per decidere bene i termini della cosa
4) lavare i vestiti: posso prendermi 30 minuti per decidere bene i termini della cosa

In pratica le caratteristiche di un servizio vengono definiti in base alla qualita' del servizio che si vuole offrire all'utilizzatore del servizio (U).

In pratica per definire i servizi offerti si guarda dal punto di vista dell'"utente". L'utente e' al centro della piattaforma ne' l'offritore del servizio (O - tutto-fare), ne' l'Escrow (A), ne' la Piattaforma stessa (T).

L'utente e' il punto di vista da cui si decidono le caratteristiche del servizio da offrire.

Se non ci mettiamo d'accordo su servizi standard e servizi specifici non riusciremo mai a metterci d'accordo sulle informazioni necessarie a definire un servizio in se.

Per farla "drastica" ogni servizio potrebbe avere una piattaforma a se dedicata: piattaforma per la consegna cibo, piattaforma per il taglio dell'erba, piattaforma per il taglio di capelli, piattaforma per il lavaggio delle mutande, etc...

Questo perche' se non definiamo il concetto di servizio (entita') non riusciamo a definirne le proprieta' (caratteristiche) principali e quindi di conseguenza in fase di sviluppo non sappiamo come integrare tali entita' all'interno dell'applicazione: mancanza sia dal punto di vista logico sia dal punto di vista dell'interfaccia utente.

Questo va' bene per servizi di tipo standard (taglia l'erba del giardino) in cui si presuppone il costo "standard" sia diverso da Offritore del Servizio (O) ad Offritore del Servizio (O) e in questo caso si presuppone l'Utilizzatore del Servizio (U) abbia piu' tempo a disposizione per valutare le eventuali variabili in gioco (tempo/luogo/prezzo).

Esempio: posso ordinare il taglio dell'erba il Martedi sera dopo lavoro per il Sabato pomeriggio e non ho problemi a spendere 30 minuti/1 ora a trovare il tutto-fare piu' economico per tagliare l'erba del prato.


Se voglio un servizio di tipo specifico (due pizze boscaiola e due birre) (U) non vuole perdere tempo nella scelta del costo: il 93% del costo e' gia' dato dal servizio per se (le due pizze e boscaiola e le due birre) il restante 7% sono spese di consegna da parte di (O) (4-5%) e spese della Piattaforma (T) (1-2%).

In questo secondo caso le spese di (O) non variano molto da "tutto-fare" a "tutto-fare".

Non si vuole tediare il cliente (U) con una scelta che giova un risparmio del 1-2% a scapito di fargli perdere tempo nella scelta del tutto-fare e dell'escrow.

Per i servizi specifici si vuole che la procudura sia il piu' veloce possibile. Proprio come nella piattaforma che indicavi (getmagicnow): inserisco l'ordine "due pizze boscaiola e due birre", scelgo l'escrow, pago e mi siedo in divano ad aspettare l'arrivo delle pizze e delle birre.

"Choose, pay and wait for the food to be delivered to you."

Come ordine di apparizione sul sito, ci sarebbe il template o meno, a seconda del servizio indicato, poi ci sarebbe come si vuole che venga offerta la soluzione all'utente.
Tu proponevi che il servizio trovasse lui la corrispondenza preferita per l'utente, e certo questo potrebbe essere apparentemente più userfriendly, ma non è detto che si otterrebbe il prezzo più basso.

La mia proposta iniziale invece era quella di mettere in diretto scontro, in contemporanea, tutti i "Tutto-fare, e che fosse appunto l'utente a scegliere lui le offerte che più gli sembrassero interessanti.
Nella schermata che mi immagino, sia l'utente che i vari "tutto-fare" vedrebbero le varie offerte apparire.
Quindi se ad esempio un "tutto-fare" si proponesse per 10 euro, magari potrebbe vedere apparire sotto di lui altri X offerte: 9.99 / 9.90 / 9.50 / 8.00 / ..
Proprio vedendo quelle offerte, potrebbe lui cercare subito di abbassare la sua sperando di acchiappare l'attenzione dell'utente.

Dall'altra l'utente vedrebbe appunto questo scontro di proposte, e relativi dati sui feedback degli utenti.
Da li potrebbe scegliere semplicemente l'offerta migliore come soldi richiesti, oppure una leggermente più costosa, ma con indicati più feedback a fianco.

Il fatto del template per delle proposte già pronte è una cosa che può essere fatta dopo nello sviluppo di un simile servizio.
Sarebbe una cosa per lo più utile ai "tutto-fare" che all'utente in se.
Questo perchè magari un "tutto-fare" non vorrebbe ricevere segnalazioni di richieste per qualsiasi cosa, ma soltanto appunto magari per richieste di "pizze".

Se non definiamo i servizi offerti dalla Piattaforma non possiamo metterci d'accordo sul suo funzionamento.

Per aiutare la discussione questa e' la mia idea:
-) servizi standard (tagliare l'erba del giardino)
-) servizi specifici (consegnare due pizze boscaiola e due birre)

I due tipi devono essere trattati in maniera differente.

Ad ogni modo stai gia' parlando di qualcosa in piu':
-) una cosa e' cercare un servizio per la cui descrizione puo' essere definito uno standard (tagliare l'erba del giardino)
-) una cosa e' cercare un servizio specifico (voglio due pizze boscaiola e due birre)

sono due tipi di servizio diversi: uno e' un servizio generico che non richiede ulteriore descrizione, l'altro e' un servizio specifico per cui il template non puo' esistere a meno che non inserisca di volta in volta la richiesta.

Oppure stai cercando di affrontare le due cose assieme contemporaneamente, il quale mio suggerimento e' comprendi la differenza tra i due tipi di servizio (servizio generico e servizio dettagliato) ed "il flow" dell'applicazione ti risultera' piu' chiaro.

E potremmo parlare una lingua piu' comune... il che e' indispensabile per raggiungere una qualche forma di obbiettivo.

Sono d'accordo.

Per il punto 2 non è detto che la piattaforma debba lei trovarmi per forza immediatamente una corrispondenza. Ha più senso nel caso ci sia appunto la "lista professionisti".
Semplicemente la piattaforma potrebbe mostrare la "domanda" per il servizio a tutti i "Tutto-fare" iscritti, poi questi "ora", in quel momento, si butterebbero a fare offerte per averla.

Chi ha posto la richiesta per il servizio (tipo la pizza), so vedrà apparire X offerte, e cliccherà su quella che preferisce.
A fianco di ogni offerta dei "Tutto-fare" che riceve, vedrebbe anche indicati dei numerini relativi ai loro feedback, età account ecc ...

Chi fa la richiesta (ordinare una pizza) potrebbe già trovarsi un menu dove proporla:
1) Cosa vuoi: lista di scelte proposte (ordinare pizza/pulire macchina ...) / o "scrivi tu"
2) Scelta dell'escrow:
3) Non obbligatorio: scelta del prezzo che si preferirei pagare
4) Invia richiesta

Questa e' l'Internet delle Cose applicata alle persone, una specie di Internet delle Persone.
4 Giocatori:
O) Offritore di servizio
U) Utilizzatore di servizio
A) Gestore di contese (Escrow)
T) Piattaforma

Il gioco funziona cosi':
1) io utilizzatore del servizio (U) inserico la richiesta per un servizio che mi interessa (esempio: consegna di due pizze a domicilio montanara e due birre) ad un tempo prestabilito (tipo le 20:30, tra mezz'ora, etc...)
2) La piattaforma (T) mi trova una corrispondenza per servizio/ora tra gli offritori di servizio (O) iscritti alla piattaforma, mi da l'OK che il servizio puo' avere luogo e mi comunica il prezzo per lo stesso.
3) (T) mi mostra una lista di gestori delle contese (A) da utilizzare con quel offritore di servizio ("convenzionati") oppure una lista di gestori di contese generici se non trova una corrispondenza per quella combinazione di offritore di servizio/gestore di contese appropriata (nessun O convenzionato con A).
4) A questo punto (U) scelgo il gestore delle contese che piu' si addice ai miei gusti e gli invio i soldi pattuiti per il servizio al punto (2) (questa parte avviene in automatico tramite un "carrello di checkout" come per un normale sito di consegne a domicilio).
5) (O) espleta il servizio per (U)
6) (O) riceve i soldi da (A)

Notare che non ho usato Bitcoin... la cosa puo' avvenire con qualsiasi forma di pagamento al bene che il Gestore delle contese (O - Escrow) sia affidabile.


NOTA: il punto (2) e' il centro di tutta la funzionalita' della Piattaforma (T). Qua si possono decidere due modi di operare:
1) (T) presenta (U) con una lista di (O) disponibili e (U) sceglie quello che piu' si addice ai suoi gusti
2) (T) decide direttamente l'(O) piu' appropriato per espletare quel servizio nel migliore dei modi (Qualita' del Servizio).
in entrambi i casi se non c'e' un (O) che possa espletare il servizio al tempo prestabilito (T) mi comunica che il servizio non puo' avere luogo.

non capisco questa ostilità/presa di posizione. Comunque non disturberò più la tua "quiete".

Per piacere, parliamo di cose che esistono e che funzionano.
Qualsiasi altro messaggio che tratti Ethereum/alt-coin che non siano precise specifiche e/o codice funzionante verrà immediatamente cancellato da questa discussione.

tutto questo si potrà fare con ethereum (che ha una sua blockchain)

La blockchain del Bitcoin non è adatta a tenere questo genere di informazioni.
Servirebbe una blockchain dedicata, e quindi un network completamente p2p/decentralizzato e open source per realizzare una cosa simile.
Servirebbe anche un sistema di consensus adeguato.

Tutto questo avrebbe un costo di realizzazione e di tempo che credo vada ben oltre quello per realizzare il semplice servizio centralizzato, e anche l'incertezza di arrivare da qualche parte imho.

Gli stessi di Open Bazaar infatti pur essendo il sistema p2p, non hanno messo una blockchain interna, e ogni "negozio" ha bisogno di tenere avviato un server per tenere attiva la propria "insegna".


Eviterei quindi di pensare ad un sistema completamente p2p e decentralizzato con eventuali blockchain.
Si tratterebbe di un servizio privato, fornito su una pagina web/app.

Si potrebbe rilasciare open source tutta la parte "client", più che altro per un semplice fatto di sicurezza, ma rilasciare anche la parte server probabilmente sarebbe come spararsi sui piedi e ritrovarsi fin da subito X concorrenti contro.

Poi eventualmente si potrebbe in futuro studiare modi per renderlo sempre più decentralizzato.

Secondo te/voi, quanto e' in grado una blockchain di contenere le informazioni relative all'offerta lavorativa, il sistema potrebbe essere utilizzato non solo dai disoccupati ma anche da aziende che lo fanno di mestiere (bisognerebbe ridurre la solita "lotta tra poveri" tra imprenditori alla canna del gas che si lamentano di chi gli porta via il lavoro con lavoro nero), si crea un servizio su blockchain con protocollo libero e almeno una implementazione GPL e poi si lancia la chain e il tutto avviene p2p.
A mio avviso ci vuole un "albero" delle competenze e dei curricula che fanno riferimento alle competenze possedute, ci saranno due tipi di relazioni tra le competenze e i personaggi, una autovalutazione e una di feedback pesate dall'importo della transazione (magari si fa il logaritmo? - bisogna evitare che uno si referenzi da solo con due avatar ... bo?), il concetto di territorio lo trovo interessante e utile, potrebbe anche essere utilizzato per lavori a distanza (sito internet ecc. ecc.), ha senso sostituire l'escrow con degli oracoli (almeno nei termini)?

E lo faresti Open o Close source?

L'idea è venuta vedendo questo servizio:
https://www.youtube.com/watch?v=YTH14kk2IrI
http://www.wired.com/2015/03/stump-magic/
http://getmagicnow.com/

E ripensando anche a quanto scritto qua:
https://bitcointalksearch.org/topic/buffa-idea-2-bounty-per-foto-paparazzi-788005

La stessa cosa si potrebbe sfruttare usando il multisig e le API di servizi come https://www.bitrated.com anche per scegliere l'escrow (o svilupparne uno interno)

L'idea sarebbe di poter contattare un servizio/network/software e chiedere se c'è qualcuno che sarebbe disposto a fare/portare una certa cosa, e quanto vorrebbe per questa operazione.

Chiunque potrebbe proporsi nella "lista dei tutto-fare".
Potrebbe esserci anche una parte con un eventuale descrizione di loro, e le loro capacità.
Comunque tutto sarebbe coperto da multisig ed escrow.

Immaginate che invece di provare a convincere una pizzeria da asporto ad accettare Bitcoin, si chiamerebbe uno di questi "tutto-fare" per andarla a comprare e farsela portare a casa!
Non so quanto andrebbe forte in italia, ma pensate a tutti quelli senza un lavoro che potrebbero sfruttare questa cosa per farsi almeno la giornata.

Potrebbe andare bene comunque nelle grandi città, e potrebbero pure anche rivendere i loro Bitcoin su Localbitcoin e guadagnarci ulteriormente.
Si potrebbero sfruttare per fare la spesa o farsi portare via la spazzatura.
Tinteggiarti il cancello, pulirti la macchina, ripararti la bici, portare a spasso il cane ...

Tutti lavori in generale per chi non può vuole spostarsi da casa o non può fare contemporaneamente con altre cose.
Ma potrebbe andare bene anche qualsiasi cosa: avrebbe un prezzo accordato fra le due parti (controllando il reciproco feedback) e passando eventualmente per l'escrow.


Immaginate di proporre un lavoro, con relativo prezzo e vedere apparire a fianco tutte le offerte dei "tutto-fare", uguali o più o meno alte, che continuerebbero a cambiare sperando di essere scelti da voi.
Ma potrebbe anche esserci la lista "dei professionisti" (o che credono di esserlo ), dove il prezzo per certe cose l'hanno già scelto loro.