<commit_before>Milestone 3 - Interconexión de wallets
======================================
<NAME> <<EMAIL>>

En este milestone comenzaremos a trabajar sobre cómo los usuarios usarán el sistema. +
En el milestone 1 construímos una wallet que permite que un usuario reciba dinero (bitcoins) de una
persona que utiliza una billetera externa (como coinbase, blockchain.info, etc) y pueda reconocer de
quién provino el dinero. +
También permitimos poder enviar bitcoins a este tipo de wallet desde nuestra billetera. En ambos casos
registramos a esta persona que usa billeteras externas a la plataforma con una identidad que llamamos
extra user. +

Una identidad es simplemente una forma de identificar a una persona, en ocasiones tenemos categorías
para clasificar cierto tipo de identidades. En el caso que mencionamos arriba, la identidad extra user
se la asigna a personas que envían/reciben dinero usando billeteras externas a las que están en nuestra
plataforma. +
Observamos que en el milestone 2 también creamos identidades como: developer, designer y translator
entre otras. Allí vimos que una misma persona puede tener varias identidades según el contexto o forma
en que usa las subaplicaciones del sistema. +

También recordemos que remarcamos en el milestone 2 el concepto de device user. Esta identidad es quizás
la más importante dentro de un dispositivo, ya que no sólo identifica a un usuario dentro del hardware
que corre la plataforma sino que también permite relacionar las distintas identidades de ese usuario. +
En más detalle, cuando uno abre la aplicación se loguea como device user y las identidades que uno crea
al usar la aplicación (como por ejemplo crear una identidad de developer) se asocian al Device User
actualmente logueado. +
Si se hace un logout y se ingresa en el mismo dispositivo con otro device user entonces los creados por
el device user anterior no serán mostrados y cuando el usuario se vuelva a loguear con el Device User
original volverán a poder manejarse la identidad de developer antes creada. +

En este milestone entra en juego una nueva identidad que hasta ahora hemos mantenido implícita, la de
Intra User. Todos los usuarios (Device Users) tienen al menos una identidad de Intra User asociada.
Esta identidad representa a los usuarios dentro de la plataforma (trascendiendo al dispositivo). +

Entre Intra Users se podrán enviar y recibir dinero usando las wallets del sistema, la diferencia con
las transacciones que se realizan con algún extra user es que al ser usuarios del sistema tendremos
mucha más información y recursos disponibles. Por ejemplo, podemos buscar a los usuarios dentro del
sistema; realizar pagos sin que el usuario final deba escribir o siquiera conocer direcciones bitcoin;
podremos hacer requerimientoss de pagos; notificaciones de pagos, etc. +

Veamos con más profundidad estas nuevas funciones y las modificaciones que requeriremos realizar.

== Administración de Intra Users

Una identidad se puede crear en cualquier sub app que maneje dicha identidad. En el caso del Intra
User tendremos la sup app Intra User que permitirá crear y loguarse con estas identidades. Las identidades
registradas se pueden usar en todas las wallets que tiene asociadas el Device User logueado. +
Tener varias identidades de intra user dentro de una wallet le permite a un usuario emitir pagos con
cierto anonimato ya uno puede realizar cierto tipo de pagos desde una identidad especial.

=== Agregar Intra Users a nuestras conexiones - Intercambiar información

Cuando agregamos a un usuario como contacto en alguna de nuestras wallets decimos que lo agregamos
como contacto. Al agregarlo desde una sub app especial que llamaremos Sub App Intra User decimos que
lo agregamos a nuestras conexiones. +
Todo contacto debe ser parte de nuestras conexiones pero no necesariamente toda conexión debe ser un
contacto nuestro en alguna wallet, +
Supongamos que nos encontramos logueados con la identidad de Intra User A y deseamos agregar al Intra
User B como contacto. +
A través de diversas sub apps podemos buscar nuevos Intra Users, en este milestone podrá hacerse a
través de un tab de búsqueda de contactos dentro de cada wallet para agregarlo como sólo a la wallet
o desde la misma sub app intra user para agregarlo a como conexión del intra user logueado en ese
momento. +
Sin pérdida de generalidad buscamos a B en el tab de búsqueda de una wallet y cuando lo encontramos
lo seleccionamos para agendarlo. El netwoek service intra user enviará una solicitud a B para que nos
acepte como conexión (asumiendo que no lo teníamos agregado como conexión) y el network service Crypto
Addresses solicitará direcciones de envío y enviará direcciones de recepción de dinero. Hasta que B
no nos acepte como contacto no podemos enviarle dinero ni recibir dinero de él. +
Cuando B nos acepta como contactos entonces el network service Intra User de B nos comunica la aceptación
para que quede registrado y el network service Crypto Addresses nos enviará una dirección para envío
de dinero. +

Para una descripción detallada ver el archivo "Agregado de Usuarios | Wallet Contacts | Actor Intra
User | Intra User Network Service". +

== Requerimientos de pago

Permitiremos que entre usuarios se pueda enviar y recibir requerimientos de pago. Un requerimiento de
pago a grandes rasgos es una solicitud que hace un usuario a otro en la que figura un monto a pagar,
un usuario al que pagar dicho monto y un mensaje descriptivo. +
Pensemos en un usuario A enviando un requerimiento de pago a B. +
En primer lugar, ambos usuarios deben haber intercambiado su información (deben ser contactos uno del
otro). +
El usuario A completa un formulario con un monto a pagar, coloca una descripción y selecciona al contacto
B (el destinatario). Al realizar el envío este se almacena en un registro y se envía a través del network
service money request a B. +
Cuando el network service de B recibe el requerimiento lo comunica a través de un evento al módulo de
requerimientos de pago de la capa Request para que vaya a buscar el requerimiento. Cuando este fue
adquirido por el módulo de la capa de request el network service conforma la recepción a su par en el
dispositio de A. +
Posteriormente B debe aceptar o rechazar el requerimiento; en ambos casos el network service de B
informa al de A la decisión. Además, en el caso de aceptar la solucitud se generará inmediatamente
la transacción que envía ese dinero. Claramente la interfaz no debe permitir que se acepte la solicitud. +


== Intra Users y vistas de una wallet

Pensemos cómo podemos organizar la información que mostramos en diferentes tabs de la wallet al
incorporar el concepto de Intra User. Para ello supongamos que tenemos dos identidades de Intra User,
A y B. +

=== Balances

Los balances de la wallet deben basarse en las transacciones de ambas identidades dado que corresponden
al mismo Device User y por ende los fondos son del mismo usuario. Podemos dar la opción al usuario de
ver también los balances en función a las identidades. +

=== Transacciones

Al igual que con los balances, las transacciones de las diferentes identidades pertenecen realmente
al mismo usuario por lo que mostraremos todas las transacciones combinadas (cosa que de hecho ya hacemos). +
Nuevamente permitiremos que el usuario haga filtros de las transacciones según su identidad. +

=== Contactos

Al agregar un contacto uno se encuentra logueado con una identidad de intra user, la cual es entregada
al otro intra user con el que se está intercambiando información de contacto. Debemos mostrarle al
usuario ver la lista de contactos que ha registrado con la identidad con la cual está logueado.

=== Requerimientos de pago

Deberá agregarse un tab para los requerimientos. Dentro de este tab querríamos poder visualizar tanto
los que emitimos nosotros como los que se nos solicitan. En cuanto a la división de esta información
según el intra user logueado dejaremos que cada wallet decida la mejor manera de mostrar estos datos
y brindaremos la interfaz más general posible. +


== Información de un Intra User

* Nombre: nombre que uno asigna para la identidad que se crea. Este será el nombre que se mostrará a
los demás usuarios de la plataforma.
* Clave pública.
* Clave privada.
* Device User asociado

== Transacciones

En este milestone continuamos con "simple" envío y recepión de crypto currencies, no agregamos
funcionalidades como enviar fiat sobre crypto. Lo que cambia al realizar transacciones entre Intra
Users es que además de tener la red crypto como bitcoin para enviar crypto currency también tendremos
la red de comunicacionesd e Fermat para transmitir otros datos. +
En este caso los datos incluirán simples descripciones de la transacción como por ejemplo un texto
que explica lo que la transacción está pagando. +
Por ende un envío de crypto a otro intra user generará una transacción a nivel de la red crypto y
otra a nivel de metadata que se transmitirá a través de la red de comunicaciones del sistema. El
plugin transaccional Outgoing Extra User deberá garantizar que ambas transmisiones se realicen (la
que va por la red crypto y la que va por la red Fermat). A sy vez el Incoming Intra User deberá
modificar los balances en función también a ambos canales de información, lo cual implica sincronizar
los daos que llegan y reaccionar adecuadamente a reversiones. +

En las descripciones de los plugins Money Request, Incoming Intra User, Incoming Crypto y Outgoing
Intra User describiremos con mayor detalle estos ciclos de envío y recepción de crypto currency. +k

== Plugins Involucrados

La lista de plugins que se van a implementar / modificar en este Milestone es la siguiente:


Reference Wallet / Bitcoin --> Existe y hay que modificarlo
Crypto Router --> Existe y hay que modificarlo

Middleware / Contacts --> Existe y hay que modificarlo


Transaction / Outgoing Intra User --> Existe y hay que modificarlo
Transaction / Incoming Intra User --> Existe y hay que modificarlo

Request / Money Request --> Crear
fermat-dmp-plugin-request-money-request-bitdubai

Module / Intra User --> Crear
fermat-dmp-plugin-module-intra-user-bitdubai
<commit_msg>Update asccidoc<commit_after>Milestone 3 - Interconexión de wallets
======================================
<NAME> <<EMAIL>>

En este milestone comenzaremos a trabajar sobre cómo los usuarios usarán el sistema. +
En el milestone 1 construímos una wallet que permite que un usuario reciba dinero (bitcoins) de una
persona que utiliza una billetera externa (como coinbase, blockchain.info, etc) y pueda reconocer de
quién provino el dinero. +
También permitimos poder enviar bitcoins a este tipo de wallet desde nuestra billetera. En ambos casos
registramos a esta persona que usa billeteras externas a la plataforma con una identidad que llamamos
extra user. +

Una identidad es simplemente una forma de identificar a una persona, en ocasiones tenemos categorías
para clasificar cierto tipo de identidades. En el caso que mencionamos arriba, la identidad extra user
se la asigna a personas que envían/reciben dinero usando billeteras externas a las que están en nuestra
plataforma. +
Observamos que en el milestone 2 también creamos identidades como: developer, designer y translator
entre otras. Allí vimos que una misma persona puede tener varias identidades según el contexto o forma
en que usa las subaplicaciones del sistema. +

También recordemos que remarcamos en el milestone 2 el concepto de device user. Esta identidad es quizás
la más importante dentro de un dispositivo, ya que no sólo identifica a un usuario dentro del hardware
que corre la plataforma sino que también permite relacionar las distintas identidades de ese usuario. +
En más detalle, cuando uno abre la aplicación se loguea como device user y las identidades que uno crea
al usar la aplicación (como por ejemplo crear una identidad de developer) se asocian al Device User
actualmente logueado. +
Si se hace un logout y se ingresa en el mismo dispositivo con otro device user entonces los creados por
el device user anterior no serán mostrados y cuando el usuario se vuelva a loguear con el Device User
original volverán a poder manejarse la identidad de developer antes creada. +

En este milestone entra en juego una nueva identidad que hasta ahora hemos mantenido implícita, la de
Intra User. Todos los usuarios (Device Users) tienen al menos una identidad de Intra User asociada.
Esta identidad representa a los usuarios dentro de la plataforma (trascendiendo al dispositivo). +

Entre Intra Users se podrán enviar y recibir dinero usando las wallets del sistema, la diferencia con
las transacciones que se realizan con algún extra user es que al ser usuarios del sistema tendremos
mucha más información y recursos disponibles. Por ejemplo, podemos buscar a los usuarios dentro del
sistema; realizar pagos sin que el usuario final deba escribir o siquiera conocer direcciones bitcoin;
podremos hacer requerimientoss de pagos; notificaciones de pagos, etc. +

Veamos con más profundidad estas nuevas funciones y las modificaciones que requeriremos realizar.

== Administración de Intra Users

Una identidad se puede crear en cualquier sub app que maneje dicha identidad. En el caso del Intra
User tendremos la sup app Intra User que permitirá crear y loguarse con estas identidades. Las identidades
registradas se pueden usar en todas las wallets que tiene asociadas el Device User logueado. +
Tener varias identidades de intra user dentro de una wallet le permite a un usuario emitir pagos con
cierto anonimato ya uno puede realizar cierto tipo de pagos desde una identidad especial.

=== Agregar Intra Users a nuestras conexiones - Intercambiar información

Cuando agregamos a un usuario como contacto en alguna de nuestras wallets decimos que lo agregamos
como contacto. Al agregarlo desde una sub app especial que llamaremos Sub App Intra User decimos que
lo agregamos a nuestras conexiones. +
Todo contacto debe ser parte de nuestras conexiones pero no necesariamente toda conexión debe ser un
contacto nuestro en alguna wallet, +
Supongamos que nos encontramos logueados con la identidad de Intra User A y deseamos agregar al Intra
User B como contacto. +
A través de diversas sub apps podemos buscar nuevos Intra Users, en este milestone podrá hacerse a
través de un tab de búsqueda de contactos dentro de cada wallet para agregarlo como sólo a la wallet
o desde la misma sub app intra user para agregarlo a como conexión del intra user logueado en ese
momento. +
Sin pérdida de generalidad buscamos a B en el tab de búsqueda de una wallet y cuando lo encontramos
lo seleccionamos para agendarlo. El netwoek service intra user enviará una solicitud a B para que nos
acepte como conexión (asumiendo que no lo teníamos agregado como conexión) y el network service Crypto
Addresses solicitará direcciones de envío y enviará direcciones de recepción de dinero. Hasta que B
no nos acepte como contacto no podemos enviarle dinero ni recibir dinero de él. +
Cuando B nos acepta como contactos entonces el network service Intra User de B nos comunica la aceptación
para que quede registrado y el network service Crypto Addresses nos enviará una dirección para envío
de dinero. +

Para una descripción detallada ver el archivo "Agregado de Usuarios | Wallet Contacts | Actor Intra
User | Intra User Network Service". +

== Requerimientos de pago

Permitiremos que entre usuarios se pueda enviar y recibir requerimientos de pago. Un requerimiento de
pago a grandes rasgos es una solicitud que hace un usuario a otro en la que figura un monto a pagar,
un usuario al que pagar dicho monto y un mensaje descriptivo. +
Pensemos en un usuario A enviando un requerimiento de pago a B. +
En primer lugar, ambos usuarios deben haber intercambiado su información (deben ser contactos uno del
otro). +
El usuario A completa un formulario con un monto a pagar, coloca una descripción y selecciona al contacto
B (el destinatario). Al realizar el envío este se almacena en un registro y se envía a través del network
service money request a B. +
Cuando el network service de B recibe el requerimiento lo comunica a través de un evento al módulo de
requerimientos de pago de la capa Request para que vaya a buscar el requerimiento. Cuando este fue
adquirido por el módulo de la capa de request el network service conforma la recepción a su par en el
dispositio de A. +
Posteriormente B debe aceptar o rechazar el requerimiento; en ambos casos el network service de B
informa al de A la decisión. Además, en el caso de aceptar la solucitud se generará inmediatamente
la transacción que envía ese dinero. Claramente la interfaz no debe permitir que se acepte la solicitud. +


== Intra Users y vistas de una wallet

Pensemos cómo podemos organizar la información que mostramos en diferentes tabs de la wallet al
incorporar el concepto de Intra User. Para ello supongamos que tenemos dos identidades de Intra User,
A y B. +

=== Balances

Los balances de la wallet deben basarse en las transacciones de ambas identidades dado que corresponden
al mismo Device User y por ende los fondos son del mismo usuario. Podemos dar la opción al usuario de
ver también los balances en función a las identidades. +

=== Transacciones

Al igual que con los balances, las transacciones de las diferentes identidades pertenecen realmente
al mismo usuario por lo que mostraremos todas las transacciones combinadas (cosa que de hecho ya hacemos). +
Nuevamente permitiremos que el usuario haga filtros de las transacciones según su identidad. +

=== Contactos

Al agregar un contacto uno se encuentra logueado con una identidad de intra user, la cual es entregada
al otro intra user con el que se está intercambiando información de contacto. Debemos mostrarle al
usuario ver la lista de contactos que ha registrado con la identidad con la cual está logueado.

=== Requerimientos de pago

Deberá agregarse un tab para los requerimientos. Dentro de este tab querríamos poder visualizar tanto
los que emitimos nosotros como los que se nos solicitan. En cuanto a la división de esta información
según el intra user logueado dejaremos que cada wallet decida la mejor manera de mostrar estos datos
y brindaremos la interfaz más general posible. +


== Información de un Intra User

* Nombre: nombre que uno asigna para la identidad que se crea. Este será el nombre que se mostrará a
los demás usuarios de la plataforma.
* Clave pública.
* Clave privada.
* Device User asociado

== Transacciones

En este milestone continuamos con un "simple" envío y recepión de crypto currencies, no agregamos
funcionalidades como enviar fiat sobre crypto.
Lo que cambia al realizar transacciones entre Intra Users es que además de tener la red crypto como bitcoin
para enviar crypto currency, también tendremos la red de comunicaciones de Fermat para transmitir datos. +
En este caso los datos incluirán simples descripciones de la transacción como por ejemplo un texto
que explica lo que la transacción está pagando. +
Por ende un envío de crypto a otro intra user generará una transacción a nivel de la red crypto y
otra a nivel de metadata que se transmitirá a través de la red de comunicaciones del sistema. El
plugin transaccional Outgoing Intra User deberá garantizar que ambas transmisiones se realicen (la
que va por la red crypto y la que va por la red Fermat). A sy vez el Incoming Intra User deberá
modificar los balances en función también a ambos canales de información, lo cual implica sincronizar
los datos que llegan y reaccionar adecuadamente a reversiones. +

En las descripciones de los plugins Money Request, Incoming Intra User, Incoming Crypto y Outgoing
Intra User describiremos con mayor detalle estos ciclos de envío y recepción de crypto currency. +

== Plugins Involucrados

La lista de plugins que se van a implementar / modificar en este Milestone es la siguiente:


Reference Wallet / Bitcoin --> Existe y hay que modificarlo
Crypto Router --> Existe y hay que modificarlo

Middleware / Contacts --> Existe y hay que modificarlo


Transaction / Outgoing Intra User --> Existe y hay que modificarlo
Transaction / Incoming Intra User --> Existe y hay que modificarlo

Request / Money Request --> Crear
fermat-dmp-plugin-request-money-request-bitdubai

Module / Intra User --> Crear
fermat-dmp-plugin-module-intra-user-bitdubai

{'fraction_non_alphanumeric': 0.02727808905927455, 'fraction_numerical': 0.0003931976801336872, 'mean_word_length': 4.630049806308799, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 23, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7486735', 'n_tokens_mistral': 5995, 'n_tokens_neox': 5907, 'n_words': 3198}