Sincronización y sin conexión

Qué le pasa a una pulsación

1. Tu pulsación cambia la pantalla, de inmediato y sin esperar a nada.
2. Se guarda en este dispositivo antes de enviar nada, así que una pestaña que muere antes de que el guardado llegue sigue teniéndola.
3. Se envía al servidor en cuanto la red lo permite, y allí se fusiona como una operación CRDT.

Hacer lo tercero antes que lo primero es un indicador de carga, y por eso van en ese orden. El segundo punto es el que conviene leer dos veces, y es más estrecho de lo que parece: lo que se guarda en este dispositivo es el texto que escribiste y que el servidor todavía no ha aceptado. Se reenvía al volver a abrir la pestaña y se borra en cuanto el servidor lo confirma.

Lo que no hace es convertir Fastpad en un editor que funcione entero sin red. Abrir una nota que no hayas abierto ya sigue necesitando conexión, y un navegador que rechaza el almacenamiento local — navegación privada, o una política que bloquea los datos del sitio — no tiene dónde poner la cola. En ese caso el editor lo dice en vez de tranquilizarte: el aviso de que no recargues la pestaña aparece justo cuando recargarla sí perdería trabajo.

En cualquier caso te lo dice. Un guardado que no ha llegado se nombra por lo que es — sin conexión, sesión terminada, nota eliminada, fallo del servidor — con qué hacer al respecto, y sigue intentándolo en vez de rendirse a los pocos segundos: la espera entre intentos crece, y volver a la pestaña o recuperar la conexión lo reanudan de inmediato. La única espera que no se acorta es la que pidió el propio servidor, porque él sabe algo que esta pestaña no sabe.

Dos personas, un párrafo

Las notas son CRDT, así que las ediciones concurrentes se fusionan sin bloqueo y sin pedirte que elijas un ganador. Dos personas escribiendo en la misma nota, o la misma persona en un portátil y un móvil, convergen al mismo documento llegue lo que llegue en el orden que llegue.

La estructura también se fusiona: reordenar bloques en un dispositivo mientras se editan en otro no produce un duplicado ni un bloque perdido, porque la identidad de un bloque es independiente de su posición.

Sin conexión

En la terminal, las ediciones y las capturas se encolan en un spool duradero en disco y se reenvían al reconectar, y el reenvío es idempotente por ambos lados: un cambio que el servidor confirmó justo antes de que perdieras cobertura se confirma en lugar de duplicarse.

fp capture nunca falla sin conexión: escribe en ese spool con una clave de idempotencia, sale con 7, y el siguiente comando que funcione lo vacía.

En la app web, una edición que haces con la conexión caída queda en este dispositivo y se reintenta con una espera creciente mientras la pestaña siga abierta, y se envía en cuanto vuelve la conexión: no hace falta que escribas otra vez para reanudarlo. La barra superior dice en cuál de los dos casos estás, porque una conexión caída y un cambio que el servidor rechazó tienen pronósticos opuestos.

El portátil que estuvo cerrado un año

El historial se compacta con el tiempo, acotado por lo que tus dispositivos han confirmado de verdad y no por un calendario. Un dispositivo que lleva mucho sin verse y vuelve con ediciones que ya no se pueden fusionar recibe una vía diseñada para ello, no un encogimiento de hombros.

Su trabajo se convierte en una nota nueva titulada «Unmerged offline edits from <dispositivo>, <fecha>», con todo lo que se haya podido recuperar. Lo que nunca ocurre es que las ediciones se descarten mientras la sincronización informa de éxito.