CalDAV ?

[theotheroracle]

ive looked through the issues and discussion posts and im honestly a bit surprised no-one has suggested caldav support ? would be really easy to backup and sync tasks with other devices that way .

[hiqua]

There's a sync feature under way already. Not sure why caldav support hasn't been considered though.

[iSoron]

Thank you for the suggestion, @theotheroracle, but it's still not clear to me how could CalDAV be helpful. Would you mind elaborating on this suggestion?

• Is the main motivation here just data backup and sync, or are there any other advantages?
• Assuming Loop "implements" CalDAV, what would be the workflow for a user to sync the data between two devices? I am interested in the concrete steps.
• Would this require Loop to share the user's (unencrypted) habit data with third parties (e.g. Google Calendar)? I have the average user in mind here, not someone with enough technical skills to run a self-hosted calendar server. Note that the sync solution we have on Loop 2.0.0-alpha does not share unencrypted data with any third parties, and does not require technical skills (we encrypt the data before uploading it).
• Would this require Loop to have complete access to the user's calendar?
• Does CalDAV support storing custom metadata, or just some common calendar event fields? For example, would it be possible to store the habit frequency, its position on the list, etc? For numeric habits, would it be possible to store numeric entries, target values, etc?
• Would Loop's data be visible in other calendar apps? What happens if the user modifies the habit in other apps?
• Unless I am mistaken, CalDAV would still simply be a remote data store. We would still need to implement all synchronization features ourselves (e.g. conflict resolution), in addition to Loop/CalDAV conversion. It's not clear to me what are the advantages of this solution compared to other simple file storage solutions. At least with other file storage solutions, there is no conversion involved; we can directly upload Loop's database.

[theotheroracle]

Is the main motivation here just data backup and sync, or are there any other advantages?

not only for the backup and sync for data from this app, but also other apps which support the caldav protocol . i could for example, create a repeating reminder from the web interface of nextcloud, or maybe the tasks app for android, or even the reminders app for ios and android . the question of course might then be, why do you want to use this app then if the others are already suitable, and it's largely the UI and analytics which make completing the tasks more engaging, but still allows the flexibility to check off tasks from other devices or apps .

Assuming Loop "implements" CalDAV, what would be the workflow for a user to sync the data between two devices? I am interested in the concrete steps.

a common workflow for apps implementing caldav is to use DAVx5 as the backend, so as to not have to worry about account management, or the like, and only focus on the implementation itself, https://github.com/tasks/tasks for example, supports repeating tasks on caldav both through davx5 and their own sync engine .

the convenient thing for many users with caldav, is that they will likely already have davx5 and won't even have to add an account, it would be easy for them to add the app . but if they don't, they'd install it, and sign into a caldav account .

Would this require Loop to share the user's (unencrypted) habit data with third parties (e.g. Google Calendar)? I have the average user in mind here, not someone with enough technical skills to run a self-hosted calendar server. Note that the sync solution we have on Loop 2.0.0-alpha does not share unencrypted data with any third parties, and does not require technical skills (we encrypt the data before uploading it).

well i imagine many of them will use a nextcloud instance, for example disroot.org, since they're already using open source task list software, but those that do upload their data to google would likely already be aware of what that entails, and if not it could be described to them in app perhaps ? another option would be to support etesync, which is a similar protocol but with end to end encryption . of course, users would still need an etesync service, so much of the same applies .

Would this require Loop to have complete access to the user's calendar?

no, that would be handled by davx5

Does CalDAV support storing custom metadata, or just some common calendar event fields? For example, would it be possible to store the habit frequency, its position on the list, etc? For numeric habits, would it be possible to store numeric entries, target values, etc?

you can add decriptions to tasks, as well as an associated file, which you can store potentially any data in, and it does also record each time a repeating task is completed, as well as list order, tasks frequency, and some various other metadata .

Would Loop's data be visible in other calendar apps? What happens if the user modifies the habit in other apps?

yes ! as i mentioned towards the top, the tasks could be compeleted in any caldav compatible client, in which the record of the completion would be stored, and the task itself would be marked again as uncompleted, which as mentioned above, provides the user with much more flexibility .

Unless I am mistaken, CalDAV would still simply be a remote data store. We would still need to implement all synchronization features ourselves (e.g. conflict resolution), in addition to Loop/CalDAV conversion. It's not clear to me what are the advantages of this solution compared to other simple file storage solutions. At least with other file storage solutions, there is no conversion involved; we can directly upload Loop's database.

well, if a backend like davx5 was used, then no, it would be handled by both it, and caldav itself, including things such as conflict resolution, afaik . and yes, the conversion process would be slightly involved, but ultimately i think worth it for the flexibility .

[theotheroracle]

i would note, that i would be willing to work on an implementation, and also that i understand that this might not fit the the direction with the project .