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

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.