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 ....