Easy to read and analyze changelog of what has changed during sync

[helgek]

Scope

• I'm sure that this feature request belongs here and not into Discussions.

Description

Hi,

I started using palm os as my first back in high school pim device 28 years ago and one thing unfortunately never improved since then: sync transparency.

With this I mean transparency in the form of an easy to consume chronological log that would allow me to trace all the changes performed during sync on my contacts, calendar entries, and so on.

I'm explicitly not talking about something like verbose logging, I'm talking about a continuously updated sync history logbook in which I can see e.g. for each contact which fields were changed and what the content was for a contact/contact field before and after. Even better: a time machine, allowing to "fly" through the history of a contact, calendar, and so on entry.

Why such a feature is so crucial: Despite digital pims with sync capabilities being available now for several decades it still is inferior to paper (or even stone) based pim with respect to integrity of my data. Until today I have no certainty that e.g. the contact data of a very interesting person I've just met and been noting down their contact information into my digital address book will still be available to me one year later. Because I have no transparency of what happened during the syncs with multiple end points involved. I have no transparency of any wrongly initiated deletion of a contact entry or part of a contact dataset due to a sync error. The only way to find out would be to keep regular backups and do a cumbersome manual comparison of backed up datasets.

You could really add a huge paradigm shift here and easily outperform any other player in this field who has implemented pim synch technology in the past by simply adding a logbook in the form described above.

I'm totally aware that even with such a feature added to DAVx a 100 percent persistence guarantee like you have it with stone engraved information will not be achievable due to nature of digitally based technologies, but it would be a huge step forward to come much closer to this.

IMO especially Apple, Google and all the other big stakeholders of digital pims in this regard have been a total failure in this regard by not showing any respect and sensitivity to the importance of integrity of personal information, ensuring a similar information ownership and integrity level like I would have if I would keep maintaining my contacts in a non digital form.

Thank you.

Further info

No response

[devvv4ever]

Hi helgek,

Thanks for the idea which would definitely be useful!

Right now we need to put our (very limited) dev power into re-newing the core of DAVx5, so it's not the right time for features but once we refactor our logging and error processing parts we'll have in mind to add some better possibility for users to see what's going on within the sync process.

[helgek]

@devvv4ever Thank you for following-up on my proposal and reflecting my proposal, very much appreciated!

@buggymcbugfix Thank you for your great response and coming up with such great ideas how to take this forward in a very concrete way!

You definitely have a point here when you refer to the server-side logging and in my case I would also be willing to invest some energy into a self-hosted server setup (or pay for sync server with additional capabilities). And certainly it would great and desirable that available server solutions (both self-hosted and not self-hosted) would evolve into the direction I described in my initial post. Realistically though I would assume that a majority of DAVx5 users would run their syncs against servers which they don't have under their own control. Also a majority (just guessing) of users would not be able or willing to invest into setting up their own sync server.

So eventually I think such a sync transparency feature would be well justified for both the server side and the client side. Of course the server will always be superior regarding the completeness of sync history. Theoretically (and also practically) situations could occur where the DAVx5 client(s) would not sync with the server for some time and while they are sync-absent (an)other non-DAVx5 client(s) could perform multiple changes with the server about which the DAVx5 client(s) then would never get to know about. Also of course any data integrity affecting sync errors between server and non-DAVx5 client(s) would possibly never come to the knowledge of the DAVx5 client(s).

But I think even with such remaining possible scenarios of an incomplete sync history on the client side a sync transparency feature on the DAVx5 side would only lose very little of it's overall justification. I believe that overall, despite the aforementioned remaining client-related limitations, a continued and easy to review sync history on the client side would still be a major evolution and huge step into the direction of ensuring sovereignty over personal data in the digital space (in the sense of data integrity as also described in my initial post), and I assume it would be an unprecedented feature that was not provided by any other solution so far.

PS: While writing I remembered that a few years back I had tried my luck with SyncML based sync clients from Synthesis and I also had been in touch with the developer of the software multiple times. But unfortunately I wasn't happy with the sync reliability and performance (despite a long changelog history).
On the server side I had put big hopes into https://www.memotoo.com/ - a long time available "jack of all trades" tool (unfortunately not anymore maintained), which probably, to date, has been the most impressive server side solution, promoting and supporting the idea of personal data ownership and integrity, while being open to many different sync protocols.
Currently I use DAVx5 with iCloud because I'm using Android, Mac and iOS devices.

[buggymcbugfix]

Server-side seems like the right place to log diffs rather than doing this on the clients. If you are willing to self-host, you might be in luck — Radicale + git can give you pretty much exactly what you want: https://radicale.org/v3.html#versioning-collections-with-git

It was a walk in the park to set up Radicale on NixOS with merely a few lines of config. I haven't tried setting up version control like described above, but consider me nerd-sniped. Once I get round to it, I'll report back here.

There you go, one more reason to self-host :)

[buggymcbugfix]

I did it! All I had to do was run git init in the Radicale directory and add this to my config:
storage.hook = ''${git} add -A && (${git} diff --cached --quiet || ${git} commit -m "Changes by \"%(user)s\"")'';

This commit is created when I add some test event on my phone:

commit 443b15b1c3d288d0075f01008dd0e3f1e07d8948 (HEAD -> master)
Author: radicale <radicale@liepelt.design>
Date:   Thu Jan 22 01:22:08 2026 +0100

    Changes by "family"

diff --git a/collection-root/family/vil/63befe9a-f73b-4bd0-bc0d-34d67a884e2b.ics b/collection-root/family/vil/63befe9a-f73b-4bd0-bc0d-34d67a884e2b.ics
new file mode 100644
index 0000000..f6862a9
--- /dev/null
+++ b/collection-root/family/vil/63befe9a-f73b-4bd0-bc0d-34d67a884e2b.ics
@@ -0,0 +1,36 @@
+BEGIN:VCALENDAR^M
+VERSION:2.0^M
+PRODID:AccountManager/4.3.10-ose+20250424115547 ical4j/3.2.13 (foundation.e^M
+ .calendar)^M
+BEGIN:VTIMEZONE^M
+TZID:Europe/Berlin^M
+LAST-MODIFIED:20230104T023643Z^M
+BEGIN:STANDARD^M
+DTSTART:19961027T030000^M
+RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU^M
+TZNAME:CET^M
+TZOFFSETFROM:+0200^M
+TZOFFSETTO:+0100^M
+END:STANDARD^M
+BEGIN:DAYLIGHT^M
+DTSTART:19810329T020000^M
+RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU^M
+TZNAME:CEST^M
+TZOFFSETFROM:+0100^M
+TZOFFSETTO:+0200^M
+END:DAYLIGHT^M
+END:VTIMEZONE^M
+BEGIN:VEVENT^M
+UID:63befe9a-f73b-4bd0-bc0d-34d67a884e2b^M
+DTSTART;TZID=Europe/Berlin:20260401T000000^M
+DTEND;TZID=Europe/Berlin:20260401T010000^M
+DTSTAMP:20260122T002207Z^M
+STATUS:CONFIRMED^M
+SUMMARY:test^M
+BEGIN:VALARM^M
+ACTION:DISPLAY^M
+DESCRIPTION:test^M
+TRIGGER:-PT10M^M
+END:VALARM^M
+END:VEVENT^M
+END:VCALENDAR^M

... and after I change the time of the event I get another commit:

commit 0508d1873d038d575d96a0c8ff2914c5e1925f74 (HEAD -> master)
Author: radicale <radicale@liepelt.design>
Date:   Thu Jan 22 01:23:18 2026 +0100

    Changes by "family"

diff --git a/collection-root/family/vil/63befe9a-f73b-4bd0-bc0d-34d67a884e2b.ics b/collection-root/family/vil/63befe9a-f73b-4bd0-bc0d-34d67a884e2b.ics
index f6862a9..114e288 100644
--- a/collection-root/family/vil/63befe9a-f73b-4bd0-bc0d-34d67a884e2b.ics
+++ b/collection-root/family/vil/63befe9a-f73b-4bd0-bc0d-34d67a884e2b.ics
@@ -22,9 +22,10 @@ END:DAYLIGHT
 END:VTIMEZONE
 BEGIN:VEVENT
 UID:63befe9a-f73b-4bd0-bc0d-34d67a884e2b
-DTSTART;TZID=Europe/Berlin:20260401T000000
-DTEND;TZID=Europe/Berlin:20260401T010000
-DTSTAMP:20260122T002207Z
+DTSTART;TZID=Europe/Berlin:20260401T090000^M
+DTEND;TZID=Europe/Berlin:20260401T100000^M
+DTSTAMP:20260122T002317Z^M
+SEQUENCE:1^M
 STATUS:CONFIRMED
 SUMMARY:test
 BEGIN:VALARM

It certainly seems feasible to build the functionality you describe on top of this. E.g. to list all the changes made to a particular event, run git log --oneline -- path/to/event.ics. This is a solid foundation for building something more ergonomic on top. Still, it remains to be seen how this scales over time. I'll report back if I encounter any issues.