Lagrange is *seriously* impressive. Once I can sync bookmarks and certs easily between clients it'll be near perfect.

🍄 sam

2025-02-03 · 1 year ago · 👍 skyjake, clseibold, undefined

7 Comments ↓

🦂 zzo38 · 2025-02-03 at 23:51:

I had written my ideas of a file format to transfer bookmarks, client certificates, server certificates, and some other information, between different implementations. (No implementation of this exists as far as I know, but I might write a conversion program (both ways) if some programs use other formats)

— https://raw.githubusercontent.com/zzo38/scorpion/refs/heads/trunk/misc/certconfig.doc

🍀 gritty · 2025-02-04 at 00:35:

people have used syncthing

🚀 stack · 2025-02-04 at 01:22:

I can live with copying a few files by hand, in a pinch.

🌆 skyjake [...] · 2025-02-04 at 04:30:

Some kind of a sync system is near the top of the todo list. I'm "just" trying to figure out how to do it the right way, securely and efficiently without always requiring a central server component. Like any feature in Lagrange, the added implementation complexity needs to be justified by the provided utility. Doing something extremely sophisticated is unreasonable.

🐐 satch · 2025-02-05 at 06:15:

@skyjake here's a sync proposal:

Anyone can run a public server which provides a sync service to users. The server has some kind of endpoint which you can configure clients to use for sync. Server uses gemini and titan to send and receive updates.

File transfer can be end to end encrypted with a one time key transfer between devices during setup.

Is that too sophisticated for your liking? I have more thoughts on how this could be done well but I understand if you think it's overkill.

🌆 skyjake [...] · 2025-02-05 at 13:28:

@daruma @satch Ideally the sync system would work without any additional dependencies. Using Titan and Gemini requests would be ideal, I suppose.

Both self-hosted and public sync servers are justified. Especially in the latter case, encrypting all data stored on the server using a client-provided key seems mandatory. The server operator ideally wouldn't be able to access the clear data at all, for privacy and security. I have some thoughts how you'd do incremental sync updates and merges like this, but it starts getting complicated. Also remember, there is more data than just bookmarks and identities (navigation history == subscription read status, maybe open tabs, snippets, site settings, trusted server certs).

🐐 satch · 2025-02-05 at 17:33:

@skyjake we're thinking along the same lines here.

Each user has:

Data is encrypted using AES-GCM or XChaCha20-Poly1305 for better nonce security.

When a new device is added, the existing device shares the Master Key encrypted with the recipient device’s public key.

All the server needs is a way to associate different public keys from different devices with one set of data. It would be nice to avoid usernames but that's one simple solution.