Tests and Compatibility Documentation (CardDAV/CalDAV RFC Support)

[titanism]

As per https://en.wikipedia.org/wiki/Comparison_of_CalDAV_and_CardDAV_implementations#Server_implementations we should probably outline the compatibility with all the different specs. We should also edit that Wikipedia and include this project too afterwards.

The current DAV header is here https://github.com/sedenardi/node-caldav-adapter/blob/bdfbe17931bf14a1803da77dbb70509db9332695/src/common/response.ts#L8-L25

The main ones it is missing appear to be:

• extended-mkcol (WebDAV; extended-mkcol – not essential)
• calendar-proxy (Calendar Delegation; gives users other access to your calendar, https://sabre.io/dav/caldav-proxy/, iCal and BusyCal support it)
• calendarserver-sharing (sharing and calendar publishing, see https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/caldav-sharing.txt)
• calendarserver-subscribed
• addressbook (CardDAV)
• access-control (related to sharing calendarserver-sharing and extendedmkcol)
• calendarserver-principal-property-search (calendar discovery, https://datatracker.ietf.org/doc/html/rfc3744#section-9.4)

The calendar-auto-schedule is arbitrary and a related discussion is at Kozea/Radicale#34 and Kozea/Radicale#1337. Almost none of the implementations support it, so we should try to be 1:1 with the most supported and well-known.

For testing, we could leverage https://github.com/natelindev/tsdav, albeit more specific tests would need to be added. One could copy/paste one of these folders and rewrite to use a test with this Koa server, e.g. https://github.com/natelindev/tsdav/tree/master/src/__tests__/integration.

I think that we will be submitting a PR to this project to try to add support for CardDAV, since none of the other open-source projects have MIT or MPL like licensing, as this one does.

The Fennel project has some inspiration at https://github.com/LordEidi/fennel.js/blob/abfc371701fcb2581d8f1382426f0ef9e9846554/libs/communication.js#L143, https://github.com/LordEidi/fennel.js/blob/abfc371701fcb2581d8f1382426f0ef9e9846554/handler/addressbook.js#L31 (CardDAV), and https://github.com/LordEidi/fennel.js/blob/abfc371701fcb2581d8f1382426f0ef9e9846554/handler/principal.js#L86.

[sedenardi]

I think that we will be submitting a PR to this project to try to add support for CardDAV, since none of the other open-source projects have MIT or MPL like licensing, as this one does.

Feel free! Once you do, I'll be sure to review and merge them in as soon as I can.

[titanism]

Thanks @sedenardi - if you have Matrix/Element, would love to have you join our chat. Either way, thanks for building this and releasing with MIT ❤️ 🙏 We're definitely planning to use and contribute @forwardemail.

https://forwardemail.net (click on Resources > Community > Matrix Chat)

[titanism]

Note for us, proId is a typo, it should be prodId

[sedenardi]

Hi @titanism, I've added you as a collaborator to this repository. As I mentioned in a comment on another issue, I'm no longer actively developing this project personally, but I'm happy to grant you access to continue it.

I will say, this is my first experience with GitHub Collaborators, so bear with me and let me know if you don't have proper access to review and merge PRs. I can publish new releases to npm when necessary, but we can discuss whether that's something you'd like access to do as well.

[titanism]

Thank you @sedenardi. I've accepted the invite on GitHub and will let you know if I have any issues.

I would love to have access to publish on npm too, respecting SemVer. At @forwardemail we use np to publish releases with detailed changelogs in the Releases tab of GitHub. See https://github.com/sindresorhus/np. You can grant us npm ownership by typing npm owner add titanism caldav-adapter on CLI I believe.

[titanism]

Edit: The command is actually npm owner add titanism caldav-adapter

[sedenardi]

Done, let me know if there's anything else.

[titanism]

You're the best @sedenardi! We're adding a ton of tests and discovering how this all works, will keep you apprised. 🙏

[titanism]

It doesn't seem like we have write access still, are you sure you added the right user and it was successful @sedenardi ?

Error screenshot below:

[sedenardi]

I ran npm owner add titanism caldav-adapter and got a successful response.

npm notice INFO: User titanism invited to package caldav-adapter successfully.
+ titanism (caldav-adapter)

Is there an additional permissions I need to grant?

[titanism]

@sedenardi I got the email, it went to spam. Thank you for your help and patience. Separately, I've filed an issue with npm because their DKIM signature was not aligned since they use Amazon SES, and DMARC with "p=reject" ; therefore their email went to spam.

[sedenardi]

No worries, glad you got it sorted.

I've always found DMARC to be more of a footgun than helpful, so I'm not shocked to hear that.

[titanism]

We've found some core bugs in this package and did a complete rewrite.

For example, https://github.com/sedenardi/node-caldav-adapter/blob/4076fc67552ddbab2ead5dc52395b0b1497f2b35/src/common/tags.ts#L165-L168 should instead have resource as the object property instead of response. There were other typos like this similarly in the codebase, and we discovered these through tests.

Unless you are interested in transferring this repository to the @forwardemail organization @sedenardi, we plan to publish an independent fork of this project (with your original authorship retained) and an updated copyright to include us, under the same MIT license. Our fork will be under @forwardemail/dav otherwise 🚀

Thank you so much for building this library, we've poured several hours into this and our fork is modernized.

[sedenardi]

I'm more than happy to transfer ownership!

For some context, this package was developed (and tested) for specific workflows and capabilities. I used other CalDAV implementations (Apple's, radicale, etc.) as well as the RFC spec as guidance, but concentrated on making sure the code paths I was using (often determined through testing against several clients) were correct. Any other code paths (like this example) were admittedly placeholders for if I ended up needing to implement them.

Please let me know what you need me to do to transfer the repo. I love that the countless hours I've poured into this are proving useful for others!

[titanism]

@sedenardi amazing 🙏 can you transfer it to @forwardemail organization on GitHub?

[sedenardi]

I received this error when I tried transferring it. Looks like you already have a fork, so not sure how you want to handle it.

[titanism]

@sedenardi we just deleted our fork, try again? 😄

[sedenardi]

New error this time.

[titanism]

sec

[titanism]

@sedenardi just invited you to the org, once you accept invite (check your inbox), should be good 🖖

[sedenardi]

Done!

[titanism]

@sedenardi Thank you 🙏 Will keep you as a maintainer 🖖

[titanism]

@sedenardi we made it happen! see forwardemail/forwardemail.net@57907d4 and https://github.com/forwardemail/caldav-adapter/releases/tag/v5.0.0

[sedenardi]

@titanism Congrats on getting your features out the door.

One thing that caught my eye is the removal of Typescript support in that release. While this library is now fully yours to do with what you want, I would strongly recommend reconsidering this decision for a 2 main reasons:

1. Typescript (IMO) is now the de-facto standard among npm libraries. Removing TS typings may not only turn away folks from using it in their own applications (as it would for me if there were no types), but highly discourages outside developers from contributing.
2. While the application you're using this library in may not be Typescript, TS is backwards-compatible and does bring some nice type-hinting to most popular IDEs.

Feel free to reach out if you'd like to discuss this decision further. As I mentioned, the decision is fully in your hands now, but I mention it only to promote the broad use of and contribution to this open source library.

[titanism]

Hi there @sedenardi 👋

Yes we dropped TS - as we attempted to use it, but found too many issues with the previous code with TS, warnings, etc.
We also don't use TS for any of our packages (which have > 30M+ monthly downloads), and attempted to rewrite the code while still using TS, but came to the conclusion it's unnecessary complexity.

TypeScript and ESM are not the current standards (a majority > 60-70% of npm packages still use pure JS and CJS exports last time we checked). We are also maintainers of Express and Koa, and have found TS and ESM to be horrible experiences and huge time sinks.

Also see https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 and https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01.

[sedenardi]

Fair enough!