Gmail Add-ons: How-to be on all desktops and mobiles with a simple app

Some weeks ago, Google opened the possibility of create Gmail add-ons for all developers. Let’s see what are the possibilities and how to create and distribute our own Gmail add-on.

This is not a very hard and abstract post, add-ons are something easy, so I hope my explanation to be simple too. It is based on an add-on created by myself that allows any user adding an email to Google Tasks (probably it is more useful than the add-on for MSN Messenger that I created years ago which read received messages with «real» voice). It is a functionality that has been always present on Gmail web client but that is not available on mobile clients.

In order to create a Gmail add-on you need to create a new Google Apps Script project. After that you can add as much scripts as you want to create an interface using Cards and the functionality to interact with other services, APIs and so.

For instance, in our example the functionality is very basic:



function getContextualAddOn(e) {
  var message = getMessage(e);
  var subject = message.getSubject();
  var permaLink = message.getThread().getPermalink();
  
  var card = CardService.newCardBuilder();
  card.setHeader(CardService.newCardHeader()
                 .setTitle('Save as task'));
  var section = CardService.newCardSection();
  
  var button = prepareSend(permaLink);
  section.addWidget(button);
  
  section.addWidget(prepareList());
  
  section.addWidget(prepareTitle(subject));
  
  section.addWidget(prepareDueDate());
  
  section.addWidget(button);
  
  section.addWidget(prepareSign());
  
  card.addSection(section);
  console.log("Open");
  return [card.build()];
}

function getMessage(e){
  var accessToken = e.messageMetadata.accessToken;
  GmailApp.setCurrentMessageAccessToken(accessToken);
  
  var messageId = e.messageMetadata.messageId;
  return GmailApp.getMessageById(messageId);
}

function prepareSend(permaLink){
   var action = CardService.newAction()
  .setFunctionName("saveTask")
  .setParameters({permaLink: permaLink});
  return CardService.newTextButton()
                    .setText("Save")
                    .setOnClickAction(action);
}

function saveTask(e){
  var res = e['formInput'];
  var task = Tasks.newTask();
  task.title = res["title"];
  task.notes = e['parameters'].permaLink;
  
  if(res["due-date"] && res["due-date"] != "")
    task.due = res["due-date"] + "T00:00:00Z"
  
  task = Tasks.Tasks.insert(task, res["list"]);
  console.log("Saved");
}

function prepareList() {
  var response = Tasks.Tasklists.list();
  var taskLists = response.items;
  var dropdown = CardService.newSelectionInput()
     .setType(CardService.SelectionInputType.DROPDOWN)
     .setTitle("List")
     .setFieldName("list");

  if (taskLists && taskLists.length > 0) {
    Logger.log('Task lists:');
    for (var i = 0; i < taskLists.length; i++) {
      var taskList = taskLists[i];
      Logger.log('%s (%s)', taskList.title, taskList.id);
      dropdown.addItem(taskList.title, taskList.id, i==0);
    }
  } else {
    Logger.log('No task lists found.');
  }
  return dropdown;
}

function prepareTitle(subject){
  return CardService.newTextInput()
                    .setFieldName("title")
                    .setTitle("Title")
                    .setValue(subject)
}

function prepareDueDate(){
  var d = new Date();
  var dd = new Date(d.setDate(d.getDate() + ( 7 - d.getDay()) % 7));
  return CardService.newTextInput()
                    .setFieldName("due-date")
                    .setTitle("Due date")
                    .setValue(dd.getYear() + "-" + (dd.getMonth() + 1) + "-" + dd.getDate())
                    .setHint("YYYY-MM-DD");
}

function prepareSign(){
  var button = CardService.newTextButton()
     .setText("@JaviLopezG")
     .setOpenLink(CardService.newOpenLink()
         .setUrl("https://javilopezg.com/")
         .setOpenAs(CardService.OpenAs.OVERLAY)
         .setOnClose(CardService.OnClose.RELOAD_ADD_ON));
  return CardService.newKeyValue()
     .setContent("Developed and maintained by")
  .setButton(button);
}

You also have to change script’s manifest. To do this you need to access to the menu «View>Show manifest file». Now you can modify it as you want, following our example you have to replace the content with following lines:

{
  "timeZone": "GMT",
  "dependencies": {
    "enabledAdvancedServices": [{
      "userSymbol": "Tasks",
      "serviceId": "tasks",
      "version": "v1"
    }]
  },
  "oauthScopes": ["https://www.googleapis.com/auth/gmail.addons.execute", "https://www.googleapis.com/auth/gmail.addons.current.message.readonly", "https://www.googleapis.com/auth/tasks"],
  "gmail": {
    "name": "Save as task",
    "logoUrl": "https://i0.wp.com/javilopezg.com/wp-content/uploads/2017/11/save-as-tag-ico-24.png",
    "contextualTriggers": [{
      "unconditional": {
      },
      "onTriggerFunction": "getContextualAddOn"
    }],
    "primaryColor": "#000000",
    "secondaryColor": "#888888",
    "version": "TRUSTED_TESTER_V2",
    "openLinkUrlPrefixes": [
      "https://javilopezg.com/"
    ]
  }
}

As soon as you save all changes you are ready to publish your add-on. Unfortunately the Gmail add-ons store is not publicly available yet. However, you can get the ID of your add-on and distribute it to your company co-workers in order to allow them install your add on in their gmail accounts. See images below:

Gmail Add-on ID
Gmail Add-on ID
Add-ons in Gmail settings
Add-ons in Gmail settings

I know that it’s frustrating not being able to publish an add-on to all gmail users around the world yet. Anyway, I already have two cool ideas to implement as soon as I was able to distribute it at least to my friends. Something to draw an ordered tree of a conversation thread and an add-on to respond an e-mail with a video in an easy way. And you? What ideas are coming to your head?

PoW vs PoS

Cuando hablamos del Cryptojacking y de la minería, pasamos de puntillas un concepto que afecta a como se valida cada uno de los bloques de un blockchain. Es la «prueba«, y aunque en la mayoría de blockchains se usa Proof of Work, son muchos los expertos que apuntan a la necesidad de pasar a blockchains que usen Proof of Stake. Veamos en que se diferencian y el porqué de la necesidad de este cambio.

military byzantine photo
Photo by Internet Archive Book Images

Aunque inicialmente pueda parecer algo super técnico, como habéis ido viendo en otros posts relacionados con el tema, los blockchains son sistemas realmente básicos, aunque se tiene que enfrentar a los problemas típicos de los sistemas distribuidos que ya vimos cuando tratamos los patrones cloud.

En concreto, estas pruebas son soluciones al problema de consenso que normalmente se ejemplifica con el problema de los generales bizantinos. En este problema se busca la coordinación de varios jefes militares que intentan atacar o retirarse de un modo conjunto. Su aplicación mediante estas «pruebas» a los blockchains, sirve para la toma de decisiones en un entorno distribuido como este.

La prueba de trabajo (Proof of Work), se basa en el cálculo de un hash que «cierre» el bloque. Por tanto, el sistema que encuentra el hash valido es el que tiene la última palabra en cuanto a las operaciones registradas en dicho bloque.

Pongamos que hay un blockchain en el que participan Alberto, Braulio, Carlos, Diego y Esteban. Cada uno le manda al siguiente en la lista una moneda, pero Carlos no se ha enterado de que Esteban le ha mandado una moneda a Alberto. A la hora de minar, todos se ponen a buscar un hash de un bloque que almacenará 5 operaciones, menos Carlos que sólo ha recibido información de 4. Si el primero en lograr su trabajo es Diego, el hash que encuentre será de las 5 operaciones y por tanto las 5 quedarán confirmadas. Por el contrario, si quien logra dicha labor es Carlos, sólo 4 operaciones quedarán confirmadas y el envío de Esteban a Alberto deberá volver a realizarse.

En este tipo de pruebas toma la decisión el primero que consigue realizar un trabajo más o menos complejo como es el cálculo de ese hash.

La prueba de participación (Proof of Stake), se basa en la participación de los distintos componentes en el sistema. Depende del blockchain se tienen unas normas u otras (aunque podéis entrar en detalle en como será Ethereum cuando pase a PoS), pero en general se presupone que los elementos más partícipes (porque tengan más dinero, hagan más operaciones, etc.) son los principales interesados en que todo funcione correctamente y se haga del modo más limpio. Por tanto, estos se convierten en validadores que pueden recibir el «honor» de dar por bueno un bloque ya sea de manera aleatoria, rotativa, por votación…

De nuevo pensemos en un blockchain, pero en este participan Alba, Barbara, Carla, Diana y Ester. Cada una tiene el doble de monedas que la anterior en este blockchain, que está «gobernado» por un PoS en el que determina el bloque quien más dinero tenga. Si en cada transacción cada una le envía a la anterior la mitad de sus monedas, el primer bloque lo decidirá Ester, pero el segundo lo decidirá Diana por ser la nueva mayor participante. Por tanto, primero Ester y después Diana serán quienes decidan que operaciones quedan confirmadas, asumiéndose que al ser las mayores poseedoras de esta criptomoneda, son también las principales interesadas en que funcione bien y sea un sistema de fiar.

Aunque los dos tipos de prueba tienen sus cosas buenas y malas, hay una en la que PoS gana de calle a PoW y que nadie podrá rebatir. Es el consumo de electricidad gastado para realizar estos trabajos. Con cada bloque de la cadena todos los mineros se ponen a buscar el hash que toque, pero sólo uno lo consigue, por lo que todo el tiempo de cálculo anterior ha sido completamente inútil para todos menos uno. Por ejemplo, si atendemos a los Bitcoins, el consumo energético de este blockchain es similar al de Nigeria, o la electricidad que se emplea para una sola transacción de Bitcoin serviría para proveer a una casa durante un mes.

Espero haberos explicado de un modo suficientemente claro estos conceptos y el porqué de este debate, como para que podáis entrar en él. ¿Hay algún concepto que creáis que es importante aclarar?

Bots vs Cyborgs

Hace un  par de años vivimos un boom de los bots, principalmente de bots conversacionales, pero se veía como la afirmación de que ya estábamos preparados para automatizar todo. En mi opinión estamos lejos de eso, pero aunque no estemos preparados para los bots, sí que deberíamos convertirnos todos en cyborgs.

Un bot (abreviatura de robot), es un sistema que se encarga de hacer cosas que antes sólo podían hacer los humanos.

Un cyborg (cíborg en castellano), es un sistema que mezcla a los bots y las personas.

cyborg photo

Ejemplos de que no estamos preparados para la automatización total hay muchos, aunque probablemente uno de los casos más llamativos, fue ese bot de Microsoft que se convirtió en un troll de Twitter.

Hay otros mucho más impactantes, como los accidentes provocados por los conductores de Tesla que se desentienden de los controles tras conectar el piloto automático. Tesla advierte repetidamente que no estamos preparados para esto, y que una compañía que se centra tanto en la automatización (de fábricas, cargadores, etc.) crea que aun no estamos preparados es muy significativo.

Esto no quiere decir que la automatización sea mala, es muy buena y aunque requiera una inversión, reduce tiempos a futuro. Sin embargo, la automatización a día de hoy aun requiere de supervision.

Por ejemplo, en un chat de asistencia técnica se pueden automatizar los pasos iniciales y sencillos como pedir al cliente sus datos para identificarlo y una descripción del problema, y luego ir proponiéndole al operador textos para ayudar al cliente, de tal modo que este no tenga que teclear y solo elegir el que más se ajusta al problema del cliente actual. Esto le puede permitir manejar 10 incidencias en el tiempo en el que antes hacía 1, pero manteniendo el control.

Mantener el control y no cedérselo a ciegas a un programa es muy importante. Puede que el programa acierte el 99% de las veces, pero el 1% restante puede resultar muy dañino, por lo que creo que a día de hoy no se puede confiar al 100%.

Esto es algo que se ha visto repetidas veces en redes sociales, en los que bots (o personas que actúan como tales) se encargan de responder a personas y meten garrafalmente la pata.

Por tanto, siempre que se vaya a ahorrar tiempo de un modo sustancial mi recomendación suele ser automatizar, pero automatizar para tener cyborgs y no bots.

Cryptojacking: la minería de cryptomonedas como modelo de negocio

Estoy seguro de que muchos habéis pensado en usar el cryptojacking como modelo de negocio –las ideas suelen surgir simultáneamente en muchas cabezas a la vez- cuando hayáis visto noticias sobre cryptojacking, como el sonado caso de la CBS que durante un fin de semana tuvo incluido en su reproductor un script para minar cryptomonedas. ¿Pero es realmente factible? Entendámoslo y observemos sus implicaciones.

web coin photo
Photo by SMU Central University Libraries

El cryptojacking es un concepto más o menos novedoso, que se refiere a realizar minería de cryptomonedas usando para el computo los navegadores de visitantes a una web. Normalmente se supone poco ético, pero vayamos por partes que hay muchos conceptos:

  • Recordaréis cuando hablamos de blockchain, a las personas que se dedican a calcular los hash de los bloques se les llama mineros, porque el algoritmo les otorga una pequeña cantidad de cryptomoneda a quienes encuentran cada hash.
  • Para realizar esa minería, para buscar esos hash hay que realizar muchos cálculos invirtiendo en tiempo de procesador. Hay empresas que se dedican a la minería y que tienen montones de ordenadores (granjas) dedicados a realizar estos cálculos.
  • Una web, es una aplicación distribuida en la que parte del programa se ejecuta en el servidor, y otra parte se ejecuta en el navegador de los usuarios.
  • Cuando se usa la capacidad de computación de los visitantes a una web, para realizar minería, es cuando estamos hablando de cryptojacking.

En casi todos los casos en los que se habla de cryptojacking se trata (o al menos se supone) de webs que han sido crackeadas, en las que se ha incluido el código necesario para realizar la minería, pero ¿y si no siempre fuese así? ¿Y si una web de manera legítima implementara este sistema de minería para financiarse? ¿Qué podría pasar?

Esta técnica hace que se consuman recursos de los equipos de los visitantes, pero por norma general, la mayoría de los visitantes tienen recursos más que sobrados en sus sistemas que están muy infrautilizados. Al final es como los sistemas para compartir potencia para cálculos distribuidos, ya sea para encontrar una cura para el cancer o buscar vida fuera de nuestro planeta. Los usuarios le estarían cediendo sus recursos a una web durante el tiempo que se pasen consumiendo sus contenidos.

Si esto se usase como sustitutivo de los anuncios (que cada vez funcionan menos y peor en la web actual), no les supondría una gran carga adicional a los usuarios, puesto que los anuncios por si mismos ya están consumiendo recursos de sus máquinas. Además dejarían de estorbar visualmente.

También, se implementarían las webs para que tuviesen la menor cantidad de recargas, y para que se pase el mayor tiempo posible con ella abierta. Por ejemplo, en una web de noticias, esto es posible que provocase que se empezaría a dejar de lado el clickbait y empezar a crear contenidos realmente relevantes e interesantes.

Para saber si es algo rentable, tendríamos que tener en cuenta muchos factores, principalmente el valor puntual de la cryptomoneda que se esté empleando. También de cuanta cantidad de cryptomoneda se  lleva el minero que tenga éxito en encontrar el hash de un bloque. Por último, cuanto tiempo medio de visitante en la página se necesita para encontrar un hash. Podríamos meter más variables como el coste de adquisición de un usuario, lo que se deje de ingresar por publicidad o muchas otras cosas, pero sólo con estas tres variables ya se ve que hay que centrarse en un caso particular para determinar si es rentable o no.

Por ejemplo, cada vez que se encuentra un hash de un bloque de Bitcoin, el minero se lleva 12.5 Bitcoins (aunque se dividirá por dos en el futuro). El precio de los Bitcoin es muy variable, pero hace ya días que está por encima de los $5,500. Por tanto, estamos hablando de más de $70,000. Por ejemplo, atendiendo a las cuentas públicas de un medio que conozco bien, les bastaría con conseguir minar un hash a la semana para ser rentables y olvidarse de la guerra de la publicidad.

Lo difícil es saber como de factible es que un sistema distribuido como este consiga minar uno de estos hash, pero desgraciadamente de eso no hay muchos datos y tendremos que esperar a que algún medio con suficiente calado se anime a hacer pruebas legítimas y en condiciones, y que posteriormente se animen a compartir esa información.

¿Cómo lo veis como usuarios? ¿Os preocuparía que se usase vuestro equipo para esto si a cambio os libraseis de la fastidiosa publicidad?

Machine Learning fácil fácil

Dentro de esa serie de posts en los que explicamos de un modo muy asequible cosas tan abstractas como los hash, los blockchains o incluso la economía colaborativa, llega el momento de hablar de algo que a la mayoría le parece super futurista y abstracto, pero que en realidad es fácil fácil: el machine learning.

El objetivo principal de machine learning (aprendizaje automático) es que las máquinas aprendan para tomar decisiones. En concreto, su aplicación suele centrarse en que dado un nuevo elemento, un programa de ordenador decida si está en una categoría de un grupo de categorías dado.

highway toll photo
Photo by Dougtone

Vamos a ejemplificarlo con un caso que pudiera ser real: resulta que el gobierno decide que para volver a hacer las autopistas rentables, va a cambiar su modelo. Quitará el límite de velocidad, y los conductores pagarán en función de la velocidad a la que transiten. Para las que se pagan a posteriori no tienen problema y lo implementan en un par de meses, pero las que se pagan por anticipado son un problema y aunque ven que es un modelo que funciona, no lo pueden aplicar ya que no pueden cambiar todas las cabinas de peaje al otro extremo de los tramos.

Un investigador de una universidad se percata casi por accidente de que la gente que más rápido transita utiliza ciertas marcas de automóvil influenciados por los tramos y las horas del día. No es en el 100% de los casos, pero si se cumple en un porcentaje suficientemente alto como para decidir que se puede cobrar en el peaje un fijo en función de la marca del coche que se tenga.

Para esto se tomarían un montón de fotos de radares, cámaras y demás dispositivos de vigilancia y si clasificarían en función de la marca del coche que aparece en ellas. Cuanto más grande sea la muestra inicial mucho mejor, pero pasa como con las muestras de encuestas de población: con ¿650? personas con determinada distribución, se puede predecir el comportamiento de todo Cantabria, y tener 1000 personas no hace que se acierte mucho más, tal vez se afine un 0.01% adicional que no resulta sustancial.

De estas fotos agrupadas en categorías, se seleccionan ciertas propiedades que sean diferenciales. Estas pueden ser muy variadas, por ejemplo puede ser la disposición de los pixeles del centro de la foto en una conversión a grises, puede ser las coordenadas de la cabina de peaje dónde se tomo, la hora, el número de pixeles que hay entre las ruedas, … cualquier información que se tenga puede ser útil, pero no toda la información lo es. Por eso hay que trabajar con esas propiedades para reducirlas al mínimo necesario a tratar para tomar una decisión acertada. Por ejemplo, se puede llegar a la conclusión de que la distribución de pixeles del centro de la foto aporta exactamente lo mismo que los pixeles que hay entre las ruedas, por lo que no tiene sentido tratar ambas propiedades y es mejor gastar energías en determinar el valor de una sola de ellas.

Cuando ya se han encontrado las propiedades adecuadas, se plantea una formula, el modelo: un algoritmo sencillo que dada una nueva imagen nos vaya a determinar en que categoría hay que incluirla. Esta puede ser algo tan sencillo como:

ax+by+cz

siendo a, b, y c constantes que hemos determinado en nuestros procesos previos, x el color predominante en la foto, y un valor valor que representa la distribución de pixeles centrales de la foto y z la hora en la que se tomó la foto.

El valor de esta formula nos dirá que de 0 a 0.2 son los coches de marcas cuyos propietarios suelen ir despacio, de 0.2 a 0.6 son los que suelen ir a la velocidad marcada por la vía, y de 0.6 a 1 los que suelen ir por encima de la velocidad recomendada.

Por tanto, una vez obtenida esta fórmula, ya se pueden procesar las fotos tomadas en las cabinas de telepeaje, de tal modo que se determine instantáneamente si un conductor debe pagar 2, 5 o 10 euros.

Esto tan sencillo es machine learning: encontrar ese modelo que se puede aplicar de un modo automático para tomar decisiones. Fácil ¿no?

Una vez entendido esto podemos entrar en la distinción entre aprendizaje supervisado o no supervisado, deep learning y otras cosas; pero estas son otras historias que tendrán que ser contadas en otro momento.

Blockchain fácil fácil

Ya son varias las personas de distinto ámbito que me han pedido una explicación sencilla de lo que es Blockchain, así que supongo que es un tema que debo plasmar aquí, y dejar de contarlo entre cervezas. Voy a intentar que cualquier persona con una base técnica mínima pueda entenderlo, pero ante las dudas preguntad en los comentarios 😉

blockchain photo
Photo by btckeychain ©

Blockchain, como su propio nombre indica, es una cadena de bloques. En cada bloque se almacena una información y el hash del bloque anterior (¿os acordáis de la explicación sobre lo que es un hash de la semana pasada?).

De este modo, al almacenar cada bloque la «firma» del anterior, si se cambiase el contenido de un bloque se alteraría esa firma, con lo que habría que cambiar el contenido del siguiente bloque, y así sucesivamente hasta llegar al bloque más actual.

Eso, así de simple es un blockchain.

Ahora bien, seguro que habéis oído que este sistema se está usando en criptomonedas y en otras soluciones porque se supone que no se puede alterar los bloques ¿no?

En un blockchain que se almacenase en un solo lugar sería «trivial» alterar el contenido de un bloque random. Sin embargo, todos los sistemas que se están basando en esto son sistemas distribuidos, en los que hay muchos participantes que mantienen una copia de toda la cadena de bloques, por lo que para poder alterarla sin que todo el mundo se de cuenta, no sólo habría que modificar todos los bloques que maneje una máquina, si no que habría que hacerlo en todas las máquinas que almacenan una copia.

Vamos a poner un ejemplo práctico aplicado a algo que muchos habréis sufrido:

  • Imaginemos que tenemos un cuaderno en el que vamos a apuntar el acta de las reuniones de una comunidad de vecinos.
  • Para que no haya alteraciones, decidiremos que cada página tiene que empezar siempre con el «hash» de la página anterior.
  • El hash en este caso (para que sea fácil de calcular a mano), estará formado por la primera y última letra de cada fila y entre ambas el número de caracteres.
  • De este modo, si cambiásemos una página cambiaríamos su hash, que al ser la primera línea de la página siguiente, nos provocaría también cambiar su hash, etc. etc.
  • Un presidente maquiavélico podría comprarse un nuevo cuaderno para cambiar todas las actas y plasmar que a él se le eligió de por vida. Pero, si todos los propietarios tuviesen una copia del cuaderno, el presidente no podría hacerlo a no ser que pudiese entrar en todas las casas de todos los vecinos a pegar el cambiazo por un cuaderno modificado.

¿Queda claro?

Las aplicaciones de esto pueden ser muchas, aunque generalmente se usa para crear soluciones que eliminen intermediarios.

Por ejemplo, es la base de Bitcoin, la primera criptomoneda que se creo para poder hacer micropagos. El problema de los micropagos, era que al tener a los bancos como entidades intermediarias, las comisiones hacían imposible realizar estos micropagos. Al eliminar los intermediarios, los pagos pueden ser gratuitos, y hacerlos tan pequeños como se quiera.

Esa es la teoría, porque Bitcoin se ha expandido mucho por otros motivos derivados de la eliminación de intermediarios (anonimato, capacidad de especulación desmesurada, acceso universal, …), pero eso ya es otra historia que tendrá que ser contada en otro momento.

Explicación fácil de lo que es un «hash»

Si nos pusiéramos muy técnicos tendríamos que hablar de qué y cómo son las funciones hash, pero no es el día. Saber que son los hash es necesario si queremos hablar de Blockchain, de BigData, y de muchas otras moderneces con propiedad. Pero no es necesario entrar en detalles ni ponerse muy técnico para entender lo que son y como se usan. Vamos pues.

byte photo

Aquí ya hablamos de las tablas Hash, que son un patrón de diseño de sistemas distribuidos. Pero más allá de eso se usan en montones de estructuras de datos, de algoritmos y demás.

El hash es como se llama coloquialmente al resultado de una función hash, y estas son funciones que se encargan de transformar un conjunto de datos en una simple cadena de texto. Digamos que el hash es como una firma que resume a todo un conjunto de datos.

Por ejemplo, imaginemos que yo tengo un boli Bic azul comprado ayer mismo. Su hash podría ser (por ejemplo, el proporcionado por una función recién ejecutada en mi mente) BBA20170703005301058. Si aplicásemos la misma función a cualquier otro boli nos daría un valor distinto y si se la volviésemos a aplicar a ese mismo boli nos volvería a dar este valor.

¿Y esto para que sirve? Por ejemplo, si algún malvado villano me escondiese mi boli entre un millón de otros bolis similares (todos Bic azul), sólo tendría que aplicar esta función a cada boli hasta encontrar el que tiene esa firma para saber que es el mío. Otra función sería, si castigásemos a nuestro villano favorito a ordenar todos los bolis en un gran almacen, este podría ir apuntando la firma de cada boli con la estantería en la que lo guarda para luego poder encontrarlos de un modo rápido y fácil.

Estas, a bote pronto, son las funciones principales que se me ocurren (demostrar autenticidad y conseguir indexación), pero es muy posible que se usen estos códigos en muchos otros ámbitos que a mi ahora no me vienen a la cabeza. ¿Tenéis vosotros en mente otros ejemplos?

Lo normal, es que este tipo de funciones tengan en cuenta todo el conjunto de datos, o todas las características del objeto sobre el que se aplica, de tal modo que si el villano hubiese sido tan perverso de cambiar el capuchón de mi boli por el de otro, habría conseguido vencerme, pues la función hash que yo había ideado ya no proporcionaría el mismo valor.

Depende de para que se use, podemos encontrarnos con problemas, ya que puede ocurrir que haya colisiones y que, por una alineación de los astros, para dos objetos distintos se obtenga el mismo hash.

Sin embargo, a pesar de esas posibles colisiones, al ser (normalmente) el resultado de un algoritmo de compresión con pérdida, de un hash no se puede obtener el objeto original invirtiendo la función, así que será muy difícil encontrar para un hash un objeto o conjunto de datos válido que pueda sustituir al original como auténtico sin serlo. Esta es la clave, por ejemplo, de su uso dentro de los blockchains, pero eso ya es otra historia que deberá ser contada en otro momento.