Síntesis de cinco lentes: practitioner, académico, escéptico, economista e historiador. Panel de construcción propia con un mapa de contradicciones; investiga si merece la pena construir una interfaz web instalable (PWA) para Moode Audio servida desde la propia Raspberry Pi.
El hecho asentado: la arquitectura "PWA servida desde el propio Pi con HTTPS" es técnicamente viable y va a favor de los estándares — las direcciones IP privadas nunca serán "contexto seguro" por especificación, así que un certificado confiable en el Pi es el único camino real hacia una app instalable, y servir desde el Pi esquiva además el nuevo permiso de red local de Chrome. La interpretación en disputa: si la fricción del certificado es mortal o manejable. El escéptico sostiene que el diferencial (automatizar la CA privada) es a la vez el techo de adopción — Android muestra un aviso permanente de "la red puede estar supervisada" que Google no piensa quitar —, mientras el académico documenta que el riesgo real está exagerado (desde Android 7 solo el navegador confía en esas CAs) y el practitioner apunta la salida: que funcione perfecto sin instalar nada y el certificado sea mejora opcional. La tensión de fondo: Moode no ofrece un contrato estable — su "API" es informal, su tiempo real es long-polling PHP, y saca 1-2 versiones al mes — así que cada línea acoplada a Moode es deuda de mantenimiento perpetua. Construye la mejor UI que funcione desde el navegador sin instalar nada, con una capa adaptadora mínima hacia Moode, y vende el certificado como asistente opcional de "modo app": así el diferencial no es también el asesino.
Un "contexto seguro" es la condición que exige el navegador para dar superpoderes a una web (instalarse como app, usar service workers). La especificación del W3C solo considera seguros HTTPS confiable y localhost; las IP privadas tipo 192.168.x.x están explícitamente fuera y la propuesta de incluirlas lleva años estancada. Chrome incluso ha relajado los requisitos de instalación (ya no exige service worker con fetch desde Chrome 108), pero el requisito HTTPS permanece intacto. Bonus arquitectónico: el nuevo permiso "Local Network Access" de Chrome (141+) restringe peticiones desde internet hacia la red local — una app servida desde el propio Pi hace peticiones al mismo origen y esquiva esa fricción, lo que descarta definitivamente la alternativa "PWA hospedada en la nube".
No hay WebSocket: la UI oficial mantiene una petición AJAX abierta contra engine-mpd.php, un envoltorio PHP alrededor del comando idle de MPD que espera eventos de cambio. El resto es un REST "ligero" en command/ más un fichero de metadatos (currentsong.txt) que hay que activar a mano para carátulas. Y cuando un desarrollador preguntó en el foro si los comandos se mantendrían estables, Tim Curtis (creador de Moode) no lo garantizó: lo trata como función interna documentada, no como API versionada. Traducción: cualquier UI de terceros construye sobre arena que se mueve 1-2 veces al mes.
El matiz que decide el diseño del producto: instalar el certificado raíz en el almacén "de usuario" de Android sí hace que Chrome confíe en él para navegar (la PWA carga sin error y se puede instalar), pero el sistema muestra desde entonces la notificación persistente "la red puede estar supervisada", exige bloqueo de pantalla, y Google ha dicho que no hay planes de cambiarlo. Desde Android 14 el almacén del sistema quedó además blindado (inmodificable sin root). En Windows el camino pasa por la consola de certificados (MMC) — factible pero intimidante. Apple es la excepción dura: Safari rechaza en silencio certificados de más de 825 días e iOS nunca implementó la instalación estándar de PWAs.
Moode publicó ~9 versiones entre diciembre 2025 y junio 2026, con salto de sistema base incluido; ya hay precedente de actualizaciones que rompieron configuraciones de terceros (CamillaDSP). La historia del nicho apunta en la misma dirección: ympd murió y lo sustituyó myMPD (minúsculo, pegado al daemon); Cantata fue abandonado en 2022 y solo revivió porque alguien heredó el código; RuneAudio murió; Volumio se comercializó. El patrón del historiador: sobreviven la plataforma base o el cliente tan fino que aguanta los cambios del motor. Una UI gorda acoplada a los internos de Moode ocupa la posición históricamente más frágil.
No existe una cifra fiable de usuarios activos de Moode (las descargas reales no son públicas). Los datos de contorno existen — Raspberry Pi acumula ~61 millones de unidades, Volumio cobra 69,99 €/año por su capa premium y tiene clientes, BubbleUPnP vive de un desbloqueo único de 5,99 € — pero la intersección que importa ("usuario de Moode + insatisfecho con la UI oficial + dispuesto a instalar la app") nadie la ha medido. El escéptico añade que la UI oficial ya es responsive y se autodescribe como adaptada a móvil/tablet/TV. Este es el hallazgo más débil del informe y a la vez el más barato de convertir en dato: preguntar en el foro.
Es la tesis del historiador (patrón "feature experimental domesticada por un tercero → integrada por el núcleo", visto en temas de Kodi y dashboards de Home Assistant) y encaja con que la guía oficial de Moode ya menciona HTTPS para "guardar como app en Android". Pero es inferencia de patrón: Moode no ha anunciado nada. No la afirmes como hecho; úsala como restricción de diseño — que el valor del proyecto no dependa solo de domesticar el certificado.
Contradicción aparente: el académico demuestra que la CA privada es el único camino posible hacia la PWA instalable (las IP privadas nunca serán contexto seguro), el escéptico demuestra que ese mismo camino es el techo de adopción (aviso permanente de Android), y el historiador demuestra que, aunque funcione, es la pieza que el núcleo de Moode absorberá antes. El diferencial elegido es a la vez imprescindible, repelente y efímero.
La resolución solo se ve cruzando las cinco lentes: el certificado no puede ser la identidad del proyecto — tiene que ser una feature de bienvenida. El valor durable está en otro sitio: en ser el cliente fino y excelente (patrón myMPD) que funciona perfecto desde el navegador sin instalar nada, con una capa adaptadora mínima hacia los internos de Moode. Sobre esa base, el asistente de certificado ("actívame el modo app") es un regalo opcional que convierte a los entusiastas — y si un día Moode lo integra de serie, te quita trabajo en vez de matarte.
El diferencial no es domesticar el certificado: es ser la UI que no lo necesita para enamorar (y la tesis de absorción, recuérdalo, es inferencia con confianza 4/10).
Las cinco lentes congelaron la variable más importante: dieron por hecho que existe demanda de una UI alternativa y debatieron solo si es construible y sostenible. Nadie auditó el foro de moodeaudio.org buscando qué echan en falta los usuarios reales en la UI oficial, qué quejas de UX móvil se repiten, ni qué features reclamadas llevan años sin atenderse. La 6ª lente que falta es el usuario de Moode / investigador de UX — y no añadiría matiz: podría invertir las conclusiones.
Si esa lente descubriera que no hay demanda real (la UI oficial ya satisface), el proyecto es un ejercicio personal — legítimo, pero con otro alcance. Si descubriera una o dos features estrella reclamadas y desatendidas, el posicionamiento entero cambiaría: Play.Moode no sería "otra UI" sino "la que por fin hace X". Construye con esta incógnita abierta en mente — y ciérrala antes de escribir código serio.
Para Edu, antes de escribir la primera línea de la UI. Movimientos concretos, cada uno atado a un hallazgo.
Abre un hilo presentando el concepto (con un mockup, no con promesas), pregunta qué echan en falta en la UI oficial, y pregunta directamente a Tim Curtis su postura sobre UIs de terceros usando el REST API. Cierra el punto ciego del hallazgo 5 y de paso mides la relación con la plataforma — con el historial GPL de Moode, mejor llegar preguntando que redistribuyendo.
Prototipa solo el onboarding (generar CA en el Pi + página "instala tu certificado" con pasos por plataforma) y pruébalo con 3-5 usuarios no técnicos. Si la mayoría abandona ante el aviso de Android, el hallazgo 3 te dice el pivote: PWA "de navegador" primero e instalación como modo avanzado. Es la pregunta empírica que zanja la mayor contradicción del panel.
La instalabilidad es mejora progresiva, no requisito. Así el aviso de "red supervisada" (hallazgo 3) filtra solo a los entusiastas en vez de bloquear la puerta, iOS/Safari deja de ser un agujero en la promesa, y sobrevives al escenario en que Moode integre HTTPS de serie (señal disputada).
Habla con MPD (vía el long-polling del engine existente o el protocolo MPD) para lo universal — cola, biblioteca, playlists — y usa los comandos propios de Moode solo donde no haya alternativa (renderers, config de audio). Cuando llegue la release mensual (hallazgos 2 y 4), que solo pueda romperse el adaptador, no la app. Es el patrón de supervivencia de myMPD.
El catálogo de Tidal no es accesible para una UI de terceros; lo honesto es mostrar "qué está sonando" cuando el renderer UPnP/Tidal Connect está activo y no prometer navegación. Un v1 pequeño y pulido sobrevive a la cadencia de Moode; un v1 ambicioso nace roto.
El economista lo dijo claro: regalar esto es firmar una factura mensual de horas. Un bote de propinas tipo BubbleUPnP (5,99 € una vez) no te hará rico pero señaliza seriedad, y una prueba automática contra la imagen nueva de Moode convierte "¿se ha roto algo?" de tarde perdida en semáforo rojo/verde.
engine-mpd.php), documentado en sus propios docs.Es una sola pregunta con dos mitades porque las dos incógnitas se multiplican: sin demanda, la mejor ejecución técnica produce un repo muerto más en la categoría; con demanda pero con abandono masivo en el certificado, el proyecto vive pero su "diferencial" se degrada a feature de entusiastas. Ninguna lente la respondió porque no está en ninguna fuente: solo existe en el foro de Moode y en un prototipo de onboarding puesto delante de usuarios reales. Responderla cuesta una semana (un hilo en el foro + un asistente de certificado sin UI detrás) y decide todo lo demás: el alcance del v1, el posicionamiento frente a la UI oficial, y si el roast posterior recibe un proyecto o una hipótesis.