--- title: Análise de Compatibilidade — Ecossistema m15o × runv.club date: 2026-07-02 summary: Quais dos 38 projetos m15o podem incrementar o runv.club, quais não, e por quê. tags: [m15o, runv, pubnix, smallweb, gemini, gopher, nex] flowerColor: "#d7e8ff" --- # Análise de Compatibilidade **Ecossistema m15o (small web) × runv.club (pubnix)** Quais dos 38 projetos m15o podem incrementar o runv, quais não, e por quê. Base: os resumos em **m15o/docs/**, os manifests de dependências (`go.mod` / PHP) e a arquitetura conhecida do runv-server. **Data:** 2026-07-02 · **Escopo:** 38 repositórios em m15o/ · **Autor upstream:** m15o (git.sr.ht / hg.sr.ht) --- ## Sumário 1. [Contexto e alinhamento](#1-contexto-e-alinhamento) 2. [Critérios de compatibilidade](#2-critérios-de-compatibilidade) 3. [Veredito geral (38 projetos)](#3-veredito-geral-38-projetos) 4. [Tier A — Incorporar já](#4-tier-a--incorporar-já) 5. [Tier B — Incorporar com infraestrutura extra](#5-tier-b--incorporar-com-infraestrutura-extra) 6. [Tier C — Não incorporar](#6-tier-c--não-incorporar) 7. [Todos podem ser compatíveis?](#7-todos-podem-ser-compatíveis) 8. [Roadmap recomendado](#8-roadmap-recomendado) 9. [Riscos e observações transversais](#9-riscos-e-observações-transversais) --- ## 1. Contexto e alinhamento **runv.club** é um **pubnix Debian** — um servidor Unix compartilhado acessado por **SSH (headless, sem ambiente gráfico)**. Serve conteúdo em três protocolos por usuário: **HTTP (Apache mod_userdir), Gopher e Gemini** (public_html / public_gopher / public_gemini), além de IRC (#runv). O código é **Python stdlib puro**, o estado vive em **arquivos JSON (não há banco SQL)**, e a experiência é a de uma comunidade tilde: comandos de terminal (runv-who, runv-finger, runv-bulletin, chat), geração estática e site bilíngue. **m15o** é o **ecossistema da “small web”**: 38 repositórios em torno de Gemini, Gopher e **Nex**, formatos de publicação em HTML puro (HTML Blog / HTML Journal), wikis estáticas, serviços de comunidade auto-hospedáveis e alguns experimentos de linguagens/editores. **Alinhamento filosófico: praticamente perfeito.** O m15o é, em grande parte, exatamente o “software de comunidade” que falta ao runv. Vários projetos são multi-protocolo (HTTP+Gemini+Gopher), que é justamente o modelo do runv. A compatibilidade, portanto, quase nunca é uma questão de **propósito** — é uma questão de **modelo de execução e footprint de infraestrutura**. --- ## 2. Critérios de compatibilidade Cada projeto foi avaliado por cinco eixos: 1. **Modelo de execução.** Serviço headless (roda em servidor via terminal/daemon) ou app gráfico (precisa de X11/display)? Um pubnix é acessado por SSH e **não tem display gráfico**; o sshd do runv inclusive **desativa X11 forwarding**. Apps SDL2/Lazarus não rodam como serviço. 2. **Runtime e footprint.** Go compila para **um binário estático** (fácil de instalar + systemd). PHP exige **PHP-FPM**; Node exige o runtime Node; C precisa de toolchain de build. 3. **Banco de dados.** O runv hoje **não usa SQL** — estado em JSON. Todos os serviços Go de comunidade usam **PostgreSQL** (github.com/lib/pq) e os PHP usam **MySQL**. Adotá-los **introduz um servidor de banco** — o principal custo operacional e a maior quebra de invariante. 4. **Multiusuário vs pessoal.** Serve toda a comunidade, é por-usuário, ou é config pessoal do autor? 5. **Redundância.** O runv já faz homepages, quota, diretório de membros, Gemini, Gopher e wiki estática. Projetos que **refazem o núcleo do runv** com outra stack tendem a conflitar em vez de incrementar. **Legenda dos tiers: A** Incorporar já (baixo custo, encaixe perfeito) · **B** Incorporar com infra extra (BD / LAMP / Node) · **C** Não incorporar (incompatível ou redundante) --- ## 3. Veredito geral (38 projetos) | **Projeto** | **O que é** | **Stack** | **Veredito** | |------------------|--------------------------------|------------------------|------------------------| | nex-pfm | Lib do protocolo Nex | Go | A — base do Nex | | nexd | Daemon Nex (porta 1900) | Go | A — 4º protocolo | | kinex | Gateway HTTP -> Nex | Go | A — Nex na web | | rex | Cliente Nex de terminal | ksh (1 linha) | A — vira comando | | the-neon-kiosk | Agregador de blogs/journals | Go (htmlb/htmlj) | A — descoberta | | ni | Wiki estática (gemtext) | Go | A — por usuário | | nini | Wiki estática (HTML) | Go | A — por usuário | | moka | Wiki client-side (1 HTML) | HTML/JS | A — no skel | | yon | Wiki/notas client-side | HTML/JS | A — no skel | | emacs.d | Config Emacs p/ small web | Emacs Lisp | A — config opcional | | gmi2html | Lib gemtext -> HTML | Go | A — bloco reutilizável | | htmlb | Parser de HTML Blog | Go | A — dep do kiosk | | htmlj | Parser de HTML Journal | Go | A — dep do kiosk | | midnight-pub | Pub social multi-protocolo | Go + PostgreSQL | B — flagship (BD) | | smol.pub | Journal multi-protocolo | Go + PostgreSQL | B — BD + autocert | | status | Microblog de status | Go + PostgreSQL | B — BD | | vpub | Fórum hierárquico | Go + PostgreSQL | B — BD (admin/admin!) | | owl-report | Leitor de feeds RSS/Atom | Go + PostgreSQL | B — BD | | riku | Backend de formulários | Go + PostgreSQL | B — BD | | feed | Parser RSS/Atom | Go | B — dep do owl-report | | opml | Parser de OPML | Go | B — dep do owl-report | | html-blog | Validador de HTML Blog | Go | B — nicho | | html-journal | Validador de HTML Journal | Go | B — nicho | | lipu.li | Wiki multiusuário | PHP + MySQL | B — LAMP | | mebo | Fórum | PHP + MySQL | B — LAMP (dup. vpub) | | piclog | Fotolog JPEG | PHP + MySQL | B — LAMP | | warp | Cliente Nex no browser | PHP | B — precisa PHP | | nexy | Proxy Nex -> Gemini | Node.js | B — runtime Node | | nspace | Ling. de máq. de registradores | C (terminal) | C — curio de terminal | | 15f | Ling. Forth + gráficos | C + SDL2 | C — gráfico (headless) | | bitters | Editor gráfico | C + SDL2 | C — gráfico | | grid | Editor gráfico (ACME) | C + SDL2 | C — gráfico | | tny | VM de 256 bytes gráfica | C + SDL2 | C — gráfico | | nova | Cliente Nex GUI | Pascal/Lazarus | C — desktop GUI | | dotfiles | Config FVWM/X11 pessoal | ksh/X11 | C — desktop | | ichi | Plataforma de homepages | Go + PostgreSQL + SFTP | C — duplica o runv | | nightfall-server | Servidor Gemini+HTTP | Go + autocert | C — redundante | | ichipedia | Enciclopédia estática | gemtext/HTML | C — conteúdo | **Contagem:** Tier A = 13 · Tier B = 15 · Tier C = 10. --- ## 4. Tier A — Incorporar já Encaixam no runv com pouco ou nenhum atrito: são binários Go únicos, arquivos estáticos ou ferramentas de terminal. Nenhum exige banco de dados. ### 4.1 Suíte Nex — um 4º protocolo para o runv O runv já serve Gopher e Gemini por usuário. Adicionar **Nex** é o incremento mais natural e barato: espelha o padrão existente e é 100% alinhado com a Nightfall City do m15o. - **nex-pfm** (Go, lib): base que lista diretórios e serve arquivos Nex. Entra como dependência de nexd/kinex. - **nexd** (Go, daemon :1900): binário único que depende só de nex-pfm. Poderia servir um **~/public_nex** por usuário, exatamente como public_gopher/public_gemini. Instalação: 1 binário + unit systemd. - **kinex** (Go): gateway HTTP->Nex, expõe Nex no navegador — como o runv já faz Gemini->web. - **rex** (ksh): cliente Nex de terminal. É literalmente echo $2 | nc $1 1900 | less. Vira um comando em tools/bin (como o **chat**), custo ~zero. ### 4.2 Descoberta e wikis estáticas — sem banco, ethos idêntico - **the-neon-kiosk** (Go, usa htmlb/htmlj): agrega blogs/journals HTML recentes. Apontado para os **public_html dos membros**, vira uma página de descoberta da comunidade — casa direto com o members.json e a geração estática do runv. Sem BD. - **ni** (gemtext->HTML) e **nini** (HTML->HTML): geradores de wiki estática com backlinks. Ótimos como ferramenta por-usuário (gera para o public_html/public_gemini). Sem BD. - **moka** e **yon**: wikis client-side em **um único arquivo HTML** (localStorage). Custo zero — basta servir o arquivo ou oferecê-lo no skel do novo usuário. - **emacs.d** (Emacs Lisp): config com modos para HTML Blog, gemtext, journal e cliente Gopher (elpher). **Emacs roda em terminal via SSH** — perfeito para pubnix. Oferecer como config opcional/skel. - **gmi2html / htmlb / htmlj** (Go, libs): blocos de construção reutilizáveis (conversão e parsing). Entram junto dos serviços/geradores que os usam. --- ## 5. Tier B — Incorporar com infraestrutura extra Alto valor de comunidade, mas cada um **introduz um banco de dados ou runtime novo**. Viável no Debian, porém quebra a invariante “estado em JSON, sem SQL” do runv. Recomendação: **padronizar PostgreSQL** (a maioria dos serviços Go usa lib/pq) e só entrar no mundo PHP/MySQL se realmente quiser os apps PHP. ### 5.1 Serviços Go (PostgreSQL) - **midnight-pub** — pub social **multi-protocolo HTTP/Gemini/Gopher**. É o candidato a flagship: o modelo multi-protocolo é idêntico ao do runv. Go + PostgreSQL + gmi2html. - **smol.pub** — journal **Web/Gemini/Gopher**. Excelente, mas sobrepõe parcialmente ao public_html/gemini/gopher que o membro já tem; e o **autocert dele disputa a porta 443/TLS** com o Apache/certbot atuais (usar subdomínio próprio). - **status** — microblog de status curtos (com badges PNG). Integra-se ao vpub. Go + PostgreSQL. - **vpub** — fórum hierárquico. **Atenção: cria admin/admin na 1ª execução** — trocar imediatamente. - **owl-report** — leitor de feeds self-hosted (usa as libs feed + opml). Go + PostgreSQL. - **riku** — backend de formulários HTML: complemento natural para os sites estáticos dos membros (formulário de contato sem serviço externo). Go + PostgreSQL. - **feed / opml** (Go, libs): entram só como dependências do owl-report. - **html-blog / html-journal** (Go): servidores que validam o formato e geram Atom. Nicho — o mais útil é adotar a **convenção de formato** nos public_html; rodar os validadores é opcional. ### 5.2 Apps PHP (MySQL) e outros runtimes - **lipu.li** — wiki multiusuário com backlinks (PHP + MySQL + PHPMailer). - **mebo** — fórum PHP. **Redundante com o vpub** — escolher um; não vale subir MySQL só por ele se já houver PostgreSQL. - **piclog** — fotolog JPEG com perfis e feed (PHP + MySQL). - **warp** — cliente Nex no browser (PHP, arquivo único). Leve, mas depende de PHP. - **nexy** — proxy Nex->Gemini (Node.js). Opcional; adiciona o runtime Node só para essa ponte. --- ## 6. Tier C — Não incorporar ### 6.1 Incompatíveis com um servidor headless (apps gráficos/desktop) Precisam de display gráfico. O runv é acessado por SSH sem X, e o sshd **desativa X11 forwarding** — logo não rodam como serviço. Fazem sentido **na máquina do próprio membro**, não no servidor compartilhado. - **15f** (C + SDL2) — linguagem Forth com gráficos. - **bitters** (C + SDL2) — editor gráfico estilo Canon Cat. - **grid** (C + SDL2) — editor gráfico estilo ACME. - **tny** (C + SDL2) — emulador gráfico de VM de 256 bytes. - **nova** (Pascal/Lazarus) — cliente Nex com GUI desktop. (Para Nex no servidor, use rex/kinex/warp.) - **dotfiles** (FVWM/X11) — config de window manager pessoal; nada a rodar num servidor headless (no máximo, aproveitar scripts shell soltos). ### 6.2 Redundantes ou conflitantes com o núcleo do runv - **ichi** (Go + PostgreSQL + SFTP): é, ele próprio, **uma plataforma de pubnix** — homepages por usuário, quota, índice, editor web. Adotá-lo inteiro seria manter **dois pubnixes concorrentes**. Serve de inspiração de features (editor web, índice), não de incremento drop-in. - **nightfall-server** (Go + autocert): servidor Gemini+HTTP. **Redundante com a stack atual** (Apache + Gemini + certbot); seria uma substituição, e o autocert conflita na 443. Não é incremento. - **ichipedia**: é **conteúdo** (enciclopédia gemtext do m15o), não software. Pode ser publicado como conteúdo, mas não “incrementa” o sistema. ### 6.3 Caso-limite - **nspace** (C, terminal): interpretador de linguagem de máquina de registradores. **Tecnicamente roda em terminal** (compila com cc), então é compatível como curiosidade/esolang — mas valor marginal para o pubnix. Só se quiser um brinquedo tipo runv-games. --- ## 7. “Todos podem ser compatíveis?” **Resposta honesta: a maioria sim, mas não todos — e o motivo é estrutural, não de vontade.** - **~28 projetos** são compatíveis como serviço ou ferramenta de servidor (Tiers A e B): o alinhamento small-web é perfeito; o único preço é infraestrutura (banco/PHP/Node) nos de Tier B. - **5 projetos gráficos** (15f, bitters, grid, tny, nova) **não podem** rodar num pubnix headless — dependem de SDL2/Lazarus e de um display. Isso é uma barreira de **modelo de execução**, não de licença ou stack. O caminho para “torná-los compatíveis” é oferecê-los como **código-fonte para o membro compilar na própria máquina**, não como serviço no runv. (X11 forwarding via SSH seria teoricamente possível, mas o runv o desativa por segurança.) - **dotfiles** é config de desktop pessoal — não “roda” em lugar nenhum do servidor. - **ichi e nightfall-server** rodariam tecnicamente, mas **duplicam/competem** com o núcleo do runv — compatíveis no papel, indesejáveis na prática. - **ichipedia** é conteúdo, não um componente de sistema. **Conclusão:** o ecossistema m15o é um encaixe raro para o runv. O trabalho real não é vencer incompatibilidade de propósito — é decidir **quanto de infraestrutura nova** (sobretudo um banco de dados) você aceita introduzir, e evitar duplicar o que o runv já faz. --- ## 8. Roadmap recomendado Da menor para a maior fricção: ### Fase 1 — Protocolo Nex (sem BD, espelha o que já existe) - Adotar **nex-pfm + nexd + kinex** e o comando **rex**. Servir **~/public_nex** por usuário, no mesmo molde de public_gopher/public_gemini; adicionar o backfill (como o yetgg.py já faz para Gopher/Gemini). ### Fase 2 — Descoberta e escrita estática (sem BD) - Adotar **the-neon-kiosk** (agrega os blogs/journals dos membros), **ni/nini** como ferramentas por-usuário, e distribuir **moka/yon** no skel. Oferecer o **emacs.d** como config opcional. ### Fase 3 — Serviços de comunidade (introduz PostgreSQL) - Decidir o banco padrão (recomendo **PostgreSQL**). Começar por um flagship multi-protocolo — **midnight-pub** ou **smol.pub** — depois **status + vpub** (que se integram) e **riku** (formulários para os sites dos membros). **owl-report** se quiser leitor de feeds. ### Fase 4 — Extras opcionais - Apps PHP (**lipu.li, piclog, warp**) só se aceitar um segundo stack (PHP/MySQL). Evitar **mebo** se já adotou o vpub. --- ## 9. Riscos e observações transversais - **Banco de dados quebra a invariante do runv.** Hoje todo o estado é JSON; qualquer serviço Tier B adiciona PostgreSQL/MySQL, com backup, migrações e hardening próprios. - **Conflitos de porta/TLS.** Serviços com go-gemini/go-gopher/autocert (midnight-pub, smol.pub, nightfall-server) disputam as portas 1965 (Gemini), 70 (Gopher) e 443 (TLS) com o molly-brown/gophernicus/Apache do runv. Rodar cada um atrás de **subdomínio + porta própria** ou reverse proxy. - **Segurança padrão.** vpub cria **admin/admin**; vários apps PHP usam ativação por e-mail (PHPMailer) — precisam de config SMTP alinhada com o e-mail transacional do runv. - **Build e origem.** Repos estão em **Git e Mercurial**; os serviços Go precisam do toolchain Go no servidor (ou build local + deploy do binário). Os PHP precisam de PHP-FPM. - **Não duplicar o núcleo.** ichi e nightfall-server refazem o que o runv já entrega; adotá-los cria manutenção redundante e confusão de modelo. - **Consistência de comunidade.** Ao adicionar serviços com login próprio (midnight-pub, vpub, status…), pensar em como se relacionam com a conta Unix do membro — SSO real dá trabalho; no mínimo, alinhar nomes de usuário. *Fim da análise.*