Pensé que eran cambios menores en Channel2RSS 💀

Introducción

Dado que los feeds no se pueden modificar y menos los newsletter, muchas veces el feed puede llenarse de spam de botoneras, algo que puede no notarse en los canales originales debido a que mediante bots, estos post son borrados automáticamente cada cierto tiempo. Entonces la mejor opción es directamente ignorar las botoneras. Aun así, no es posible notar un patrón claro en ellas, así que, para evitar ignorar mensajes con botones y mensajes de hablando de las botoneras, se bloquea directamente mensajes de canales que tengan caption y en el caption se mencione la palabra botonera.Obviamente esto funciona solo para español, pero si encuentro mejores criterios para discriminar este tipo de post, será algo que iré agregando conforme pase el tiempo.He agregado el botón del ko-fi. Por los loles nada mas, no es que le tenga mucha esperanza XD

Las botoneras y otros bots

El contenido automatizado puede ser un problema por cuanto es difícil determinar cuando es deseado por el usuario o es simple spam. Entiendo que sean necesarios para alcanzar cierta divulgación en un entorno sin algoritmos ni recomendaciones, pero a diferencia del canal donde reside el bot, el feed RSS no puede ser editado (todavia) para borrar la publicidad de la botonera. Esto es especialmente molesto en el modo Newsletter, puesto que alli el contenido si que es permanente. No hay forma de invadir la bandeja del suscriptor solo para borrar la publicidad de la botonera y esta pasa a ser simple y puro spam.De momento, solo detecto si un mensaje tiene la palabra botonera. Los bots pueden ser utilizados para publicaciones automáticas legitimas, por lo que discriminar por el tipo de usuario, puede ser contraproducente.

Las galerías o grupos de imágenes

Una de las funciones mas recientes pero que pasan desapercibidas son las galerías o grupos de imágenes. Al compartirlas, estas actúan como una sola entrada, pero en realidad son varias imágenes, cada una con su propia entrada y unicamente agrupadas mediante un media_group_id el cual debe ser interpretado por el cliente para mostrar las imágenes agrupadas. Por supuesto, el webhook recibe cada imagen por separado y simplemente las procesa como una entrada independiente cada una, produciendo que se publiquen muchas entradas sin texto y sin relación entre si.Esto provoca una molesta inundación de post, tanto en el feed como en el newsletter, así que el primer paso para controlar esto fue, ignorar todas las publicaciones que tienen el campo media_group_id activo.El problema del campo media_group_id es que no indica cuando comienza y cuando termina una galería. Telegram simplemente sigue tirando los mensajes a mi webhook y mi script solo puede procesar un mensaje a la vez. no puede quedarse esperando a la ultima imagen de la galeria y tampoco sabe cuando llegará, por lo que fue necesario crear un nuevo archivo llamado enviar_galeria.php donde se procesaría con mas calma los datos.A diferencia del webhook, que es activado por un llamado de telegram por una url publica, enviar_galeria.php es llamado por cron usando PHP en la consola, cada minuto.Me resulta imposible saber cuando llegará la ultima imagen de la galería que se este enviando, pero espero que lo haga en menos de un minuto, para que cuando el sistema lo analice, cree una galería completa, con su respectiva descripción.He aprendido de paso que puedo ejecutar cron a modo de ruta relativa, algo así tipo:* * * * * cd /var/www/misitio && php miscript.phpDe esta manera, el script puede ejecutarse teniendo en cuenta las rutas relativas que ya tiene de por si.

Mejoras

Sigo estudiando buenas practicas de programación, asi que la creación de este nuevo archivo me ha dado la excusa perfecta para revisar el código y mejorarlo un poco. Al momento, el webhook procesa cada mensaje de forma lineal porque no necesita mas pasos para hacerlo, pero con la creación del enviar_galeria.php ya me di cuenta que hace falta una forma de reciclar el codigo. Especialmente para las funciones de procesar el RSS y enviar las Newsletter. Como primer paso, he creado dos métodos que se encargan de ello y como próximo paso, puede ser que empiece a estudiar como se crean librerías y claro, usarlas. De esta manera puedo tener uniformidad en el código y reciclarlo para que sea mas fácil de mantener.

Curiosidades

• El modo lectura lleva un mes fuera de linea, pero aun siguen llegando peticiones a esas URL. ¿Han quedado registradas en algún lado para algo en especifico?
• Desde las ultimas correcciones, las peticiones se han calmado y ya solo hay para los feeds por parte de mi lector RSS y el webhook de telegram. Como soy el único usándolo, no se si haya fallas para otros usuarios.
• Definitivamente es culpa del IDE Atheos, así que abandono su uso.
• Corregido una vulnerabilidad que expone la base de datos
• Hubo un incidente en el que el IDE reemplazo gran parte del archivo principal con galimatias al guardar. Afortunadamente tenia un archivo anterior con el que pude medio reparar el código, pero la verdad, se perdieron algunos cambios de los que no estoy seguro cuales fueron. Creo que finalmente me decidí en implementar git, pero me da miedo.

Desarrollo de Bots: Channel2RSS

Changelog 22 de noviembre de 2025

• Se ignora todo mensaje de bot que contenga la palabra botonera (case insensitive).
• En el flujo principal, se ignora el procesamiento de los mensajes media_group_id.
• Se crea una nueva tabla galerias en la base de datos.
• En el flujo principal, se almacena recursos en la base de datos en su tabla galerias.
• Se crea un archivo enviar_galeria.php para el procesamiento de los datos de la tabla galerías.
• Se crean los métodos guardar_entrada() y enviar_newsletter() para próxima creación de una librería.
• Editado index.php para mostrar este changelog, claro.

TODO

• Había un error en algún lado pero me olvide donde esta. Tengo que depurar mas pero me da pereza.
• Hay que implementar git.
• Hay que corregir las entradas existentes para cumplir los lineamientos del validador de xml.

https://interlan.ec/2025/12/03/changelog-channel2rss-22-de-noviembre-de-2025/

#bot #changelog #channel2rss #correoElectronico #selfhosting #servidores #telegram

Channel2rss ha tenido algunas mejoras hasta el momento de registro de 22 de octubre de 2025

Introducción

Aprovechando Channel2RSS como herramienta de estudio, he estado investigando como funciona el despliegue de software basado en PHP en la actualidad. No he completado grandes proyectos en este lenguaje y lo que recuerdo es tan primitivo como para que el código que me enseñaron en la universidad se parezca a esto:

Así que estuve investigando nuevas formas de mantener la seguridad del código sin aumentar la complejidad del mismo.

El problema que tenia era que estaba acostumbrado al modelo de «Hosting Compartido» que permite solo subir los archivos PHP al directorio publico sin mayores pretensiones. Imagino que ahora eso ha cambiado, pero en principio, fue la razón por la que comencé a estudiar NodeJS pues la lógica no se encuentra en publico, sino que esta es la que decide que es publico o no.

Esto era así incluso hasta la época de Codeigniter 2.x que fue el ultimo que utilice y que abandoné cuando en su cambio a 3.0 luego de la muerte de su creador, ya funcionaba como Laravel, necesitando un interprete que sirva los contenidos según la nueva estructura de seguridad.

Composer

He empezado a usar Composer bajo la excusa de utilizar una herramienta como PHPMailer, así que, como este crea una carpeta llamada Vendor, considere que la estructura de archivos del momento, representaba un riesgo de seguridad innecesario. Hasta el momento había protegido el archivo de base de datos con reglas de nginx, pero esto hace que sea poco portable el código y en realidad, peligroso, pues puede filtrarse información sensible ante los random que andan dando vueltas con sus escaneres de vulnerabilidades todo el dia por internet.

Estructura de seguridad en archivos

Actualmente tengo control del servidor donde alojo mi proyecto, por lo que ya puedo decidir que es publico y que no lo es. Desconozco si esto es posible en los Hosting Compartidos actuales o si hay un método mediante .htaccess que permite lograrlo sin modificar el vhost, pero con esto ya puedo decidir una estructura que no haga públicos los archivos que deben ser privados, incluido el .env

Sigo actualmente esta estructura de directorio:

• 📂config (En un principio iba a usar un config.php, pero ya no)*
• 📂public
  • 📂cache
    • 📄archivo.xml
  • 📂public
    • 📂codigo_canal
      • 📄imagen.jpg
      • 📄feed.xml
  •  📄index.php *
  •  📄suscripcion.php
  •  📄desuscripcion.php
  •  📄webhook.php
• 📂src
• 📂vendor
•  📄.env
•  📄database.db
•  📄composer.json
•  📄composer.lock
•  📄webhook.log

* ¿Por qué se debe separar del código?La separación de la configuración del código ofrece varias ventajas:

• Portabilidad: Permite desplegar el mismo código en diferentes entornos (por ejemplo, desarrollo, pruebas y producción) sin necesidad de modificar el código.
• Seguridad: Evita que la información sensible, como contraseñas y claves de API, quede expuesta en el repositorio de código.
• Escalabilidad: Simplifica la gestión de configuraciones a medida que el número de despliegues de la aplicación aumenta, evitando combinaciones complejas de configuraciones.
• Mantenimiento: Facilita la comprensión y mantenimiento del código, ya que las configuraciones se gestionan de forma independiente y no se mezclan con la lógica de la aplicación.

¿Cómo se debe almacenar la configuración?
La metodología recomienda almacenar la configuración en variables de entorno. Este enfoque garantiza que la configuración sea independiente del lenguaje de programación y del sistema operativo, y proporciona un mecanismo seguro para inyectar las configuraciones en la aplicación durante la fase de ejecución.

Seguridad general

Tener organizado los archivos de esta manera permite detectar también los comportamientos extraños desde el log de nginx, el cual también recomiendo segmentar por Vhost si así lo usas. Actualmente no he promocionado por ningún lado la URL de este servicio, por lo que no debería llegar nadie, aun así, el trafico total ya llega casi al mega en el poco tiempo que tiene el nuevo log segmentado. También me llama la atención algunas URL mal formadas que pueden insinuar tanteos para probar la seguridad del sistema.

También es interesante notar la enorme cantidad de Crawlers que llegan. Es interesante que la mayoría del trafico es de Crawlers, pero también es interesante que alguien con Brave ha visitado el sitio 8 veces y al menos 1 vez fue visitada por un navegador safari.

Archivos de configuración

Siguiendo los principios de The Twelve-Factor App, una guia creada por los dueños de Heroku para el despliegue de SaaS (Software as Service o software como servicio), he cambiado la forma en la que se utilizan las variables de configuración, que en principio estaba hardcodeadas directo en el codigo y luego guardadas en config/config.php, pero ahora he separado la configuracion del codigo con el popular .env, que tanto buscan los crawlers por la red.

¿Por que lo buscan tanto? Bueno, eso es fácil, allí están contraseñas, usuarios y mas información importante que sin duda alguna te ahorraran muchas molestias como ciberdelincuente. Y esto es llamativo puesto que al ser algo muy importante debería estar oculto, pero como mencioné antes, lo normal en proyectos PHP era solo tirar todo en la carpeta publica y darte por servido tras llenar las variables que se requerían.

Por esa razón, en este proyecto ahora solo la carpeta /public es servida por Nginx, aunque la carpeta del proyecto siga en el directorio común. De esta manera, solo los archivos mas importantes dan la cara al publico, pero el acceso físico de los mismos sigue siendo posible con rutas relativas.

Las Newsletters

Esta es una nueva función experimental del bot. Para crearla, solo agregué dos archivos PHP, uno de suscripción y otro de descripción, ademas de dos plantillas HTML para los correos en cada acción. Al igual que el archivo RSS se actualiza al instante en cada publicación, también se enviará un correo electrónico apenas el canal publique. Esto es algo interesante por cuanto es posible estar al día con las novedades casi al instante, pero también puede llegar a ser abrumador. La función de desuscripcion se hace mediante un enlace mágico, el cual se encarga de eliminar el registro del usuario para que deje de recibir correos apenas se desuscriba. En lo posible, deseo guardar los mínimos datos que pueda, así que la fila seleccionada se borra con DELETE, pero eso hace que el usuario suscrito pueda ser suscrito casi a la fuerza. No se me ocurre una idea para evitar esto, pero en una próxima actualización podría estar agregando el borrado lógico de suscripción, que mediante un cambio de estado, la persona suscrita puede evitar permanentemente que se le sigan enviando novedades.

El fin de la vista lectura

No sabria si llamarle «fin» puesto que solo lo movi para poder corregir algunas cosas, aunque no estoy muy motivado a ello. Dado que el objetivo principal son los RSS, esto ya esta completado, mientras que al agregar los Newsletter, hacen menos necesario que exista un modo lectura de los canales.

He removido esta vista porque no la veo necesaria, pero si hiciera falta, la podria volver a incorporar. Hasta el momento, debido a que no ha sido publicitado, no tuvo ninguna vista humana, pero si una horrible cantidad de crawlers intentando descubrir vulnerabilidades. Mejor evito riesgos quitando una funcion que probablemente no le vaya a prestar mucha atencion.

Mejoras

Hace falta una opción de apagado de suscripcion. Tengo ideas de como se puede usar para mal las suscripciones que no comentaré por esta via, pero apenas vea comportamientos abusivos, es posible que la deshabilite.

Los bots de botoneras pueden llegar a ser muy molestos. No se todavia como filtrarlos, tampoco se si sea buena idea simplemente dejar de oir lo que miembros no humanos del canal digan, pero en algunas pruebas el contenido de botoneras puede superar al contenido humano, convirtiendo esto en un nido de SPAM

Algunos canales pueden tener una tasa de publicación muy alta. Estaba pensando que tal vez sea mejor hacer un resumen semanal o simplemente acumular todos los post para que se publiquen una vez a la semana. La verdad no tengo idea que camino seguir, puesto que quiero guardar la mínima cantidad de información sobre los usuarios. si los lectores tuvieran la opción de configurar sus preferencias, probablemente tendría que hacer un sistema de login y pos no.

Hay un bug de URL en los archivos de audio. No lo corregí por pereza. Luego revisaré.

Curiosidades

El archivo del modo lectura read.php tiene un problema raro y una de las razones por las que lo he quitado. Por alguna razon, cada que lo edito, sea desde mi compu en casa como en el server directo, puede darse el caso de que los cambios que hagan corrompa el archivo. Por ejemplo, si edito una linea y la dejo bien, al guardar puede que la siguiente linea se incruste en la anterior, dañando todo obviamente.

Algo mas

He configurado mi correo siguiendo las reglas DKIM y SPF actualizadas, tratando de que las grandes empresas no me marcen mis correos como SPAM, o que al menos llegue a la bandeja de SPAM, pero solo lo he probado con mi correo, así que no se si pasara esos filtros. Si no llegan los mensajes, revisa tu bandeja de spam, y marcalo como no spam. Si no funciona, ya revisare que pasa.

Desarrollo de Bots: Channel2RSS

Changelog

22 de octubre de 2025

• • Creada pagina suscripción

• Agregada la opción newsletter en index.php
• Correcciones de url relativa (eliminadas url absolutas)
• Creación de tabla suscripciones_canales
• Creada la plantilla de envío de correos
• Agregado soporte para composer
• Agregada la librería phpmailer
• Corrección de navegación: El Nombre de la pagina lleva a la pagina de inicio
• Correcciones varias para seguridad
• Se rompió la pagina de read.php funciona parcialmente, no aparece la descripción.
• Me cansé. a la porra la pagina de «read.php». sigo teniendo problemas de que los cambios que hago con ese archivo, se borran o se desplazan
• Agregado este changelog al index y preparado el de la pagina interlan
• Correcciones en la semántica del sitio
• Reestructuración del directorio del proyecto
• Agregadas variables de entorno
• Agregadas opciones de configuración rápidas

TODO

• Apagado de suscripción lógico (el usuario puede pedir que no se le suscriba mas)
• ¿Resumen semanal para no saturar la bandeja de entrada?
• Hacer el sistema para desuscribirse (no te preocupes, me escribes a [email protected] y me encargo de borrarte si no quieres recibir correos hasta que haga el sistema automatico)
• Por alguna razón los archivos de audio en el correo no enlazan al dominio correcto
• Es muy probable que los bots de botoneras y similares se vuelvan muy, muy hostiles con el usuario, especialmente si el dueño del canal deja de publicar, siendo que llenarían la bandeja de entrada de los suscriptores con mucho y muy horrible spam. ¿Debería bloquear la publicación de post desde bots?

Curiosidades

• El archivo read.php se corrompe regularmente. se agregan espacios o directamente se sobrescribe el archivo. no tengo idea de la causa

https://interlan.ec/2025/11/05/changelog-channel2rss-22-de-octubre-de-2025/

#bot #changelog #channel2rss #correoElectrónico #desarrolloWeb #devops #email #postfix #rss #selfhosting #servidores

Introducción

Los feeds RSS son una herramienta muy útil para seguir las actualizaciones de blogs y otras plataformas que publiquen de forma regular, porque permiten obtener los artículos de forma organizada y también permiten utilizar las herramientas de tu gusto para leerlos sin necesitar pasar por la pagina principal. Por esta razón, me gusta utilizar mi lector favorito en la actualidad, FreshRSS, selfhosted, con el que puedo leer cuando quiero y guardar los artículos que me gusten para ver mas tarde. Desafortunadamente no todas las plataformas ofrecen este servicio y no es posible seguirlas con un lector de RSS normal, como es el caso de los canales de Telegram.

Los canales de Telegram

Los canales de Telegram son una forma de microblogging  muy comoda que ofrece la plataforma, como un modo de difusión ligero y confiable para todo tipo de contenidos, en un formato de entradas cortas, con texto enriquecido y soporte multimedia con la capacidad de crear comunidades para comentar cada post. Actualmente es una plataforma completa de blogging que incluye una visualización de los contenidos sin necesidad de tener la aplicación instalada. Puedes visitar en  linea y con un navegador común un post especifico o ver todos los que se han publicado en la red. Debido a esto ultimo, me parecía fantástico que se pudiera leer mediante un lector de RSS, con el fin de poder guardarlos para lecturas posteriores y otras cosas mas.

Channel2RSS

Changelog

Corrección de errores

• Al agregar al bot a un nuevo canal, se guarda de forma errónea el id del usuario, por lo que he eliminado la tabla original y creado una nueva que vincule con el código del usuario y no con el id de usuario de la tabla. Corregido
• Index.php también tenia un error que no mostraba mas que un canal por usuario. Corregido,
• Se reconstruyo la tabla canales para poder usar como clave foránea codigo_usuario en lugar de id
• En la vista read.php, se ha agregado algo de estilo para centrar columnas en pantallas grandes, se ve bien en pantallas pequeñas. No soy muy creativo con los estilos. (Falló, vease meme:)

Conclusiones

Nada mas, me da pereza hacer mas cambios, pero con estos que hice queda espacio para mejoras.

https://interlan.ec/2025/09/24/changelog-channel2rss-22-de-septiembre-de-2025/

#bot #canalesDeTelegram #channel2rss #desarrolloDeBots #feed #rss #telegram

He tenido algunas ideas para mejorar el proyecto, por lo que channel2rss cuenta ahora con los siguientes cambios

Introducción

Los feeds RSS son una herramienta muy útil para seguir las actualizaciones de blogs y otras plataformas que publiquen de forma regular, porque permiten obtener los artículos de forma organizada y también permiten utilizar las herramientas de tu gusto para leerlos sin necesitar pasar por la pagina principal. Por esta razón, me gusta utilizar mi lector favorito en la actualidad, FreshRSS, selfhosted, con el que puedo leer cuando quiero y guardar los artículos que me gusten para ver mas tarde. Desafortunadamente no todas las plataformas ofrecen este servicio y no es posible seguirlas con un lector de RSS normal, como es el caso de los canales de Telegram.

Los canales de Telegram

Los canales de Telegram son una forma de microblogging  muy comoda que ofrece la plataforma, como un modo de difusión ligero y confiable para todo tipo de contenidos, en un formato de entradas cortas, con texto enriquecido y soporte multimedia con la capacidad de crear comunidades para comentar cada post. Actualmente es una plataforma completa de blogging que incluye una visualización de los contenidos sin necesidad de tener la aplicación instalada. Puedes visitar en  linea y con un navegador común un post especifico o ver todos los que se han publicado en la red. Debido a esto ultimo, me parecía fantástico que se pudiera leer mediante un lector de RSS, con el fin de poder guardarlos para lecturas posteriores y otras cosas mas.

Telegram también contaba con una plataforma de blogging mas completa pero abstracta llamada telegra.ph que por el contrario, aunque era minimalista, era imposible de rastrear los artículos a menos que se compartan como enlaces en algún lado. Actualmente ha perdido mucha popularidad debido a que ya no es posible subir multimedia y desconozco si esto fuera a cambiar. Otras aplicaciones como teletype intentaron ocupar el espacio que quedo disponible, pero parece que se han llenado bastante de publicidad. Era de esperarse. el alojamiento puede resultar costoso, especialmente cuando se gana popularidad.

Sobre la decisión de tener RSS

Dado que tener RSS no es una opción integrada de Telegram, considero que tenerlo debe ser una decisión personal. Aunque el canal sea publico, no considero que este bien escrapearlo. Es por eso que para tener este servicio, es necesario agregar el bot al canal para que se cree el feed. Puedes dejar de llenar el feed con solo quitar o bloquear el bot, pronto haré una función para eliminar el feed por completo también.

Lo que hace especial a este servicio

Realmente no es un servicio muy especial. Pretendo que sea mas atractivo al adoptar algunas características que no tienen los servicios que he explorado, como un titulo aclarando que tipo de articulo es, referencias al articulo de origen en caso de ser un reenvío y características del multimedia para el caso de archivos de audios.

Este servicio nació con la idea del podcasting en mente. Si bien por esta razón permito audio y voz, ademas de imágenes, no creo poder tener recursos suficientes para alojar mucho contenido. Por esta razón no publicitare mucho el bot a menos claro, que aparezca una forma de mantener el servidor.

Lista de cambios

Actualización de la pagina principal

• La pagina ahora es responsive, se ha agregado un estilo estandarizado temporal
• Se agregan dos enlaces, el primero al xml de RSS y el segundo al nuevo modo de lectura para las entradas del canal.
• Se agregan enlaces a los canales originales
• Se muestran solo los últimos 10 usuarios registrados en el bot

Creación del modo de lectura

Puedes considerar el modo lectura como una forma rápida de leer los artículos sin tener un lector RSS. Permite publicar el canal a modo de blog, con lo que se puede leer fácilmente las novedades

El modo lectura permite leer el feed sin necesidad de tener la app ni un lector de RSS. Tiene las funciones basicas de un Blog, pues es un prototipo de una idea que tuve de un sistema de blog ligero basado en telegram. Hay que explorar la idea, pero por el momento, sirve de lector de RSS serverside.

Propuesta: incrustar un feed completo en wordpress

Aprovechando el feed RSS de telegram, me ha parecido una idea interesante incrustar las diez ultimas entradas en un post. El widget nativo de wordpress para rss es feo, así que hice uno propio que puedes instalar como plugin o como fragmento de código en tu blog. Yo lo hice en mi pagina Canal de Telegram a modo de ejemplo que puedes revisar, con el fin de aprovechar las funciones de texto enriquecido del bot.

El objetivo de este feed es poder utilizar las imagenes de la etiqueta enclousure para mostrarlas en lugar de un feed de texto todo aburrido. Se podrian agregar mas estilos para que quede mas bonito, pero aqui esta el prototipo.

Ideas

Bloquear bots

Realmente el problema esta en que no se como lidiar con los canales con botoneras. Por el momento creo que deberia bloquear los contenidos creados por bots, pero conforme se use mas el bot podría ir aprendiendo que hacer. Por supuesto acepto sugerencias.

Eliminar medios antiguos

Debido a que no tengo espacio ilimitado, podria considerar borrar medios antiguos. Los post de telegram son principalmente texto asi que no se notaria demasiado, pero no se que hacer con los audios.

¿Algo de SEO?

Por el momento el sitio es compatible con metadescripciones, pero no se si este bien agregar algo de SEO. por el momento todo el sitio es SSR (Server Side Rendering)

Viernes 22 de agosto de 2025

• Agregado la pagina «read.php» para que los artículos de los canales puedan ser leídos sin necesidad de un lector RSS
• Actualizada la pagina de inicio para mostrar el modo lectura, aparte del enlace al feed RSS
• Agregado campos meta para vistas previas de hipervínculo en redes sociales (falta mejorar)
• Correcciones varias de estilos
• Creado el Snippet y prototipo de Plugin de wordpress miniblog_rss
• Actualizada la política de titulos del post
• Actualizada la política de reenviados
• Establecido la política de multimedia
• Información sobre la multimedia subida
•  

https://interlan.ec/2025/09/03/changelog-channel2rss-22-de-agosto-de-2025/

#bot #canalesDeTelegram #channel2rss #desarrolloDeBots #feed #rss #telegram

Nuevo proyecto para el portafolio: Channel2RSS

Introducción

Este bot es un proyecto rápido con el fin de probar por primera vez como funcionan los webhooks de Telegram e intentar demostrar que sirve para hacer un despliegue de bot mas rápido y sencillo que los que se hacen con Update. por supuesto, esto ultimo resulto un fracaso XD

Channel2RSS

La idea de este bot es sencilla; dotar de RSS a canales de Telegram. Por supuesto, no es el primero ni sera el ultimo, he probado al menos dos alternativas y he notado que, aparte de ser lentas, no piden permiso al autor para que este decida si quiere o no tener RSS en su canal. Simplemente usan un WebCrawler que reúne la información y la sirve como RSS para quien la quiera tener. Aunque esto me parece un poco injusto, tampoco es que se pueda hacer mucho. En Telegram se filtra muchísima información por bots y usuarios malintencionados, así que ofrecer un servicio de forma mas educada y considerada se me hacia algo lindo de intentar.

Características de Channel2RSS

Este bot trata de ser lo mas sencillo posible, basta que lo agregues a tu canal para que empiece a generar una URL con el XML de tu nuevo feed. Se ira llenando conforme vayas escribiendo en tu canal y se publicara en un formato tipo:

• Titulo: La fecha de publicación (a diferencia de los blogs, los post de Telegram no tienen titulo. Pertenecen a la categoría de Microblogging) Se obtiene el tipo de post del canal y se agrega parte del contenido del post
• Descripción: El contenido de tu post. esto puede ser obtenido de:
  • Texto: si el post solo es texto, se obtiene del texto del mensaje recibido desde la API
  • Caption: Si el post solo es audio, se obtiene del caption del audio.
  • Detalles del audio: Si el archivo de audio incluye metadata, se agrega tambienn

Como es un proyecto en desarrollo, por el momento solo guarda audios en formato mp3, como sugerencia de un Podcaster @avionesdepapel que consideraba que era una función importante para la comunidad que no había encontrado hasta el momento. Por esta razón, la prioridad es pulir esta función antes de continuar escalando el proyecto.

También recibí un post de parte de @surrealcloud hablando sobre mi bot en su canal aun antes de que empiece a escribir este post XD

Al usar Webhooks, la actualización de los feeds es inmediata. Es posible que muchos lectores de RSS noten esto al instante, pero otros, como FreshRSS no actualicen sino hasta cierto tiempo después de una actualización previa, imagino que para ahorrar recursos del servidor.

El bot tenia también como fin ser selfhosted. Sin embargo, no estoy muy seguro de como podría resultar esto. Todo bot de telegram esta diseñado para ser multiusuario, por lo que el despliegue de un bot para un solo usuario, puede ser un desperdicio enorme de recursos. En ese caso, tal vez debí optar por usar Update en lugar de WebHooks pero debido a que el XML debe estar en publico, esto habría complicado muchísimo el desarrollo.

Por supuesto, estoy abierto a sugerencias, dejare abierto los comentarios por si tienen ideas o sugerencias para el bot.

Sobre el despliegue de Channel2RSS

Realmente en si es un código bastante pequeño, pero puede resultar inesperadamente lioso de desplegar porque necesita algunos requisitos. En especial un hosting o VPS porque es necesario dejarlo en publico para que tenga sentido su existencia, asi que en resumen, se necesitan los siguientes pasos previos antes de poder recién poner el código en el directorio requerido.

• Crear un dominio o subdominio: Los feeds RSS deben estar alojados en un lugar publico para que los clientes puedan consultarlos.
  • Por supuesto, debes apuntar el dominio o subdominio a tu nuevo servidor.
• Crear host o virtual host: El servidor que va a atender las llamadas de la API o de los clientes.
• Crear certificado SSL para tu host: puedes comprarlo o firmarlo con Let’s Encrypt usando el certbot.
• Crear tu bot con el botFather: Necesitas el token, claro
  • Configurar el bot: Limita los permisos, Ponle un titulo, una descripción, si quieres, ponle la URL de tu hosting como botón de MiniAPP
  • Configurar el modo de escucha de tu bot: Puedes hacerlo según lo que explica la Telegram Bot Api Documentation. Puedes hacerlo usando CURL
• Definir el nombre de tu WebHook: Por supuesto que no lo vas a llamar index.php. Necesitas ponerte creativo, ponle un nombre difícil de adivinar, porque no querrás trafico indeseado estorbando en tu bot, no? Te recomiendo que generes un hash SHA para que sea difícil de adivinar y ponle un prefijo. Recuerda que esto es lo que usaras cuando configures la webhook en la explicación de abajo.
• Proteger los archivos sensibles: Temporalmente este bot guarda un log de texto en el mismo directorio de ejecución de tu webhook. también la base de datos en formato SQLite esta en el mismo directorio. No queremos que se divulgue la información allí contenida, por mucho que sea publica, así que debes configurar la seguridad en tu servidor. En mi caso, he compartido lo que agregue a mis configuraciones para NGINX.
• Y bueno, recién ahora puedes poner a funcionar el bot. sencillito 😀

Si, ya se que esto es un tostón, pero el hecho de tener que dejarlo en publico es lo que hace que hayan todos estos requisitos. Se podría haber hecho esto con Node y express, pero también seria un proceso largo que incluso necesitaría de un proxy inverso como nginx. Por eso estoy dudando tanto de dejarlo como un código listo para selfhosting. No puedo garantizar que no se fuguen datos sensibles si la persona que despliega el bot no sigue todos los pasos y requisitos de seguridad.

Configurar el WebHook es bastante fácil, solo debes hacer lo siguiente:

Mira como esta configuradas las webHook

curl https://api.telegram.org/bot<TUTOKEN>/getWebhookInfo

Configura la webhook para que llegue a tu url de destino

curl -X POST "https://api.telegram.org/bot<TUTOKEN>/setWebhook" -d "url=TUURL"

Configurar el bloqueo de archivos sensibles es sencillo usando Nginx

Información técnica

Esta es la tecnología utilizada para este bot:

• Servidor: PHP FPM 8.1 Nginx
• Base de datos: SQLite 3
• Lenguaje de Programación: PHP

¿Que mas? nada mas, como dije, aunque el despliegue es muy complejo, el código es muy sencillo.

Modo de uso

Lo que hace el bot

Cosas pendientes

Notas sobre el desarrollo

Este bot es un desarrollo rápido creado con el fin de utilizarse por podcasters de Telegram. Si bien hay otros servicios que ofrecen cosas similares, no utilizan el enfoque que he usado porque entre otras cosas:

Por el momento conozco 2 servicios que funcionan relativamente bien para ofrecer RSS a canales de Telegram, pero no piden permiso al dueño del canal. por supuesto, que mi bot lo pida no significa que los demás no puedan hacerlo. Si alguien usa mi bot para tener RSS, también puede que hayan otros servicios screappeando el canal para que alguien lea por RSS también

Adjunto los servicios que conozco

• ch2rss.fflow.net que pertenece al mismo creador de watchbot y dead man’s switch bot, dos de mis bots favoritos.
• Telegram RSS or JSON server algo mas lento en sus actualizaciones y con fallos eventuales.

No me he dado el gusto de estudiar como funcionan, pero a diferencia de mi proyecto, no usan bots para obtener los datos y pueden recolectar post bastante antiguos también.

Ultimas notas

Si bien el XML consume memoria en escala de kilobytes, los archivos de audio pueden consumir en escala de megas. Actualmente mi servidor solo cuenta con 25GB de disco duro, siendo solo 5GB mi espacio disponible actual. No se por cuanto tiempo puedo mantener este servicio aunque tampoco espero que lo use muchas personas. Pero si se diera el caso de que haya mucha gente dispuesta a usarla, probablemente necesite algo de apoyo para mantener el servicio.

De nuevo, validar que mi bot no se use para propósitos turbios también es complicado, asi que entre las mejoras programadas debería poner algo que disuada de usarlo irresponsablemente. No tengo idea de que podría ser.

Otra idea que tuve era la de crear un archivo HTML estático que consuma el Feed de tu canal, para que puedas usarlo a modo de blog estático que se actualiza con tus post de tu canal de Telegram, seria una alternativa ligera de blogging pero no se como podría llegar a ser y de nuevo, si mi servidor va a aguantar eso. Según yo, si, pero quien sabe.

https://interlan.ec/2025/08/15/desarrollo-de-bots-channel2rss/

#bot #channel2rss #nginx #rss #seguridad