Quoting Craig Sanders (cas(a)taz.net.au): Tried Radicale? https://radicale.org/ There's also a slightly different fork project, Xandikos. https://www.jelmer.uk/xandikos-intro.html

Quoting Craig Sanders (cas(a)taz.net.au): [Radicale and Xandikos:] Did you notice how there's basically _no_ publicity for these small, fast, secure, modestly scoped projects -- only for overfeatured, huge, slow, probably insecure groupware dinosaurs? It sure did strike me that way, a couple of years ago when I did an impromptu survey of Linux 'iCalendar'-hosting software. Actually, possible amusing story: I lurk on a LUG mailing list in central Florida (GoLugTech), where one of the members posted this in Jan. 2018: Suggestion: add iCalendar for meetings to golug.org I knew what he _meant_. He meant that, seeing as he's a frequent user of Google's hosted proprietary service 'Google Calendar', would GoLUG please, for his personal convenience, henceforth maintain an iCalendar dataset, that GoLUG would craft and host entirely within Google's hosted service -- basically asking GoLUG volunteers to do ongoing work to support 'cloud' outsourcing. But since that's not what he _said_, I somewhat mischievously replied to the letter rather than the spirit of his request, exploring in several postings all current _self-hosted_ Linux software (both proprietary and open source), by which one can create/edit and then SELF-host RFC-5545 iCalendar event files for public / LUG access -- with access mediated by the CalDAV and CardDAV access protocols, for reasons I briefly detail.[1] As I predicted, the querent made no reply. He probably had no intention of ever finding iCalendar client software for _any_ OS; his vision went only as far as his opening https://calendar.google.com/ in a Web browser and letting Google do everything via AJAXey HTML5 operations and stupendously complex proprietary back-end software. (In fact, I'll bet he's never seen an .ics file, and would have zero idea what to do with it.) Anyway, my improptu survey from Jan. 2018 may still be of interest. I re-posted it to SVLUG's main mailing list (after some copyedits): http://lists.svlug.org/archives/svlug/2018-January/062504.html http://lists.svlug.org/archives/svlug/2018-January/062505.html http://lists.svlug.org/archives/svlug/2018-January/062506.html Disclaimer: It having been almost exactly two years, I wouldn't be the least surprised if my survey is has mold around the edges. [1] This happens to be the feature-scope (IMO) 'sweet spot' occupied by Radicale and its two forks Calypso and Xandikos. (I didn't mention Calypso before. Keith Packard of X.org fame wrote it. See third link, above.) -- Cheers, "Maybe the law ain’t perfect, but it’s the only Rick Moen one we got, and without it we got nuthin'." rick(a)linuxmafia.com -- U.S. Deputy Marshal Bass Reeves, circa 1875 McQ! (4x80)

Quoting Trent W. Buck (trentbuck(a)gmail.com): Sadly, I'm no expert at this. (I don't even so far use smartphones.) I suspect that it all depends on what sort of client service on the phone you're talking about, i.e., is it one of the ones designed to work with real iCalendar scheduling servers (w/access protocols), or is it just a Web wrapper devoted entirely to a Web site fronting scheduling data. I do know that, if you engage with the communities using software like Radicale as server-side solutions, they can tell you a lot about what works client-side and anything required to mesh the two -- perhaps the missing glue in your (one hopes, roughtly corresponding) server stack that's purported to make people with phones do useful things to your server if you do the 'add calendars' step. To know more, I'd have to do the same from-near-zero research you would, and you have the advantage of a test platform. ;-> And, of course, the typical 'person with phone' wouldn't know jack, about what software he/she must have installed to implement commodity network protocols and to interpret received data. So, no point in asking them. They'd have no clue, in the main. But, to help get around that: Taking a quick gander at Radicale (assuming it's feature-comparable): Front page encouragingly says 'Works with many CalDAV and CardDAV clients.' Well, peachy. https://radicale.org/clients/ elaborates: Radicale has been tested with: Android with DAVdroid GNOME Calendar, Contacts and Evolution Mozilla Thunderbird with CardBook and Lightning InfCloud, CalDavZAP and CardDavMATE Goes on to give specific tips. Of course, this information would be useful to _you_ only to the extent that your server stack truly has the identical capabilities, and I haven't a clue what a postfix+dovecot stack with 'calendars' would comprise/do, really. I was curious about 'DAVdroid'. Looks like its successor codebase is something called DAVx, described as 'a CalDAV/CardDAV management and sync app for Android'. So, there ya go. But if the user wants a contacts, calendar, or tasks app (to edit/view contacts, events, tasks etc. on a smartphone), that's a separate need. DAVx just manages the CalDAV/CardDAV data flow between remote content providers and the Android API. For example, Samsung's Android devices reportely include in the OS build something called Samsung S Planner (more recent name 'Samsung Calendar'). I followed the non-progress of scheduling software on Linux for long years starting in 1999, when the CTO, David Sifry, of my company Linuxcare (a now long-dead dot-com) was known for, among other things, an alphaware set of scheduling software called OpenFlock[1] implementing some of the IETF alphabet-soup-du-jour protocols for the purpose that never went anywhere. (I remember these included BEEP and iTIP.) The project soon got unceremoniously abandoned, far from finished. One of the lessons of study that and similar debacles was that the chaotic churn of protocols and every little device (which then included idiosyncratic PDAs) or client software having its own quirks and needs was a killer. And, the thing is, I think many such projects gave up in part because of standards churn and 'Oh, I see you just added LDAP authentication but it doesn't work with _my_ LDAP'. And also that there wasn't agreement about what client-side needed to do, hence no agreement on linking protocols. What was required was a few strongly present-in-the-market clients all implementing the same core protocols and having the same expectations of a server. Then, coders would have a stable target to shoot for. I'm guessing we're appoaching that sort of pragmatic consensus that delivers a commodity standard. I would further guess that https://radicale.org/clients/ might be deemed a place that goes into the details of that commodity standard. Hope that helps. [1] https://www.usenix.org/legacy/publications/library/proceedings/als00/2000pa…

Quoting Trent W. Buck (trentbuck(a)gmail.com): You're one step ahead of me, because I haven't even yet set up a prototype, only read stuff about it. It certainly _seems_ to have something going for it, and enthusiasm among people who seem credible.. Just in case you haven't seen these detailed client tips, maybe they'll help: https://radicale.org/clients/ Also, oriented around setup on OpenMediaVault, with client usage around minute 33: https://www.youtube.com/watch?v=WlkF79-KCPo Also^2, this review walks through some client-connectivity examples: https://www.techrepublic.com/blog/linux-and-open-source/create-an-easy-to-u… Also^3, this tutorial covers client setup on Android: http://gedakc.users.sourceforge.net/display-doc.php?name=android-davdroid-r… as does (briefly) https://www.stavros.io/posts/private-contacts-and-calendars-android/ -- Cheers, "Maybe the law ain’t perfect, but it’s the only Rick Moen one we got, and without it we got nuthin'." rick(a)linuxmafia.com -- U.S. Deputy Marshal Bass Reeves, circa 1875 McQ! (4x80)