Possibility to bind to a thirdparty iCal service (not Google Calendar)

[Tyrben]

Is your feature request related to a problem? Please describe.
The google account behind Discal is owned by discal and is not accessible in edition to external users without using Discal.

Describe the solution you'd like
There are currently several standard interface to access e-calenders: iCal if one of them, there is also DAVx ...
There are also plenty of free calender services (for example https://framagenda.org/login ). Where beside the standard webinterface, there is a iCal webservice as well.
Could it be possible to configure Discal to bind to a given webservice URL, login, pass... ?

Could be commands like:

!discalconfig url https://framagenda.org/api/ical/1v8e45k1L9a78dfV
!discalconfig login myUser

Describe alternatives you've considered
An alternative would be to bind Discal to a given google account, so that is could be the property of the user.

Additional context
https://framagenda.org/login or any other iCal / calDAV webservice.

[NovaFox161]

Not currently possible as google's calendar API is integrated directly within the bot. While I do want to eventually support iCal among some other notable calendar services (Apple, Office 365, etc), it would require nearly a complete rewrite of the bot as well as to find ways to support things that we currently support with google that may not exist within those other services.

As for the problem this is related to, the design of DisCal was to integrate google calendar with Discord as cleanly as possible, doing so meant removing the need for the user to actually make google accounts, create, and assign proper permissions to the calendar, among other things, we wanted to remove as much "clunk" as possible. We added external calendar support for the clear benefit for users to use DisCal with google calendars that had already been established for a long time.

While we do possess the ability to invite users to the calendar directly, there is no easy, private, or secure way about this. We would be requiring users to send us their emails so that we can send it to the API for an invite. This goes against our main design principles of maintaining a secure and privacy focused code base and service.

As such, those commands we wouldn't deem accessible as it is breaking the principle of security. It would most likely function similar to the external calendar, where you could select the service to use, and it would authorize the bot in a secure way to the account (such as using the OAuth2 authorization flow that we currently use with Google for external calendars). This also gives the user ownership of the calendar and keeps the accounts secure.

I understand the desire for wanting the calendar to be owned by the user, and that is why we have the external calendar system as well. The bot is fully usable as a free bot, and the subscription gives access to more features that are useful, or beneficial, but not expressly needed.

So, I do want to add support for other services don't get me wrong, There's just a need to rewrite a substantial part of the code base and figure out how we would design into it. The good news is that I am working on abstracting large parts of the code and working directly with a centralized DisCal API, but its still in very early stages of development.

[Tyrben]

Thank you for this very complete and professional state of the art.
I can only agree with you about security concern, I also prefer authentication delegation (with OAuth2) than direct login. That's for sure.
And I'm happy this suggestion worries you too.