2026-11-12 - Lagrange 2: End-to-End Encrypted Sync for the Small Web
Introduction
On 6 November 2026 Jaakko Keränen, known as skyjake, announced Lagrange 2, the new major version of his client for the Gemini protocol. The project turned six in September, and this release addresses its most practical limitation: until now, every device had its own bookmarks, identities and feed subscriptions, and keeping them aligned meant exporting and importing data by hand.
Lagrange 2 solves this with user data sync across devices. What makes it interesting from a data protection perspective is not the feature itself, which every web browser has had for years, but the way it has been designed: no account, no password, no email address, and data encrypted on the device before it leaves it. The question it raises is a familiar one: what does the operator of the service actually see?
First, though, a question that deserves an answer: why use Gemini at all?
Why Gemini: the Advantages over the Web
Gemini is a lightweight internet protocol, born in 2019, that sits between the old Gopher and the modern web. It does not try to replace the web; it offers a different place to publish and read. Its history and features are described in
; here it is enough to recall why it matters.
It limits common forms of web tracking by design. A Gemini request is a single line containing the address of the page. There are no headers, so no cookies, no user agent and no referrer; pages cannot run code in the client, and the protocol gives them no means to load third-party resources on their own, so no tracking pixels, external fonts or analytics scripts. This does not make the reader invisible: a server can still log the IP address and the pages requested, and recognise a client certificate that is reused. But the tools on which most web tracking relies are simply not part of the protocol.
Encryption is mandatory. Every Gemini connection uses TLS. There is no unencrypted version to fall back to.
Identity belongs to the user. When a site needs to recognise a reader, for instance to post on a forum, the reader presents a client certificate created on their own device. No account on a third-party platform, no password stored by others, no email address to hand over, and a different identity for each site if desired.
The reader controls the presentation. Gemtext describes only the structure of a text; fonts, colours and layout are chosen by the client. There are no pop-ups, cookie banners or advertising, because the format has no way to express them. Pages weigh a few kilobytes and remain readable on old hardware or in a terminal.
Gemini has real limits, and they should be stated clearly: the community is small (in November 2026 the Lupa crawler counted about 3,000 recently reachable capsules), a dedicated client is needed, and the format deliberately excludes inline images, tables and rich formatting. It is not a replacement for the web, but an alternative for reading and writing in a quieter and more respectful space. A good client is what makes that space usable every day, and this is where Lagrange comes in.
What Is New in Lagrange 2
Lagrange runs on macOS, Windows, Linux (also in the terminal), iOS, iPadOS and Android, and can be tried directly in a browser at
. On iOS, the App Store currently offers version 1.21, while version 2.0 is available through TestFlight.
Besides sync, version 2 brings:
- a paginated view that behaves like an e-reader, with up to four columns on wide screens;
- a bookshelf for Gempub books, the Gemtext-based ebook format, with reading positions kept across devices;
- subscriptions to Tinylog feeds, a minimal form of microblogging on Gemini;
- a dedicated reader tab for feed entries;
- support for system fonts and colour Emoji, a refreshed interface and faster document layout;
- ECDSA and Ed25519 client certificates, with ECDSA as the new default.
How Sync Works
According to the release announcement, the design rests on four elements.
The Sync Identity. There is no account to create. Sync relies on a self-signed Ed25519 client certificate, the Sync Identity, which must be present on every device that shares the same data. The sync server uses TLS 1.3, so the certificate itself travels encrypted.
Encryption on the device. The private key of the Sync Identity is used to derive a symmetric key, and the data are encrypted locally with AES-256-GCM before being uploaded. The server receives and stores only encrypted blobs: it cannot read their content, nor merge or reorganise them. Merging happens on each device, after decryption.
What is synchronised. Two kinds of encrypted data are uploaded: a full export of the user data (bookmarks, identities, subscriptions, settings, bookshelf) whenever something changes, and a short list of the pages visited in the last couple of days, used to keep track of which feed entries have been read, uploaded every few minutes. The other devices check the server at a configurable interval.
Which server. By default, Lagrange uses the public server run by its author. Alternatively, the server software, lgrsyncd, is part of the Lagrange source code and can be compiled and run on one’s own machine. A self-hosted server can be configured to accept only specific client certificates.
A Data Protection Reading
When an individual uses Lagrange to sync their own reading, the GDPR does not apply to that use: it falls within the exemption for purely personal or household activities (Article 2(2)(c)). The position of whoever runs the sync server is a separate matter, to be assessed on its own, especially with regard to the connection metadata it processes. Here the GDPR is used for something else: as a lens to read the design choices, because Articles 25 and 32 describe quite precisely what Lagrange does.
Data minimisation starts at sign-up. There is no sign-up. No email address, no name, no password: the server knows a certificate and some encrypted blobs. This is what data protection by design and by default (Article 25) looks like in practice: the data that is not collected cannot be lost, misused or requested by anyone.
End-to-end encryption as a security measure. Encrypting on the device with a key that never leaves the user’s devices is the kind of measure Article 32 has in mind. The operator of the server holds data it cannot read, and a breach of the server would expose only ciphertext.
What encryption does not hide. The server still sees metadata: the IP address of each connection, the time of each synchronisation, the size of the blobs, and the fact that several devices use the same identity. These are limited data, but they are not nothing. Those who want to remove the third party entirely can run their own server.
No recovery means no back door. If the private key of the Sync Identity is lost, the data on the server can no longer be decrypted, by anyone. This is the price of real end-to-end encryption, and in my view it is the right one. The risk is mitigated by the fact that each device keeps a full local copy, so a new identity can be created and all devices moved to it. The key, however, must be transferred between devices with care, for example through a password manager or an encrypted file, never in clear through an ordinary messaging app.
Storage limitation. According to the announcement, the server eventually deletes accounts that have not been accessed for a long time, so stale encrypted blobs do not accumulate indefinitely.
There is also a more theoretical question, which I leave open. In EDPS v SRB (C-413/23 P, 4 September 2025), a case concerning pseudonymisation under Regulation (EU) 2018/1725, the Court of Justice held that pseudonymised data are not necessarily personal data for a recipient who has no reasonable means of re-identifying the persons concerned. The judgment concerns pseudonymisation, not encryption, and its transposition is anything but automatic. It does raise a question, though: for the operator of a sync server who never holds the key, are the encrypted blobs still personal data? The answer matters for anyone who designs services along these lines, and it deserves a careful analysis of its own.
Setting It Up in Brief
- Back up first. Before upgrading from version 1, export the user data from the app; downgrading after the upgrade is not recommended.
- Open the Sync page in the preferences, create the Sync Identity, and choose the server: the public one or your own.
- Move the identity to the other devices securely, and select the same server on each of them.
- Check the interval at which each device looks for updates.
From that moment on, a bookmark saved on the phone appears on the laptop, and a feed entry read on one device is marked as read on the others.
Limits
- On iOS, version 2 is still in TestFlight; the App Store version does not yet include sync.
- With the public server, connection metadata remain visible to its operator.
- Lagrange is essentially the work of a single developer: a strength for coherence of design, a risk for long-term continuity.
Conclusion
Lagrange 2 shows that privacy by design is not an abstract principle reserved for large organisations with dedicated teams. It can sync bookmarks without asking for an email address or a password. The server can see connection metadata, while the synced content is encrypted on the user’s devices. In my view, many commercial products that ask for an email address, a phone number and a password to synchronise a few bookmarks have no technical reason to do otherwise.
For those curious about Gemini, Lagrange 2 makes the protocol comfortable to use every day, on every device. My capsule, a mirror of this blog in English and Italian, is at gemini://nicfab.eu, and every article on this site links to its Gemini version.
References and Further Reading
Lagrange 2 - release announcement by skyjake (6 November 2026)
Lagrange v2.0.0 - release notes
Lagrange - README and source code
GDPR - Regulation (EU) 2016/679
Court of Justice, Case C-413/23 P, EDPS v SRB
Gemini Protocol: A Human-Centric Alternative to the AI-Driven Web
- Lupa, statistics on Geminispace (November 2026): gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi
New to Gemini? This capsule is best read with a Gemini client, such as Lagrange.