El desarrollo de Bancos de Tiempo parece imparable. No está lejano el día en que su impacto económico sea importante.

Es posible que su presencia sea tolerada por un tiempo. Pero, tarde o temprano, el establishment que controla la creación del dinero en el sistema de Banca de Reserva Fraccional va a reaccionar.

Bancos de Tiempo Centralizados

En un banco de tiempo centralizado, un servidor central contiene una base de datos con las cuentas de cada socio. Además, mantiene un registro con todos los socios. En algunos casos, si usa distintas tarifas para distintos servicios, mantiene un listado de ocupaciones.

Para efectuar un pago, un socio se debe conectar a la base de datos, y allí hace una transferencia de su cuenta a la cuenta de otro socio. 

Todos los socios se tienen que conectar para realizar sus operaciones.

Esta es una arquitectura extremadamente vulnerable. Una simple acción legal puede cerrar el servidor central y destruir la red creada con tanto esfuerzo.

Bancos de Tiempo Descentralizados

Urge por tanto usar arquitecturas P2P descentralizadas antes de que la estructura centralizada crezca mucho.

Una arquitectura asíncrona basada en el envío de bonos (voucher) mediante email, es especialmente resistente a ataques, tanto del banco de Tiempo central como de parte de los socios. En esta arquitectura, cada socio tiene su cuenta (wallet) localmente. Para efectuar un pago, un socio deduce de su cuenta una cantidad (añade la cantidad al pasivo de su base de datos local) y emite un bono como un documento electrónico, y lo adjunta a un email.

Cuentas descentralizadas, pagos por email

El documento Requirements and Design for Voucher Trading System (VTS) http://tools.ietf.org/html/draft-ietf-trade-drt-requirements-03 explica una arquitectura genérica para sistemas de moneda complementaria  que sirve tanto para arquitecturas centralizadas como descentralizadas.

El diseño del bono ya se desarrolló en el año 2001 en el documento XML Voucher: Generic Voucher Languagehttp://tools.ietf.org/html/draft-ietf-trade-voucher-lang-02  y desarrollos posteriores, como el contrato Ricardianohttp://www.systemics.com/docs/ricardo/issuer/contract.html, no suponen mayores modificaciones.

Las funcionalidades genéricas que debe tener la interfaz de usuario se definen en el documento Voucher Trading System Application Programming Interface (VTS-API) http://tools.ietf.org/html/draft-ietf-trade-voucher-vtsapi-00.

El uso de estas soluciones normalizadas resuelve además un problema con que se van a encontrar muy pronto los Bancos de Tiempo, la interoperabilidad. Pronto nos encontraremos con personas que pertenecen a más de un Banco de Tiempo y deseen poder usar sus activos con los socios de un Banco de Tiempo y de otro.

Registros descentralizados

Es más, no es necesario que el Banco de Tiempo  tenga en exclusiva el registro de socios ni el listado de ocupaciones. Puede fácilmente distribuirlas por email. 

De ese modo mantiene un control sobre los socios, pero en caso de un ataque, cada uno de los socios está en condiciones de replicar de nuevo le organización de una réplica de la oficina central del banco de Tiempo.
En última instancia puede permitir que:

1. Cada socio maneje su propio registro, su propia agenda de socios con los que tiene relación de confianza para canjear horas.
2. Las tarifas por cada servicio sean indicativas, de forma que cada socio ponga a la venta sus horas de servicio a su precio, dejando que sea el mercado el que regule las tarifas.

Desarrollo de herramientas

Desde 2001 ha habido un gran desarrollo de XML, y en especial del lenguaje capaz de manejar formularios XML como es XFormshttp://www.w3.org/MarkUp/Forms/.

El desarrollo de soluciones descentralizadas para Bancos de Tiempo tiene todo lo que hay que tener para permitir un desarrollo nada costoso en tiempo y esfuerzo.

El software de usuario

voucher	Cada socio tiene un programa, que llamamos voucher asi como lo hace  XML Voucher: Generic Voucher Language, que permite emitir bonos normalizados como medio de pago, denominados en HORAS de Banco de Tiempo. El programa debe comprobar que los activos del socio sean mayores que cero o del umbral fijado por la política del banco de Tiempo. Una vez generado el bono, debe enviarlo como anexo a un email al socio que debe cobrar.
wallet	Es el libro de cuentas de cada socio, donde se apuntan los PASIVOS (o pagos que realiza por los servicios recibidos) y los ACTIVOS (o bonos que recibe por los servicios prestados). El programa debe poder registrar los bonos recibidos como datos adjuntos a un email y depositados en un directorio de su ordenador.
ficheros	Estos ficheros alimentan tanto a voucher como a wallet: myWallet.xml contiene el libro de cuentas con los activos y los pasivos occupations.xml mantiene un listado de ocupaciones o servicios y las tarifas por defecto. registry.xml mantiene la agenda de socios con las que hacer intercambio.

El software del banco de Tiempo

Es más sencillo aun. Un  programa para manejar la lista de socios (registry) y otro las tarifas (occupations).

En mi opinión, este software se podría distribuir a los socios.

Seguridad

La arquitectura es bastante resistente a ataques externos. Sigue la misma filosofía que la que inspiro los principios de la Internet, una arquitectura donde las redes de ordenadores USA deberían funcionar aunque cayera una bomba atómica en cualquier parte del territorio.

Sin otras medidas de seguridad, está totalmente expuesta a ataques desde dentro. Se están enviando por correo ficheros XML que cualquiera puede editar con Notepad. Es por tanto más vulnerable al fraude que una base de datos en una oficina del Banco de Tiempo cerrada con llave por el secretario. Aunque no mucho más.

El remedio no es totalmente sencillo, pero un cierto grado de seguridad es alcanzable.  El documento (Extensible Markup Language) XML-Signature Syntax and Processing http://www.w3.org/TR/xmldsig-core/ contiene los principios.

No obstante, hasta que se haya alcanzado un volumen de participantes alto, otras medidas de control suave de la confianza pueden funcionar. Se puede enviar una copia de cada transacción al Banco de Tiempo, que va vigilando que no hay saldos negativos altos; la detección y denuncia del fraude es muy fácil entre pocos socios;  la edición de los ficheros es de todas formas difícil para legos; se puede introducir una firma digital de andar por casa con un procesamiento sencillo).