anchor.diff:  
   == Infraestructura para los procedimientos
   
  -Antes de recorrer todo el proceso que adoptaremos para añadir como desarrolladores nuevas Niche Wallets, presentaremos brevemente los diversos componentes que agregaremos para cumplir con este milestone. Tras la presentación continuaremos con un desarrollo más detallado de los procedimientos. + 
  -
  -Developer PIP sub APP:: Esta sub app le permite a los desarrolladores registrarse como tales en el sistema. Además le provee herramientas para testear sus wallets y otros plugins de la plataforma.
  +Antes de recorrer todo el proceso que adoptaremos para añadir como desarrolladores nuevas Niche
  +Wallets, presentaremos brevemente los diversos componentes que agregaremos para cumplir con este
  +milestone. Tras la presentación continuaremos con un desarrollo más detallado de los procedimientos. +
  +
  +Developer PIP sub APP:: Esta sub app le permite a los desarrolladores registrarse como tales en el sistema.
  +Además le provee herramientas para testear sus wallets y otros plugins de la plataforma.
   Wallet Runtime:: Este plugin se encarga de almacenar y administrar la estructura de navegación de las wallets.
  -Wallet Resources:: Este plugin es un network service del tipo DAPP (Distributed Application), administra los recursos de las wallets y se encarga de conseguir los recursos que le pidan si es que no los tiene.
  -Wallet Factory SUB APP:: Cuando un developer cree una nueva wallet, esta sub app permitirá realizar la edición de la estructura de navegación y la edición de recursos de la wallet. Sin embargo no interactuará con el Wallet Runtime ni el Wallet Resources. Esta sub app creará proyectos que llamaremos Wallet Factory Projects.
  -Wallet Publisher:: El Wallet Publisher permite crear un proyecto asociado a una Niche Wallet y entre otras cosas maneja el hecho de que puedan haber diferentes versiones de la misma. Una vez finalizada cada nueva versión de la Niche Wallet, exportamos el proyecto de Wallet Factory para que pueda ser abierto por el Wallet Publisher como una versión determinada de la Niche Wallet. + 
  -El Wallet Publisher permite también administrar que versiones se van subiendo a la Wallet Store y monitorear la cantidad de instalaciones de cada versión de la wallet en el sistema Fermat. Para subir una nueva version de la Reference Niche Wallet a la Wallet Store, se comunica con el Network Service DMP Wallet Store, que en el fondo es un nodo de la DAPP Wallet Store.
  -Wallet Store:: La Wallet Store es dentro del sistema fermat una DAPP (Distributed Application). Es decir que es una aplicación formada por un número indeterminado de nodos que colaboran entre si para manejar la funcionalidad de la DAPP a nivel del sistema completo. Su función es aceptar la publicación de la nueva (o nueva versión) de una Niche Wallet y comunica al DMP Network Service Wallet Store, para que se expanda por la región donde este tipo de wallet tiene sentido existir.
  -Wallet Manager:: La instalación la produce el Wallet Manager en el dispositivo de del usuario final, el cual es responsible de unir todas las partes para que la nueva Reference Niche Wallet | Niche Wallet esté disponible para ser usada.
  +Wallet Resources:: Este plugin es un network service del tipo DAPP (Distributed Application), administra
  +los recursos de las wallets y se encarga de conseguir los recursos que le pidan si es que no los tiene.
  +Wallet Factory SUB APP:: Cuando un developer cree una nueva wallet, esta sub app permitirá realizar
  +la edición de la estructura de navegación y la edición de recursos de la wallet. Sin embargo no
  +interactuará con el Wallet Runtime ni el Wallet Resources. Esta sub app creará proyectos que llamaremos
  +Wallet Factory Projects.
  +Wallet Publisher:: El Wallet Publisher permite tomar un WFP asociado a una Niche Wallet en desarrollo
  +y enviarlo a la Wallet Store para que otros usuarios puedan descargar la wallet. Además maneja el hecho
  +de que puedan haber diferentes versiones (actualizaciones) de la misma wallet. Cuando desarrollamos
  +una nueva versión de la Niche Wallet, exportamos el proyecto de Wallet Factory para que pueda ser
  +abierto por el Wallet Publisher como una versión nueva de la Niche Wallet. +
  +Desde el Wallet Publisher publicamos la wallet importada en el Wallet Store. Adenpas permite
  +monitorear la cantidad de instalaciones de cada versión de la wallet en el sistema Fermat. Para subir
  +una nueva version de la Reference Niche Wallet a la Wallet Store, se comunica con el Network Service
  +DMP Wallet Store, que en el fondo es un nodo de la DAPP Wallet Store.
  +Wallet Store:: La Wallet Store es dentro del sistema fermat una DAPP (Distributed Application). Es
  +decir que es una aplicación formada por un número indeterminado de nodos que colaboran entre si para
  +manejar la funcionalidad de la DAPP a nivel del sistema completo. Su función es mostrar un catálogo
  +de wallets que el usuario puede instalar, mostrar información de estas wallets y permitir iniciar la
  +instalación de las mismas.
  +Wallet Manager:: La instalación de la wallet la produce concretamente el Wallet Manager en el dispositivo
  +de del usuario final. Esta app es responsible de unir todas las partes para que la nueva Reference
  +Niche Wallet | Niche Wallet esté disponible para ser usada. También permite otras tareas administrativas
  +sobre las wallets intaladas (por ejemplo, abrir, calificar, desisnstalar, etc.)
   
   == Primeros refinamientos
   
   Analicemos los pasos para incorporar una wallet y extendamos las definiciones anteriores.
   
  -Lo primero que debemos realizar es registrarnos como desarrolladores en el sub app Developers. +
  -Usaremos la plataforma misma para comunicarnos con el Desarrollador, evitando el uso de correosm SNSm etc.
  -
  -Supongamos que queremos crear una wallet a partir de la Bitcoin Reference Wallet. Procedemos entonces a hacer un fork del repositorio de fermat de bitDubai y lo clonamos en nuestra computadora. +
  -Una vez clonado creamos un nuevo paquete en fermat/DMP/android/niche_wallet y otro en fermat/DMP/plugin/niche_wallet_type con nombres adecuados como por ejemplo: /home/eze/Escritorio/fermat/DMP/android/niche_wallet/fermat-dmp-android-niche-wallet-bitcoin-wallet-myDeveloperName y /home/eze/Escritorio/fermat/DMP/plugin/niche_wallet_type/fermat-dmp-plugin-niche-wallet-type-crypto-wallet-myDeveloperName. +
  -En el folder de android se coloca el código dependiente de android (de haber otras plataformas disponibles se agregan directorios en las locaciones análogas), mientras que en el plugin se coloca la lógica de la wallet, la cual es un proyecto java. Cuando querramos exportar nuestra wallet a otra plataforma sólo deberemos reescribir el módulo dependiente del sistema operativo, mientras que la lógica que se escribió en java (lo que está en DMP/plugin) no requerirá reescribirse. +
  -
  -NOTE: En DMP/plugin hay que crear la capa reference_niche_wallet_type y separar la Reference Bitcoin Wallet allí o crear una para las niche_Wallet_type que no son reference.
  +Lo primero que debemos realizar es registrarnos como desarrolladores en el sub app Developer. +
  +Usaremos la plataforma misma para comunicarnos con el Desarrollador, evitando el uso de correos, SMS. etc.
  +
  +Supongamos que queremos crear una wallet a partir de la Bitcoin Reference Wallet. Procedemos entonces
  +a hacer un fork del repositorio de fermat de bitDubai y lo clonamos en nuestra computadora. +
  +Una vez clonado creamos un nuevo paquete en fermat/DMP/android/niche_wallet y otro en
  +fermat/DMP/plugin/niche_wallet_type con nombres adecuados como por ejemplo:
  +`/home/eze/Escritorio/fermat/DMP/android/niche_wallet/fermat-dmp-android-niche-wallet-bitcoin-wallet-myDeveloperName` y
  +`/home/eze/Escritorio/fermat/DMP/plugin/niche_wallet_type/fermat-dmp-plugin-niche-wallet-type-crypto-wallet-myDeveloperName`. +
  +En el folder de android se coloca el código dependiente de android (de haber otras plataformas disponibles
  +se agregan directorios en las locaciones análogas), mientras que en el plugin se coloca la lógica de
  +la wallet, la cual es un proyecto java. Cuando querramos exportar nuestra wallet a otra plataforma sólo
  +deberemos reescribir el módulo dependiente del sistema operativo, mientras que la lógica que se escribió
  +en java (lo que está en DMP/plugin) no requerirá reescribirse. +
  +
  +NOTE: En DMP/plugin hay que crear la capa reference_niche_wallet_type y separar la Reference Bitcoin
  +Wallet allí o crear una para las niche_Wallet_type que no son reference.
   
   En estos paquetes copiamos el código necesario de los proyectos de las reference wallets. +
  -A continuación debemos definir la estructura de navegación y recursos que tendrá la wallet que construiremos para poder conectarla y correrla en la plataforma. 
  +A continuación debemos definir la estructura de navegación y recursos que tendrá la wallet que
  +construiremos para poder conectarla y correrla en la plataforma.
   
   Procedemos entonces a abrir el Wallet Factory. +
   
   === Wallet Factory
   
  -Como mencionamos antes, el wallet factory permite editar la estructura de navegación de una wallet y sus recursos. Esta información, junto con la relación que enlaza la estructura de navegación con los fragmentos programados de front-end se persiste en disco en un formato que llamaremos Wallet Factory Project o WFP. +
  -La Wallet Factory también deberá proveer la manera de permitir al desarrollador ejecutar concretamente lo que está editando (esta funcionalidad será similar a lo que hace el wallet runtime más la funcionalidad de proveer los recursos multimedia (entro otros) a la wallet). Para realizar estas labores requeriremos que entre otras cosas se pueda:
  +Como mencionamos antes, el wallet factory permite editar la estructura de navegación de una wallet y
  +sus recursos. Esta información, junto con la relación que enlaza la estructura de navegación con los
  +fragmentos programados de front-end se persiste en disco en un formato que llamaremos Wallet Factory
  +Project o WFP. +
  +La Wallet Factory también deberá proveer la manera de permitir al desarrollador ejecutar concretamente
  +lo que está editando (esta funcionalidad será similar a lo que hace el wallet runtime más la
  +funcionalidad de proveer los recursos multimedia a la wallet). Para realizar estas labores requeriremos
  +que entre otras cosas se pueda:
   
   * Crear un WFP vacío
   * Importar el WFP de una wallet existente.
   * Persistir el proyecto en disco.
  -* Correr un proyecto. Para lo cual el back-end asociado deberá estar integrado en la plataforma en que se edita el proyecto.
  -* La edición debe ser en modo gráfico, por lo que al agregar/eliminar/modificar un componente de la estructura de navegación debemos hacer que eso se refleje en una representación interna que luego podamos persistir.
  +* Correr un proyecto. Para lo cual el back-end (y fragmentos) asociado deberá estar integrado en la
  +plataforma en que se edita el proyecto.
  +* La edición debe ser en modo gráfico, por lo que al agregar/eliminar/modificar un componente de la
  +estructura de navegación debemos hacer que eso se refleje en una representación interna que luego
  +podamos persistir.
   
   REMARK: No podemos incorporar el código nuevo sin lanzar una nueva versión del sistema (en android al menos). 
   
  -NOTE: Actualmente hay que hacer diversas modificaciones manuales para poder lograr integrar una nueva wallet y luego recompilar el proyecto. Hay que resolver cómo hacer estas configuraciones dinámicamente y automáticas a partir del wallet factory project.
  +NOTE: Actualmente hay que hacer diversas modificaciones manuales para poder lograr integrar una nueva
  +wallet y luego recompilar el proyecto. Hay que resolver cómo hacer estas configuraciones dinámicamente
  +y automáticas a partir del wallet factory project o al menos reducir la cantidad de modificaciones en
  +diversos módulos del back-end que requiere incorporar una wallet. Por ejemplo, modificaciones de los
  +módulos transaccionales que accionan sobre las wallets.
   
   Con este proyecto, los recursos y el código podemos integrar la wallet para correrla. +
   
  -Al terminar esta configuración estamos en condiciones de hacer correr la wallet desde el wallet factory para poder testear lo programado.
  +Al terminar esta configuración estamos en condiciones de hacer correr la wallet desde el wallet factory
  +para poder testear lo programado.
   
   === Wallet Publisher
   
  -Al culminar nuestra edición obtemdremos como producto de la Wallet Factory un WFP. Hasta este momento la wallet que hemos creado sólo existe en nuestro dispositivo. Si deseamos ofrecer a otros usuarios la posibilidad de usar nuestra wallet debemos publicarla para que puedan descargarla en componente que llamamos Wallet Store.
  -
  -Para que la wallet funcione requerimos por un lado tener el código que ejecuta la wallet (el back-end), por otro lado requerimos el wallet factory project de la wallet. Por tanto debemos buscar la forma de ofrecer estos recursos. Un problema a considerar es que queremos controlar el código que se sube a la plataforma y evitar que se use nuestro sistema para que se distribuya software mal intencionado. +
  -La back-end de la wallet será sometido a un pull request en el repositorio central de bitDubai y su wallet factory project se enviará por separado. Sólo se podrá descargar el back-end de una wallet al descargar una nueva versión de la plataforma. Los recursos no se descargan con la plataforma, estos se consiguen (en principio) a través de network services (el network service Wallet Resources es quien tendrá el WFP de la wallet y el network service Wallet Store es quién agrega al catálogo la wallet).
  -No podemos evitar que un nodo integre al catálogo y wallet resources wallet factory projects dado que el desarrollador tiene una versión completa del sistema corriendo en su dispositivo, la cual puede alterar a deseo. Por ende debemos proveer al nodo de la plataforma que quiera descargar una wallet un mecanismo que permita verificar que los recursos que descargan son correctos. +
  -Optaremos por colocar un hash del wallet factory project en el mismo plug-in root de la wallet que creamos, este hash entre otros datos (como la identidad del developer, el precio de la licencia, dirección de pago, etc) estará hardcodeado en el código de la clase root y se accederá a esta información a través de una interfaz que debemos definir. De esta manera si como desarrolladores intentamos publicar recursos falsos que intenten subplantar los de una wallet existente, el nodo que descargue dichos recursos contrastará el hash de lo que descarga contra el hash que tiene registrado y si no coincide el network service descarta lo que descargó y lo busca de otro(s) nodo(s). +
  -En el caso de nuestra nueva wallet, para que alguien pueda descargarla esta debe haber sido aprobada previemente por bitDubai, por lo que el hash también fue comprobado. Así, tras estar habilitada para descargarse nuestra wallet nosotros tampoco podremos alterar los recursos que enviamos. +
  -Por otro lado, si mandamos recursos de cosas que aún no han sido integradas en la plataforma, no va a existir manera de que otros nodos lo busquen instalar de por sí, porque el wallet store sólo debería ofrecer descargar wallets que están registradas en la versión de la plataforma que se está corriendo. +
  +Al culminar nuestra edición obtemdremos como producto de la Wallet Factory un WFP. +
  +Hasta este momento la wallet que hemos creado sólo existe en nuestro dispositivo. Si deseamos ofrecer
  +a otros usuarios la posibilidad de usar nuestra wallet debemos publicarla para que puedan descargarla
  +en componente que llamamos Wallet Store.
  +
  +Para que la wallet funcione requerimos por un lado tener el código que ejecuta la wallet (el back-end),
  +por otro lado requerimos el wallet factory project de la wallet. Por tanto debemos buscar la forma de
  +ofrecer estos recursos. +
  +Un problema a considerar es que queremos controlar el código que se sube a la plataforma y evitar
  +que se use nuestro sistema para que se distribuya software mal intencionado. +
  +El back-end de la wallet será sometido a un pull request en el repositorio central de bitDubai y su
  +wallet factory project se enviará por separado. Sólo se podrá descargar el back-end de una wallet al
  +descargar una nueva versión de la plataforma. Los recursos no se descargan con la plataforma, estos
  +se consiguen (en principio) a través de network services (el network service Wallet Resources es
  +quien tendrá la estructura de navegacion y los recursos de la wallet y el network service Wallet
  +Store es quién agrega al catálogo la wallet). +
  +No podemos evitar que un nodo integre al catálogo y wallet resources el contenido de los wallet factory
  +projects dado que el desarrollador tiene una versión completa del sistema corriendo en su dispositivo,
  +la cual puede alterar a deseo. Por ende debemos proveer al nodo de la plataforma que quiera descargar
  +una wallet un mecanismo que permita verificar que los recursos que descargan son correctos. +
  +Optaremos por colocar un hash del wallet factory project en el mismo plug-in root de la wallet que
  +creamos, este hash entre otros datos (como la identidad del developer, el precio de la licencia,
  +dirección de pago, etc) estará hardcodeado en el código de la clase root y se accederá a esta
  +información a través de una interfaz que debemos definir. De esta manera si como desarrolladores
  +intentamos publicar recursos falsos que intenten subplantar los de una wallet existente, el nodo que
  +descargue dichos recursos contrastará el hash de lo que descarga contra el hash que tiene registrado
  +y si no coincide el network service descarta lo que descargó y lo busca de otro(s) nodo(s). +
  +En el caso de nuestra nueva wallet, para que alguien pueda descargarla esta debe haber sido aprobada
  +previemente por bitDubai, por lo que el hash también fue comprobado. Así, tras estar habilitada para
  +descargarse nuestra wallet nosotros tampoco podremos alterar los recursos que enviamos. +
  +Por otro lado, si mandamos recursos de cosas que aún no han sido integradas en la plataforma, no va
  +a existir manera de que otros nodos lo busquen instalar de por sí, porque el wallet store sólo debería
  +ofrecer descargar wallets que están registradas en la versión de la plataforma que se está corriendo. +
   
   NOTE: Hay que refinar el manejo de lo que se muestra en el wallet store y la falsificación de información.
   
  
positive.code: 
  * Publicar la wallet en el wallet store. 
  * Administrar la publicación de diferentes versiones de una wallet (actualizaciones/upgrades). 
  * Informar algunos datos relacionados a las descargas de la wallet, por ejemplo el número de usuarios que la han instalado. +
  
  Publicar en el Wallet Store significa que debemos registrar en el Wallet Store DMP Network Service que el dispositivo tiene esta wallet en su parte del catálogo. A su vez, requerimos colocar el wallet factory project en un lugar para que el wallet store pueda obtener la información necesaria para la instalación. El componente encargado de almacenar los wallet factory projects a publicar es el Network Service Wallet Resources, el cuál administra los recursos de las wallets instaladas y publicadas. +
  
  NOTE: Podrían ponerse restricciones a lo que se puede publicar, pero como el desarrollador tendrá acceso a modificar todo el código que desee en su nodo no veo mucho sentido a estas acciones.
  
  
negative.code: :version: v1.0
  :date: 2015-06-30
  
  Este es un draft general del milestone 2. Los detalles están en proceso de refinamiento en archivos
  concretos correspondientes a cada módulo que se menciona aquí.
  
  == Introducción
  
  En el milestone 1 desarrollamos nuestra primer Reference Niche Wallet. Este tipo de wallet como su
  nombre lo indica busca ser una referencia para que los desarrolladores de wallets puedan incorporar
  sus ideas de manera más simple que construyendo una wallet desde cero. +
  La Reference Niche Wallet es completamente funcional, sin embargo su objetivo es ser minimalista para
  que su código y estructura puedan ser fácilmente reutilizados por los desarrolladores de Niche Wallets. +
  Funcionalmente una Reference Niche Wallet es idéntica a una Niche Wallet, pero conceptualmente se
  mantienen separadas en el sistema para poder distinguirlas fácilmente, en principio estas Reference
  Niche Wallets son desarrolladas por bitDubai.
  
  Lo que necesitamos incorporar en este milestone son los mecanismos para permitir que los
  desarrolladores de Niche Wallets creen e incorporen sus wallets al sistema. +
  
  Ante este problema surge la necesidad de definir qué es una wallet con precisión.
  
  == Wallet
  
  Una wallet es una aplicación que puede enviar y/o recibir dinero. Si bien esta wallet usa sólo bitcoins
  tomamos el concepto de dinero también para fiat currencies entre otras cosas. +
  Este tipo de aplicación involucra una gran cantidad de módulos. Podemos distingur en principio dos
  grandes grupos:
  
  * Los módulos vinculados a lo que el usuario ve y usa para interactuar (front-end)
  * Los módulos vinculados a llevar concretamente a cabo las acciones a realizar (back-end) 
  
  Comencemos analizando los conceptos del front-end. +
  
  Estrcutura de navegación:: Es una estructura que que representa lo que la interfaz de la wallet muestra,
  sean menues, tabs, fragmentos, botones, etc. Contiene referencias a los recursos que utiliza.
  Recursos:: Son principalmente las imágenes u otros elementos multimedia que aparecen en la wallet.
  
  En el back-end tenemos componentes que se encargan de diversas funciones, entre otros:
  