El patrón del cuaderno de notas: el fichero en tu disco como fuente de verdad
El extremo más puro del ideal de longevidad: ficheros de texto en el disco del usuario, formato abierto y publicado, y una sincronización opcional, de pago y con sus límites documentados por escrito.
De todos los casos de este nivel, este es el único donde la respuesta a dónde está la fuente de verdad no requiere ningún matiz: está en una carpeta de tu disco, son ficheros de texto, puedes abrirlos con cualquier editor y la aplicación puede desaparecer mañana sin que pierdas nada. Lo interesante no es la arquitectura, que es casi trivial, sino lo que esa decisión arrastra consigo: obliga a publicar los formatos, convierte la sincronización en un producto separado que hay que vender aparte, cambia el modelo de negocio de retener datos a merecer suscripción, y —esto es lo que lo hace un caso de estudio y no un manifiesto— obliga a documentar por escrito qué partes del sistema no pueden protegerse, porque el usuario tiene la información suficiente para comprobarlo por su cuenta.
- Analizar el patrón de fichero en disco como fuente de verdad y qué exige del formato.
- Entender por qué la longevidad es una propiedad del formato y no de la aplicación.
- Estudiar la sincronización como producto separado, opcional y de pago, y su modelo de confianza.
- Leer con atención los límites que un producto de este tipo se ve obligado a documentar.
La bóveda es una carpeta y nada más
El punto de partida es tan simple que cuesta reconocerlo como arquitectura. Un espacio de trabajo es un directorio del sistema de ficheros, y cada nota es un fichero. La documentación de Obsidian enumera los tipos aceptados sin ambigüedad: Markdown con extensión .md, un formato de bases con extensión .base, lienzos en JSON Canvas con extensión .canvas, más imágenes, audio, vídeo y PDF; y añade que la aplicación puede extenderse a otros formatos mediante complementos de la comunidad. No hay base de datos propietaria, no hay índice que sea la verdad y no hay un servidor que tenga que estar de acuerdo.
De ahí se derivan tres consecuencias que en cualquier otra arquitectura serían objetivos ambiciosos y aquí salen gratis. La aplicación funciona sin conexión porque nunca la necesitó. Las herramientas del sistema —búsqueda, control de versiones, copias de seguridad, guiones de línea de órdenes— operan sobre los datos sin que nadie construya una integración. Y la exportación deja de ser una funcionalidad, porque no hay nada de lo que exportar: los ficheros ya están fuera.
La diferencia con una aplicación de escritorio clásica no está en dónde viven los datos sino en si el formato está publicado. Un procesador de textos de 1995 también guardaba en tu disco, y sus ficheros son hoy en buena medida ilegibles porque el formato era un vertido de estructuras internas que nadie documentó. El patrón que estudiamos aquí solo se sostiene si el formato es texto plano o una especificación publicada. Es el mismo eje de acceso frente a propiedad del nivel 4, con la publicación del formato como bisagra.
Fichero antes que aplicación
Este patrón tiene una formulación explícita y firmada. Steph Ango, que es director ejecutivo de la empresa que hace Obsidian, publicó en julio de 2023 un texto breve titulado File over app cuya tesis cabe en una línea: si quieres crear artefactos digitales que duren, tienen que ser ficheros que controles, en formatos fáciles de recuperar y leer. El texto se presenta como dos cosas a la vez, una filosofía para quien crea y una petición a quien fabrica herramientas: acepta que todo software es efímero y da a la gente la propiedad de sus datos.
La frase del texto que mejor resume el argumento técnico es esta: para que lo que escribes siga siendo legible en un ordenador de 2060 o de 2160, es importante que tus notas puedan leerse en un ordenador de 1960. No es una boutade nostálgica; es un criterio operativo de selección de formato. Un formato que un sistema de hace sesenta años podría interpretar es un formato sin dependencias ocultas, sin marco de ejecución, sin esquema binario versionado y sin biblioteca que mantener. El propio autor cierra el texto reconociendo que la aplicación que él ayuda a fabricar acabará siendo obsoleta y que lo diseñado para durar son los ficheros de texto plano, no el programa.
La coherencia de esa postura se puede comprobar, y ese es el motivo por el que entra en este nivel. Cuando el producto necesitó un formato para lienzos infinitos, en lugar de inventarse un contenedor interno publicó JSON Canvas: una especificación abierta con su propio sitio, extensión .canvas, licencia MIT y repositorio público, presentada explícitamente como formato de importación, exportación y almacenamiento para cualquier herramienta, incluida la competencia. Un formato abierto que tu rival puede adoptar sin pedirte permiso es una renuncia deliberada a un foso defensivo, y es la clase de decisión que distingue una postura de una campaña de marketing.
flowchart TD U[Usuario] --> C[Carpeta en el disco] C --> MD[Ficheros markdown] C --> CV[Ficheros canvas con formato publicado] C --> AD[Adjuntos e imagenes] C --> APP[Aplicacion de notas] C --> OTR[Cualquier otra herramienta] C --> GIT[Control de versiones o copia de seguridad] SYNC[Servicio de sincronizacion opcional] -.-> C style C fill:#a6e3a1,color:#11111b style SYNC fill:#f9e2af,color:#11111b
La sincronización como producto aparte
Al poner el fichero en el centro, la sincronización deja de ser infraestructura obligatoria y pasa a ser una funcionalidad vendible, y la empresa la vende: un plan estándar por cuatro dólares al mes con facturación anual —cinco si se paga mes a mes—, con una bóveda remota, un gigabyte de almacenamiento, cinco megabytes de tamaño máximo por fichero y un mes de historial de versiones; y un plan superior por ocho o diez dólares con diez bóvedas, diez gigabytes ampliables, doscientos megabytes por fichero y doce meses de historial. Hay sincronización selectiva por tipo de fichero, exclusión de carpetas, restauración de ficheros borrados y bóvedas compartidas para equipos.
Lo que hace interesante este esquema no son las cifras sino la inversión del incentivo. En el modelo habitual, la empresa custodia tus datos y tu suscripción compra el acceso a ellos; dejar de pagar es perderlos. Aquí tus datos están en tu disco tanto si pagas como si no, y lo que compras es la comodidad de que aparezcan también en el otro dispositivo. La consecuencia es que el producto tiene que ganarse la renovación cada mes con calidad, porque el coste de marcharse es copiar una carpeta. Que un negocio pueda sostenerse así es la evidencia empírica más útil de todo este nivel: el modelo de retención por datos secuestrados no es el único que financia software.
Formato publicado
Markdown en texto plano y una especificación abierta con licencia MIT para los lienzos. Sin foso defensivo en el formato.
Sincronización de pago
Opcional, por suscripción, con planes por almacenamiento e historial. Se compra comodidad, no acceso a lo propio.
Cifrado extremo a extremo
AES-256 en modo GCM y derivación de clave con scrypt y sal. Es la opción por defecto al crear la bóveda remota.
Límites documentados
Hay metadatos que el servidor necesita leer para enrutar, y la empresa publica cuáles son y qué se puede hacer con ellos.
Los límites que la propia empresa publica
Esta es la parte por la que merecía la pena traer el caso, y la que casi nunca aparece en las comparativas. La documentación describe dos modalidades al crear una bóveda remota: cifrado extremo a extremo, que es la predeterminada y exige que el usuario custodie su contraseña —si la pierde, los datos remotos quedan cifrados para siempre y la empresa declara que no puede recuperarlos—, y un cifrado estándar con clave gestionada por la empresa, que compara de forma explícita con el modelo de los servicios en la nube habituales y del que dice con todas las letras que puede usarse para descifrar, por ejemplo ante una orden judicial. También aclara algo que muchos usuarios asumen mal: la bóveda local no está cifrada, solo lo está la remota y el tránsito.
Y luego está la sección titulada Limitaciones, que documenta dos concesiones deliberadas. La primera: los resúmenes criptográficos de los ficheros se cifran de forma determinista, de modo que el mismo contenido con la misma clave y sal produce siempre el mismo valor en el servidor. Eso permite detectar duplicados y no volver a subir ni almacenar lo idéntico, lo cual ahorra ancho de banda y espacio sobre todo en el historial de versiones; y a cambio abre un ataque concreto que la propia documentación describe: si alguien compromete el servidor y además tiene forma de inducir al usuario a subir ficheros elegidos por él, puede determinar si un fichero coincide con otro subido antes.
La segunda es más profunda: no hay vínculo criptográfico entre la ruta y el contenido. Qué dispositivo subió o borró un fichero, cuándo, y la correspondencia entre rutas cifradas y contenidos cifrados son datos que el servidor necesita poder leer para enrutar los cambios, calcular el historial de versiones y mantener los dispositivos al día. La consecuencia que la empresa enuncia sin adornos es que un servidor comprometido podría manipular esa correspondencia y entregar el contenido de un fichero bajo la ruta de otro. El texto en claro sigue protegido; la integridad estructural de la bóveda, no del todo.
Cifrado extremo a extremo describe qué le ocurre al contenido, no al conjunto del sistema. En cuanto un servicio tiene que enrutar, deduplicar, versionar o sincronizar de forma incremental, necesita leer algo, y ese algo son casi siempre los metadatos: quién, cuándo, qué tamaño, qué correspondencia. Cuando evalúes un producto que se sincroniza cifrado, la pregunta útil no es si usa cifrado extremo a extremo sino qué necesita leer el servidor para hacer su trabajo, y si la empresa ha sido capaz de escribirlo. Que aquí esté escrito no significa que el sistema sea peor que sus competidores; probablemente significa lo contrario.
Detrás de este caso hay un argumento que trasciende las notas personales y que conviene extraer con cuidado, porque contradice la intuición con la que casi todo el mundo evalúa herramientas. Cuando alguien se pregunta si puede confiar sus veinte años de escritura a un producto, la pregunta que suele hacerse es sobre intenciones y solvencia: si la empresa parece seria, si tiene financiación, si su política de privacidad es decente, si el equipo inspira confianza. Y todas esas preguntas, siendo razonables, comparten un defecto fatal: son predicciones sobre el futuro de una organización, y las organizaciones cambian de dueño, de dirección y de modelo de negocio con una frecuencia que ninguna promesa sobrevive. La pregunta que sí es contestable en el presente es de otra naturaleza: qué es lo que esta empresa ya no puede hacerme aunque quisiera. Si mis ficheros están en mi disco en un formato publicado, la respuesta es larga y tranquilizadora —no puede subir el precio del acceso, no puede cerrar y llevárselos, no puede cambiar los términos y dejarme sin salida, no puede degradar la exportación, no puede impedir que otro programa los lea— y ninguna de esas garantías depende de que siga siendo la empresa amable que es hoy. Depende de una decisión de arquitectura que ya está tomada y que sería costosísimo revertir sin que todos sus usuarios lo notaran al instante. Eso es lo que convierte este caso en el extremo puro del ideal de longevidad del nivel 1: no ha resuelto la longevidad prometiendo mejor, la ha resuelto quitándose la capacidad de incumplir. Y de ahí sale el criterio práctico más transferible de la lección, que puedes aplicar mañana a cualquier herramienta que estés evaluando o construyendo: mide la confianza en poder retirado, no en compromiso declarado. ¿Está el formato publicado bajo una licencia que sobreviva a la empresa? ¿Funciona el producto completo sin la parte de pago? ¿Puede un tercero escribir un lector sin permiso? ¿Está documentado por escrito lo que el servidor necesita leer? Cada respuesta afirmativa es un grado de libertad que ya no te pueden quitar, y la suma de esos grados es una medida mucho mejor de la longevidad que cualquier declaración de principios. Advierte, para terminar, que este patrón tiene un coste que no hemos escondido y que las cuatro lecciones restantes de este nivel se encargan de subrayar: el fichero en disco resuelve la propiedad y la durabilidad de maravilla, y resuelve la colaboración concurrente rematadamente mal, porque dos personas editando la misma nota a la vez sobre un sistema de ficheros es exactamente el problema que los tres niveles de estructuras convergentes venían a resolver. La pureza tiene un precio y el precio es que este patrón sirve para cuadernos y no para talleres.
- Elige la herramienta donde guardas el trabajo que más te dolería perder y localiza en qué formato está realmente almacenado, no en qué formato lo exporta.
- Comprueba si ese formato tiene una especificación publicada y bajo qué licencia, y si existe al menos un lector independiente que no sea de la misma empresa.
- Determina qué deja de funcionar exactamente si dejas de pagar mañana, y distingue entre perder comodidad y perder acceso.
- Busca en su documentación la sección de límites o de metadatos no cifrados; si no existe, anota esa ausencia como un dato en sí mismo.
- Simula la marcha: copia todo a otra herramienta y cronometra el proceso, apuntando qué se pierde por el camino y qué no se puede recuperar.
- Aplica el mismo cuestionario a algo que tú estés construyendo y escribe la lista de cosas que tus usuarios ya no podrían perder por tu culpa aunque quisieras.