Luis-Fernando-Molina
commented
9 years ago @EzequielPostan me perdí un poco en las combinaciones, pero creo que puedo aportar los siguientes casos de uso:
Caso de Uso 1
Alice entra en la Sub App Intra User y busca a Bob. Le envía una solicitud de conexión y este la acepta. Alice entra en su Fiat over Crypto Wallet y le hace un requerimiento a Bob de que le pague 100 AR$.
Internamente lo que sucede es lo siguiente:
La Fiat over Crypto Wallet crea en el plugin DMP / Request / Money un requerimiento de AR$100 contra la clave publica de Bob (intra user).
Dicho plugin trasmite a su contraparte en el dispositivo de Bob la siguiente información:
- El monto en fiat = 100
- El tipo de fiat = AR$
- El value_channel por donde vendrá el valor (crypto network, sistema financiero, etc) (esto puede quedar para el futuro)
- La crypto network (si el value_channel es crypto network, se debe decir por cual debe llegar el valor)
- crypto_network_address donde se pretende recibir el pago
En el dispositivo de Bob, el requerimiento llega hasta el plugin que administra los requerimientos de pago y guarda todo es su log e inmediatemente arranca el ciclo de vida de ese requerimiento.
La plataforma entonces emite una notificacion para que Bob se entere de que tiene un requerimiento de pago de Alice. Esa notificación no forma parte de ninguna wallet en particular. Bob puede aceptar, declinar directamente en la notificación. También puede ignorarla y no pasa nada.
Como las notificaciones no van contra una wallet en particular, Bob puede ir en cualquier momento a la sub app Money Requests y ver lo que tiene pendiente ahí. Adicional a eso si Bob tuviese una wallet en AR$, dentro de esa wallet le aparecería como un Money Request pendinte de contestar, de lo contrario solo se vería en Money Requests sub app. (en el futuro)
Si Bob no tuviese una wallet en AR$ pero Bob ya le ha pagado a Alice anteriormente desde alguna wallet, por mas que no sea en esa moneda, entonces también le aparecerá como pendiente de contestar en esa wallet porque quizás quiera volver a hacerlo desde ahí.
En otras palabras el request estará disponible desde al menos una wallet para ser contestado. Se buscará un algoritmo que de la manera mas inteligente posible logre predecir cual es la que Bob usaría (todo esto en el futuro)
En nuestro caso Bob tiene solo una bitcon wallet, con lo cual el requerimiento le cae ahí y decide aceptarlo. Como es una bitcoin wallet, en la lista de requerimientos a Bob le aparece que le solicitaron AR$100 que equivalen a 1 bitcoin en ese momento.
Esto produce que el DMP / Request / Money en el dispositivo de Bob le avise a su contraparte en el dispositivo de Alice que el requerimiento está aceptado y el pago pronto se va a ejecutar.
El plugin de Alice recibe la noticia, confirma que el requerimiento está vigente (no se ha cancelado) y le avisa al plugin de Bob que proceda (dicho plugin como quiera esperará un cierto tiempo la respuesta y si no la recibe, comoquiera ejecutará el pago).
Para ejecutar el pago, el plugin Request / Money de Bob crea una transacción en el DMP /Transaction / Outgoing Intra User porque el requerimiento es que viaje por una red crypto a una dirección bitcon en este caso, sino, la pudiera haber creado en otro lado y se iría por otro channel.
El Plugin transaccion en el dispositivo de Bob recibe como imput lo siguiente:
- La cantidad de fiat= 100
- El tipo de fiat = AR$
- crypto currency = bitcoin
- La cantidad de cripto currency = 3 (esto se sabe porque el usuario confirmó que desea enviar este monto)
- Cruypto Address = esto sale de la dirección que venía en el requerimiento de pago.
- originator PluginId = el Id del plugin Request / Money (es donde se orgino la transaccion, pudiera ser el Id del Wallet Module si la transacción no venía de un money request y la originó el usuario desde una wallet, o el Id de un Agente que autonomamente la creó)
- Wallet = enumerador de la wallet desde donde se aceptó el request. ( si se acepta desde la sub app Money Request, esa sub app le debería preguntar al usuario desde que wallet tomar los fondos)
Con estos datos el Plugin transaccional procesa la transacción como sabemos que lo hace:
- Primero el componente NetworkService / Money ejecuta un protocolo de negocición de tasa de cambio para tratar de asegurarse de que Alice espere la misma cantidad de bitcoins que Bob le piensa enviar. Cuando se llega un acuerdo se continúa con la transacción. (si no se llega porque no se ponen de acuerdo debe intervenir el usuario, si no se llega porque Alice esta fuera de linea, el protocolo usará su configuracion para saber que hace, si espera a que vuelva en línea, si después de un tiempo lo envía comoquiera, etc, dicha configuración es algo que el usuario final puede cambiar) (en el futuro)
Luego,
- Envía 3 bitcoins a la dirección especificada.
- Debita 3 bitcoins de la wallet desde donde se acepto el request.
- Envia la metadata diciendo que ahí van los 100 pesos argentinos en 3 bitcoins.
Del lado de Alice, el plugin transaccional se entera que llegaron los bitcoins y la metadata. Realiza el crédito a la wallet donde se originó el requerimiento de pago (para esto tiene que saber que era parte de un requerimiento de pago, con lo cual debería haber un RequestAddressBook donde se registren las direcciones asociadas justamente a esto).
El componente Request Money / escucha el evento de que llegaron 3 bitcoins a la dirección que el tenía registrada asociada al requerimiento de pago y lo procede a cambiar de estado a Pagado.
Lo de arriba es una primera versión. Deberíamos discutirlo para ver si estamos en la misma página.
EzequielPostan
Transacciones entre wallets de tipos distintos
Buscamos dejar descritos los datos que debe contemplar cada basic wallet, los módulos transaccionales y el módulo de Request.
Para este análisis asumimos que queremos tener compatibilidad para enviar transacciones entre distintos tipos de wallets (hoy son crypto wallet a fiat over crypto y vuceversa). Partamos por identificar el hecho de que tenemos dos tipos de transacciones:
Sin considerar las transacciones simples entre dos wallets del mismo tipo (wallets de fiat enviando fiat entre sí y wallets de crypto enviando crypto entre ellas), debemos considerar doce combinaciones:
Los casos 2, 3, 5, 7, 9 y 10 pueden no aplicar a nuestras implementaciones/consideraciones de reference wallets pero evidentemente otras wallets podrían querer soportar dicho tipo de comportamiento. Notar que por simplicidad no estamos analizando el problema de que la crypto subyacente entre dos wallets sea diferente, tampoco que se usen otros assets fuera de fiat y tampoco que existan otros medios digitales de transmisión de valor diferentes a las cryptocurrencies (como pensamos que podría darse al digitalizarse alguna moneda hoy fiat)
Para la información manejada por el módulo de requerimientos de pago sólo importan los puntos 1 al 4 y los mencionados en 9 y 10 que involucran requerimientos de pago Para los transaccionales es indistinto si la transacción deriva o no de un requerimiento de pago por lo que se reduce a analizar dos casos. Para las basic wallets podemos asumir que también es indistinto si la transacción deriva de un requerimiento de pago.