¿Está vivo el "sueño" del Metaverso? Second Life se apunta al formato GLB del Metaverse Standards Forum

Me vais a matar, soy María otra vez. ¡No es culpa mía que vaya todo tan rápido! Hoy os traigo novedades frescas sobre... Tachán tachán... ¡¡¡El Metaverso!!! ¿Ves? He dicho “Metaverso” y no se me han caído los ojos de sus cuencas ni nada.

Figura 1: ¿Está vivo el "sueño" del Metaverso?

Second Life se apunta al formato GLB del Metaverse Standard Forum

¿Te imaginas tener acceso fácil a realidades extendidas y mundos virtuales? ¿Tan fácil como ahora accedes a Internet desde el dispositivo que tengas a mano? ¿Y te imaginas estar compartiendo tus propias creaciones virtuales, igual de fácil que ahora compartes vídeos en TikTok o en reels? ¿Te ves participando en una nueva economía de creadores que forme parte de ti como el respirar? Pues puede que ese futuro se esté acercando... Y puede que no venga de donde crees.

Figura 2: Esa soy yo en Second Life, es mi bienamada avatar Irma.

 
Reto: si aciertas dónde surgió la idea para este artículo, te llevas un tontipunto. Pero no me hagas trampa, ¿eh? ¡Espera a leerlo hasta el final! Bueno, haz lo que te plazca XD

Primero, un poco de contexto

¿Te acuerdas de hace casi 4 años, en octubre de 2021, cuando Mark Zuckerberg nos contó en Connect su visión del Metaverso? Los que estamos en estas cosas lo entendimos normal, a la primera, sin problema. Pero por algún motivo que nunca comprendí, la idea fue procesada por el mundo en general al estilo Martes y 13 con Encarna de Noche y las empanadillas de Móstoles. Perdona porfa si no conoces la referencia, es humor español absurdo de los años 80.

Figura 3: vista en detalle, un avatar actual en Second Life (male).

 Imagínatelo, alta calidad gráfica y animaciones preciosas.

Empanadillas aparte, desde el anuncio de Zuckerberg muchísima gente nos pusimos a trabajar súper ilusionados, pensando en construir paso a paso un futuro que nunca antes había sido posible imaginar: un futuro de interoperabilidad. Una idea chula... Aunque confieso que siempre fui escéptica. Bueno, no siempre. Creo que fue en 2008 cuando perdí la fe del todo.

Interoperabilidad, ¿2021 era demasiado pronto?

¿A qué me refiero con interoperabilidad? A estándares. ¿Para qué? Para poder transitar por diferentes mundos o experiencias inmersivas, entrar, salir, saltar de una a otra... Siendo un único tú, un único usuario: un avatar, una agenda, una wallet. ¿Por deporte? No: por economía. ¡Ticling!

Figura 4: Second Life Marketplace, el equivalente en esta plataforma

a “Amazon”, donde vender y comprar de todo al instante.

Una vez superado el hype del anuncio de Zuckerberg (y con este sentido del humor tan sofisticado que se nos ha quedado, consistente en reírse entre dientes cada vez que alguien dice “Metaverso” como si fuera un chiste de pedos), parece que efectivamente el tiempo pone todo en su sitio y las plataformas de mundos virtuales, en su esfuerzo por mantenerse a flote, tienden a ir en la otra dirección: no hacia interoperabilidad (ciento volando), sino hacia “walled gardens” (pájaro en mano).

Figura 5: vista en detalle, un avatar actual en Second Life (female).

Si esta es su cara, no quieras imagiar su cuerpo, grrr... ¡Miau!” =^_^=

  
¿A qué me refiero con “walled gardens”? A lo que suena: economía cerrada. Por lo que observo, parece que cada plataforma se está plegando sobre sí misma, buscando una economía propia que le permita sobrevivir a corto. No digo que esté mal, Woz me libre, es sólo que el momento es así ahora. Posiblemente 2021 era pronto para interoperabilidad... Especialmente si hablamos de plataformas nuevas, que seguramente tengan que consolidarse muy mucho antes de pensar en romper fronteras.

El monstruo que acecha... Esperando su momento

Y sin embargo, no todas las plataformas de mundos virtuales son nuevas, ni mucho menos. Hay algún maromazo por ahí que a la chita callando lleva más de veinte años levantando un mundo paralelo bit a bit. Un mundo habitado, creado y sostenido por una comunidad súper pro y freak a morir. Un mundo con una economía consolidada, comprobada y curada en el tiempo. Un mundo sólido, viejo, fuerte, preparado para romper esa frontera en cuanto las nuevas capacidades de Internet lo permitan.

Figura 6: Philip Rosedale pilotando su avatar Philip Linden en SL.

Ya ves a quién me refiero... ¡Efectivamente! Es Philip Rosedale: el jefe súper supremo y fundador de Linden Lab, la empresa detrás de Second Life. Por si no le pones cara, te dejo este simpático vídeo de tres minutos y medio del World Economic Forum.

Figura 7: Vídeo de tres minutos y medio del World Economic Forum.

Podéis ponerme mil pegas: podéis decirme que Second Life es sólo para ordenador, que no funciona con gafas de VR, que no incluye experiencias AR, que ni siquiera se puede acceder mediante navegador porque sigue dependiendo de un viewer... Y es verdad. Tienes toda la razón. Y esa es precisamente la barrera que Second Life podría -hipotéticamente- estar en posición real de derribar, llegado el momento.

Como ya te conté en este artículo anterior, mientras las plataformas nuevas (las que empezaron su andadura después de la idea de Zuckerberg) se repliegan de momento hacia “walled gardens”, Second Life parece calentar motores. Primero con las pruebas en navegador mediante pixel streaming como te conté la otra vez. Y ahora... Atiende que voy:

Second Life está adoptando estándares (.glb)

El pasado viernes 8 de agosto, Second Life actualizó su viewer a la versión 7.2.0.16729091892 – 2025.05, con una feature de lo más interesante: permiten la importación de modelos .glb, uno de los estándares de objetos 3D que más se está utilizando en diferentes plataformas de mundos virtuales sociales.

Figura 8: A principios de agosto, Second Life ha dado un

primer paso para la adopción del estándar glTF.

Hasta ahora, para subir un modelo 3D a Second Life se necesitaba un editor 3D que permitiese la exportación en COLLADA (.dae), formato desarrollado inicialmetne por Sony Computer Entertainment y que ahora es gestionado por Khronos Group.

El formato COLLADA está basado en XML y es más utilizado en workflows de edición y transferencias entre software 3D clásico, no es muy rápido y a veces su peso es excesivo. El formato GLB, en cambio, es binario, más compacto, rápido, y especializado en XR y plataformas de Metaverso, aunque es menos editable, tiene soporte limitado para materiales avanzados y no todas sus extensiones son 100% compatibles para cualquier runtime.

Figura 9: Exportando glTF desde Unity, con KHR_Interactivity integrada.

Una de las extensiones que no están completamente soportadas es la de glTF interactivity, que además de geometría, materiales y animaciones, permite añadir interactividad a los objetos a través de Unity y visual scripting. ¿Os imagináis lo que significaría poder crear los comportamientos de un elemento 3D en un único entorno, y poder importarlo en casi cualquier plataforma de Metaverso? Yo sí XD! Porque me lo enseñó a principios de junio el gran Iker Jamardo de Google ;) Si te interesa, lo tienes muy a mano porque se trata de un plug-in del propio Khronos Group.

Llámame loca... Pero juzga por ti

Recapitulando: ¿son imaginaciones mías, o Second Life está adaptando los estándares que se están proponiendo desde el Metaverse Standards Forum? Lo digo porque los archivos .gltf (o .glb en su “traducción” a binario) se están planteando durante los últimos cuatro años como la base de la interoperabilidad de objetos entre mundos virtuales, con la posibilidad de incluirlos en escenas .USD, que albergarían diferentes objetos .glb dentro de ellas.

Si te suena a chino... ¡Dime qué dialecto XD! Me refiero a que la adopción del estándar glTF es sólo uno de los working groups en los que están trabajando desde el Metaverse Standards Forum donde hay muchas más líneas de trabajo abiertas. Si te interesa conocer más, aquí tienes el listado completo.

Figura 10: Tocando el ukelele con mi avatar Irma.

¿Ves mi cara de concentración?

Llámame loca (¡Loca! Graciasss) pero, ¿no parece que esto es medio paso más de Second Life hacia la interoperabilidad entre mundos virtuales? Y digo “medio” porque ahora mismo subir modelos .glb a SL todavía tiene limitaciones, como la necesidad de importar por separado el modelo y el material, y unirlos después dentro del editor de Second Life... Bueno, no pasa nada. La otra mitad del paso está a punto de completarse: no hay más que echar un vistazo a las contribuciones de la comunidad en GitHub o seguir las conversaciones en Discord, y ahí ya se ve que esta feature avanza rápido, ofreciendo cada vez más posibilidades.

Ideas perversas al alcance de todos

Llegados a este punto, supongo que llevas ya un rato pensando en ideas perversas con esa cabecita traviesa tuya, ¿a que sí? ¿A que estás pensando en herramientas de creación de modelos 3D con Inteligencia Artificial como Meshy o Tripo, que permiten la generación de modelos 3D a través de un prompt de texto y/o una imagen y su posterior descarga en formato .glb? 

Figura 11: Vista en detalle, accesorios para lengua en Second Life, impensables

(por varios motivos) en plataformas de mundos virtuales más recientes.

¿Eh, eh? ¿A que sí? ¡¡¡Pues claro que sí!!! Y Philip Rosedale y su equipo también, no te quepa duda. Lo que no sé es a qué esperas para probarlas, alma de kantarooz =^_^=

Pero esos avatares... ¿No son demasiado chulos?

En las imágenes que te he ido poniendo ya has visto que los avatares en Second Life son una pasada. ¡Y no es porque fueran así originalmente! Bajo la piel de cada avatar precioso que ves, hay un avatar básico de sistema recubierto por piezas 3D interactivas creadas por otros usuarios a lo largo del tiempo (User Generated Content). Para poder hacerte un avatar así, han tenido que pasar veinte años.

Figura 12: fíjate en la joyería tan intrincada que lleva este avatar.

Esta complejidad de geometría era impensable hace veinte años.

Durante estos veinte años, la comunidad de Second Life ha ido puliendo y perfeccionando métodos ingeniosos para hackear el avatar de sistema, añadiendo capas de creciente complejidad y belleza. Al mismo tiempo, Linden Lab no se ha quedado atrás y ha ido ampliando las capacidades de Second Life a la par que el propio Internet iba creciendo y madurando.

Hoy por hoy, armar tu avatar es un proceso absolutamente delicioso. Puedes comprar cada componente a tus artistas favoritos (cabeza, pelo, cuerpo, ropa, animaciones...) e ir ensamblándolo todo a tu gusto. Incluso puedes ser artista tú también y vender tus creaciones a los demás.

Figura 13: Bakers on Mesh (BOM)El viewer de Second Life “tuesta” todas las texturas

de tu avatar en una textura única, ahorrando recursos de render sin que tú tenga

 que hacer nada.¡Y puedes cambiar tu ropa, pelo accesorios... Siempre que quieras!

  
Pero espera... ¡Piensa un momento! ¿Y si en un futuro no demasiado lejano Second Life fuera un paso más allá y consiguiera adoptar el formato .vrm, que es el estándar por el que se están decantando en el Metaverse Standard Forum en cuanto a avatares y moda digital? ¿Y si pudieran hacerlo compatible con la creación de avatares por piezas? No sería la primera vez que Second Life ingenia algo así: mira si quieres cómo se lo montaron para mapear todas las texturas del avatar en un solo atlas, sin que el usuario sea consciente de ello. La solución se llama “Bakes On Mesh” (BOM) y es brillante.

En la línea de fuego

Cada día estoy más convencida de que los veinte años de ventaja que tiene adelantados Second Life respecto al mercado la colocan en la línea de vanguardia para romper la barrera de la interoperabilidad, en cuanto las nuevas capacidades de Internet y los nuevos dispositivos lo hagan posible. Y te digo por qué.

El hecho de que Second Life esté abriendo su runtime a otros formatos de modelos 3D más allá de COLLADA, concretamente estándares como .glb, para mí es una declaración de intenciones. Si Philip Rosedale, que ha conseguido mantener su plataforma de Metaverso abierta durante más de 20 años (a base de ofrecer a los usuarios lo que le estaban pidiendo), se está colocando en la línea de fuego de esas nuevas fronteras... ¿Qué más no tendrá en mente?

Figura 14: Warning! Irma sigue observando.

Se lo dije a Iker Jamardo cuando estuvo aquí, os lo digo a todos: atentos a Philip Rosedale que es un pieza el figura. Y ¿quién sabe si ahí donde lo ves, tal vez se esté preparando para liderar la revolución cyberpunk? XD Yo por mi parte no le pienso perder ojo. Sin duda va a resultar muy interesante seguir sus movimientos ;)

Saludos bue... ¡Ay, espera!

¿Recuerdas el reto del principio? Te había prometido un tontipunto si acertabas dónde surgió la idea para este artículo. Pues... ¡Efectivamente! Surgió en el chat público de este blog, El lado del mal, en MyPublicInbox. Fue durante una conversación con mi querido Ángel Soto (Anso) sobre NotebookLM...

Figura 15: Participa en la conversación Pública de El lado del mal 

¿Acertaste? ¿Sí? Genial: ¡tontipunto para ti! Ya sabes adónde venir a canjearlo por un “hola qué tal”: a mi buzón en MyPublicInbox, o al chat público de El lado del mal ;)

Ahora sí... ¡Saludos buenignos!

Autor: María Gómez Prieto

Contactar con María Gómez Prieto

El feed RSS "No Hack, No Fun" con todo lo que me interesa

Si eres de los que se subieron a la Web 2.0 con la llegada del RSS, seguramente seas usuarios de los lectores RSS y recordarás el "drama" que tuvimos cuando se cerró Google Reader para convertirlo en parte de Google+. Una pena que acabó como acabó. Yo me moví, como muchos a Feedly, y sigo siendo un usuario de los canales RSS. No me gusta estar al vaivén de lo que se viraliza por redes sociales, me parece que es más fácil ese canal para que te lleguen Fake News y estar a merced de bots, campañas de Growth Hacking, etcétera. 

Figura 1: El feed RSS "No Hack, No Fun" con todo lo que me interesa

Pero es una opinión personal, así que sigo teniendo cargado mi lector RSS de feeds que leo todos los días. Se me puede pasar lo que sucede por las redes sociales, pero no lo que me entra por mi canal RSS. Ahí sigo a la gente de la que me fío, la gente que publica cosas que me parecen interesantes, y es mi principal foco de estar conectado al mundo. Si no pasa en mi lector RSS, puede que no me interese tanto. 

Figura 2: Periódico Online "No Hack, No Fun"

E igualmente que consumo, hay un Feed RSS que genero con todo lo que publicamos, con todo lo que es interesante para mí, con todo lo que mis equipos, amigos, y gente de mi interés publica. Es el Feed RSS de "No Hack, No Fun". 

Figura 3: Feed RSS de "No Hack, No Fun"

Como sabéis, "No Hack, No Fun" está construido sobre Paper.ly, en forma de periódico online con todo lo que publicamos y me interesa de las Redes Sociales e Internet. Yo lo mantengo a diario. Todos los días doy de alta unas 50 publicaciones a la semana con lo que hacemos o que me interesan, y cada semana - más o menos - lo rehago de cero. Es uno de los trabajos rutinarios que hago durante años, y lo sigo manteniendo.

Figura 4: Feed RSS "No Hack, No Fun" en Feedly

Este periódico online, además de tener su versión para navegar por las secciones, tiene también una lista de distribución por e-mail, donde, cada vez que doy por terminada una edición, la envío a las miles de personas que están suscritas.

Figura 5: Unos 47 artículos por semana de media

Pero si quieres tener todas las noticias que publicamos y que son de interés para mí, también puedes seguir el Feed RSS de "No Hack, No Fun", que tienes en la siguiente URL. Basta con que vayas a tu lector de feeds RSS y lo pongas. 

Figura  6: Siguiendo "No Hack, No Fun" en RSS en Feedly

Tendrás todas las noticias y publicaciones que hacemos, y que son de mi interés, en un único Feed RSS que puedes seguir sin necesidad de ir a la web. Así que, si eres de los que disfruta de leer las noticias sin ads ni cookies, en un lector rápido y configurado para ti, tienes toda mi actividad resumida en un único punto.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Common Vulnerability Reporting Framework 1.1

Los días que hay muchos advisories de trabajo siempre pienso en mi amigo Sergio de los Santos echando "ofús". Esos días debe filtrar todos los documentos publicados por los fabricantes de software para que sean distribuidos a través de su servicio SANA y para ello debe pegarse con las maneras que cada uno de los fabricantes tienen de poner disponible esa información, así que sé que tiene una tarea larga por delante, por muy automatizados que tengan los procesos internos.

Esto es algo que sucede en casi todos los frameworks de gestión de vulnerabilidades, consolidación de reportes, o integración de resultados, en los que se muestra el expediente de seguridad del fabricante para ampliar la información del bug.

Para evitar esto se está trabajando en estandarizar la forma en la que se publica y consume esta información en un formato de documento definido como Common Vulnerability Reporting Framework, en el que se intenta crear un tipo de documento en XML que sea capaz de ser producido y procesado de manera estándar.

Figura 1: Esquema del schema de CVRF 1.1

El formato del documento está siendo definido por ICASI (An Internet Consortium for Advancement of Security on the Internet), y en el whitepaper publicado, además de justificar la necesidad de un consenso para hacer más fácil gestionar esta información, expresan la necesidad de seguir trabajando en la integración y evolución de otros formatos estandarizados para comunicarse, como son:

- Security Content Automation Protocol
- Common Platform Enumeration
- Common Weakness Enumeration
- Open Vulnerability and Assessment Language

Hoy en día, modelos como el CVSS para medir la criticidad de una vulnerabilidad son ampliamente utilizados - aunque algunos fabricantes adapten esas métricas y la expresen de otra forma -, pero todos estos esfuerzos en estandarización del advisory ayudarán a que haya un lenguaje completo y no solo una "manera de hacer las cosas", para que sea mucho más sencilla la tarea de consumir toda la información de seguridad que se produce.

Algunos fabricantes ya han anunciado que comenzarán a utilizarlo, como es el caso de Microsoft o de CISCO, que incluso ha publicado un manual en dos partes con un ejemplo de cómo transformar un advisory de CISCO a formato CVRF 1.1.

- The Missing Manual: CVRF 1.1 (Part 1 of 2)
- The Missing Manual: CVRF 1.1 (Part 2 of 2)

Espero que en el futuro, mi amigo Sergio de los Santos eche menos "ofús" los días que se hayan publicado muchos security advisories, y le quede más tiempo para otras cosas.

Saludos Malignos!

Google FeedFetcher como arma de destrucción masiva

Ya hace tiempo que le dedicamos Enrique Rando, algunos alumnos del Master de Seguridad de la UEM y yo un tiempo a jugar usando los Buscadores como arma de destrucción masiva, así que cuando he leído la entrada de hackplayers sobre cómo hacer un D.O.S. utilizando Google, me he ido a leerme la historia completa de cabeza.

El resumen de la historia es bastante peculiar e interesante. Resulta que Google tiene un agente, que no es el famoso bot de indexación GoogleBot, que se utiliza para la recolección de feeds XML en servicios como Google Reader, al que se ha denominado Google FeedFetcher.

Este bot está pensado para recolectar el contenido de URLs y mostrárselas al usuario a través de un lector XML. Sin embargo, el comportamiento es que lo que se obtiene a través de este bot no se incluye directamente en los índices del buscador, por lo que no tiene que preocuparse y por lo tanto no lo hace, del incomprendido funcionamiento de los robots.txt.

Esto quiere decir que si un usuario hiciera una lista de todas las URLs de un sitio y las metiera en un feed XML al que se suscribiera, haría descargarse todo el sitio a Google FeedFetcher. Una vez descargado todo el sitio, Google Reader cachea los contenidos, como vimos en el artículo de Puedes borrar tu blog, pero Google Reader guarda el feed.

Sin embargo, como descubrió este profesor de universidad, Google FeedFetcher también se utiliza para descargar contenido público enlazado desde servicios privados de usuarios, es decir, por ejemplo una hoja de cálculo en Google Docs que cargue un imagen desde una URL. Como este contenido no se cachea, Google FeedFetcher cada cierto tiempo va a volver a solicitar esa imagen al servidor.

De esta sencilla forma, creando una hoja de cálculo manipulada en Google Docs con carga de contenido remoto de un sitio, Google FeedFetcher estará descargando las URLs generando grandes cantidades de tráfico y costes en servicios de pago por uso de ancho de banda.

Figura 1: La factura de Amazon del profesor que se hizo su ataque vía Google DOCs

Lo curioso de este comportamiento es que los feeds XML manipulados, pueden convertirse en una buena arma de destrucción masiva si los bots no tienen límites adecuados o cacheo de contenido, ya que haciendo uso de Servicios de publicación masiva de Feeds, como por ejemplo Total Ping, un atacante podría crear un feed XML que cargase las URLs más pesadas de un sitio. Después lo publica en una URL de Internet y lo da de alta en Total Ping, generando que muchos bots automáticamente descarguen el contenido. 

Figura 2: Agregadores en los que Total Ping da de alta el feed XML

Para conseguir que aún sea más divertido, podría dar de alta varios feeds XML maliciosos apuntando a contenido del mismo objetivo, e ir rotando continuamente las URLs para que el bot que hace el crawling siempre lo perciba actualizado. Si el objetivo tiene una web de pago por uso de ancho de banda, seguro que no le hace mucha gracia.

Saludos Malignos!

Aprende más sobre esto en el libro: Hacking con Buscadores: Google, Bing & Shodan

Dust RSS: Una breve introducción

La idea de utilizar un sistema de distribución como DUST vino precedida por la controvertida persecución que hemos visto estos últimos tiempos entre los partidarios y los detractores de Wikileaks. En el caso de Wikileaks, el revuelo mediático producido fue tan grande, que consiguió aunar las fuerzas entre atacantes y defensores. Sin embargo, ¿qué podría hacer una persona única que publica su blog contra un ataque de estas características? Poco.

Con este planteamiento pensamos en hacer un sistema que, con los menores cambios posibles, cualquiera pudiera publicar sus noticias, sus posts, y garantizar la perdurabilidad de su canal de noticias y de sus usuarios.

Actualmente la mayoría, si no todos, de los blogs tienen publicado un feed RSS. Lo normal es que este feed RSS se encuentre en algún formato estándar basado en XML entendible por los clientes RSS que tienen los lectores. Todo esto funciona de maravilla, y no queremos tocarlo, queremos que se siga utilizando esta infraestructura de feeds, pero queremos cambiar el canal, para no depender de HTTP.

El Feed al P2P

Con este fin, pensamos en algo bastante evidente, utilizar canales P2P, lo que es bastante evidente. En un entorno “extremo”, es decir, en caso de emergencia, alguien podría publicar, cuando estuviera bajo un ataque, el fichero XML en la red P2P y punto. Sin embargo, su audiencia tendría que saber de ese cambio y, sobre todo, estar preparado técnicamente para este cambio.

Un cliente RSS que haga polling al P2P

Es por ello, que nuestro objetivo es tener con Dust RSS un cliente que haga polling al P2P, al igual que los clientes RSS tradicionales hacen polling por HTTP. Es decir, que los clientes se puedan suscribir al feed RSS vía P2P de igual forma que a día de hoy lo hacen al feed RSS vía http. Este cliente, lo que va a entregar, a cualquiera de las aplicaciones que lo quieran utilizar, es un feed XML del blog, que luego la aplicación de turno procesará tal y como procesa los feeds RSS que descarga vía http.

La distribución de los contenidos externos al XML

Hay que tener en cuenta que muchos componentes que se visualizan en la lectura de un feed XML son externos, es decir, que en el documento XML solo vienen referenciados por su ruta http, es necesario hacer una publicación de los mismos vía P2P, así, cuando se “dusterice” el Feed RSS hay que añadir un modificador a las etiquetas que vinculan contenido externo http para indicar que esos documentos están disponibles en la red P2P, y bastará con añadir su hash de publicación en la red.

La publicación del Feed RSS

Por supuesto, una vez creado el fichero XML, este deberá ser compartido por P2P junto con todos los archivos vinculados. Con este procedimiento, el fichero XML estará en la red P2P y en él estarán los hashes de descarga P2P de todo el contenido externo, que también estará en la red P2P. El cliente DustRSS deberá hacer polling por el nombre del feed, descargarlo, leer los vínculos p2p externos, y descargarse el contenido externo de la red P2P para poder darle al lector RSS un feed completo.

Evitar suplantación de publicaciones con PGP

Por supuesto, en este entorno de trabajo, hay como problema, que cualquiera pueda publicar un feed e intentar suplantar al publicador, así que decidimos que todos los feeds fueran firmados con PGP, es decir, el hash del fichero en la red P2P más el nombre del blog firmados con la clave privada PGP.

Por su parte, el cliente dust RSS se encargará de hacer polling y comprobar que el fichero está firmado correctamente, lo que implica que durante el proceso de subscripción al feed RSS de Dust deberá obtener la clave pública del publicador, para así descargar solo los archivos XML correctos.

Cuando tengamos más avanzado el proyecto os pasaremos los detalles técnicos en detalle, ya que, tanto el dusterizador como el cliente se publicarán junto con su código fuente.

Esperamos que todos podáis ver la charla durante la próxima RootedCON, que la daremos el viernes 4 a las 13:00 horas y que, antes. os podáis suscribir vía Dust RSS a algunos blogs, y darnos todas vuestras ideas.

Saludos Malignos!