[CAL-2115] RFC: The future for Cal Console

[PeerRich]

EDIT by @zomars

The future for Cal Console

The current state of console is quite of rusty in terms of work being done there. Even tho it is in charge of our main revenue potential (licensing).

It can be done. We already are like 80% percent there. The flow in general haven’t received much attention and love as it should. But I think now is the time to do it instead of using those resources to migrate

Separation of concerns

We still need console. But admin stuff should not live on console. Ideally it should live /settings/admin/. Adding more things that are calcom only is a bad trend that should only be done as a last resort IMO. Adds a lot of technical complexity wherever we do this.

Console should only worry about deployments and license keys. Self hosted instances should be self-manageable. (admin, users, features, auth, etc.) So it makes sense to have these tools built-in into the web-app.

Licensing and keys are only relevant to our current business model, so it makes sense to have a dedicated service to create new deployment keys and self-serve via checkout. Also Sales can make use of this tools to kickstart new customers (input an email and a custom plan and customer should receive a magic link to finish the checkout process with a user previously created).

Plan for execution

• Move all admin stuff from Console to Web-App (we're already ~80% there)
• Improve Console flow for getting a license key
  • Flow A: Self-serving
  • Can be initiated from a self-hosted deployment without a key.
  • If you already have a Cal account, pick up the session and go directly to new deployment flow (no current onboarding)
  • If you don't have a Cal account, enter your email. You will receive a magic link that will create a basic Cal account on our side and will take you directly to the new deployment flow.
  • Flow B: Custom Enterprise deals
  • Sales (Shiraz) can have a special screen where he can enter a customer's email and a previously created custom Stripe price URL and hit Send
  • This would:
    • Create a new Cal account (if it doesn't exists)
    • Send a magic link to that account
    • When clicked it will log you in and sent you directly to the new deployment flow with the custom Stripe plan already set
    • Customer then can enter their billing details and finish the Checkout.

Previous edit by @PeerRich

# goals: * deprecate [console.cal.com](http://console.cal.com) * archive calcom/console * make it easier to generate a key without logging into a separate app # plan: * create a new section in settings called: "Self-hosting" * (only if domain === [app.cal.com](http://app.cal.com), to prevent recursion haha. self-hosters can't generate license keys for other self-hosters because the license key API is closed source)  * explain what this section does with an empty screen: * title: "Host [Cal.com](http://Cal.com) on your own server" * body: "To host the commercial license of [cal.com](http://cal.com) you can generate and manage your license key here" * button: "Get Started"  * make it possible to generate license key in this new section * the license key generation API endpoint should obviously not be open sourced and live in calcom/website app and not be open sourced to protect DRM haha * after generation, show the same data we currently show in console, like monthly bookings etc.

_{From SyncLinear.com | CAL-2115}

[PeerRich]

increased priority because it would impact sales and improve quality of onboarding

[PeerRich]

added PR with layout: https://github.com/calcom/cal.com/pull/10695

need someone to take over and replace the duplicated API key logic with the console logic (payments, license key generation etc.)

[zomars]

• (only if domain === app.cal.com, to prevent recursion haha. self-hosters can't generate license keys for other self-hosters because the license key API is closed source)

This alone would be my signal to double down on keeping console. We still need a place to handle private stuff.

Console took a dive when we tried to incorporate ADMIN tools into it. Which IMO should live in the product itself.

Also we still rely on console web service for license checks and payments webhooks.

[CONIGUERO]

Hi there, I'm not really involved in this but I thought I'd share my comments anyway since licensing stuff always interested me.

If the fear comes from people being able to bypass the DRM of EE features, I don't think it's really warranted. The main IP is open-source already, if we assume a malicious actor wants to bypass the licensing logic, they can already do so easily by modifying the code that pings the license API in the main product.

Having everything, including console (or licensing API in case this issue is resolved in the future) be open-source, or at least source-available like the ee directory in the main repo, is the best option IMHO. It will prevent all headaches around what not to open or repo division/gates.

For an example of how this can work, I point you to https://keygen.sh - a licensing API for which the server source code is publicly available, https://github.com/keygen-sh/keygen-api

[PeerRich]

yeah this is not about DRM 🙏

[CONIGUERO]

yeah this is not about DRM :pray:

Sorry, I just infered that, and provided feedback on, from the following comment on the issue:

• make it possible to generate license key in this new section

  • the license key generation API endpoint should obviously not be open sourced and live in calcom/website app and not be open sourced to protect DRM haha
• after generation, show the same data we currently show in console, like monthly bookings etc.

[keithwillcode]

Moving this to be worked on in v3.4

[keithwillcode]

Removing from milestone because PR went stale.