Add Imagine domains to the list

[hmacr]

Public Suffix List (PSL) Submission

Checklist of required steps

• Description of Organization

• Robust Reason for PSL Inclusion

• DNS verification via dig

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _psl TXT record in place in the respective zone(s).

Submitter affirms the following:

• We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)

• Cloudflare
• Let's Encrypt
• MAKE SURE UPDATE THE FOLLOWING LIST WITH YOUR LIMITATIONS! REMOVE ENTRIES WHICH DO NOT APPLY AS WELL AS REMOVING THIS LINE!

• This request was not submitted with the objective of working around other third-party limits.

• The submitter acknowledges that it is their responsibility to maintain the domains within their section. This includes removing names which are no longer used, retaining the _psl DNS entry, and responding to e-mails to the supplied address. Failure to maintain entries may result in removal of individual entries or the entire section.

• The Guidelines were carefully read and understood, and this request conforms to them.
• The submission follows the guidelines on formatting and sorting.

• A role-based email address has been used and this inbox is actively monitored with a response time of no more than 30 days.

Abuse Contact:

• Abuse contact information (email or web form) is available and easily accessible.

URL where abuse contact or abuse reporting form can be found:

---

For PRIVATE section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

• Yes, I understand. I could break my organization's website cookies and cause other issues, and the rollback timing is acceptable. Proceed anyways.

---

Description of Organization

Imagine is an AI-driven, full-stack web application builder designed to turn natural language ideas into functional, deployed, and production-ready software. It's developer by the same team who built Appwrite.

I am a Platform Engineer at Imagine/Appwrite.

Organization Website:
https://imagine.dev/

Reason for PSL Inclusion

Imagine allows users to deploy their generated app on our platform. By default, each app deployed gets an auto-generated domain like 64d4d22db370ae41a32e.imagine.diy so users can access it on web. As such, we don't want developers to be able to create a cookie on imagine.diy that would be used for other people's sites.

Yes, we confirm our domain registration is longer than 2 years and will maintain more than 1 year to remain listed.

Number of users this request is being made to serve:
Estimated 15k-20k users.

DNS Verification

dig +short TXT _psl.imagine.diy
"https://github.com/publicsuffix/list/pull/2762"

[pencilnav]

#2714 (Submitted by @stnguyen90)

Hi @hmacr , could you briefly explain the differences between these two domains and why this PR isn't added in the imagine.dev section (but the appwrite section)?

A confirmation from the previous PR submitter is also required (i.e. @stnguyen90 ).

[stnguyen90]

@pencilnav thanks for catching that! @hmacr, please move the domain to the right section.

@pencilnav, right now, when you deploy a site on Appwrite Cloud and Imagine, you get a appwrite.network subdomain. However, we're adding this new domain because we want web apps deployed from Imagine to have the imagine.diy base domain instead of appwrite.network.

[hmacr]

@pencilnav Thanks for the review, I've moved the new domain to the correct section.
cc @stnguyen90

[simon-friedberger]

We commonly suggest that - if you automatically give users subdomains - you include a user identifier in the domain to avoid accidentally giving the same domain to a different customer next time. You seem to be using fairly long random strings so the likelihood is probably small but please keep it in mind.

[hmacr]

@simon-friedberger Thanks for the heads up, we ensure no two users have the same sub-domain on our side 😄
I've fixed the sorting as well, could you please re-run the workflow?

[pencilnav]

@stnguyen90 Sorry for not being clear on my previous message.

By differences between these two domains i mean imagine.diy and imagine-proxy.work (which was added in #2714 previously)

What are the differences between these two domains (and is it nesscery to add another one)? Because based on this PR and the earlier one, their stated functionality appears identical, and i think in that case having one of them in the PSL should be enough (The goal of this is to keep the PSL minimized and avoid adding entries when unnesscery).

Quote from #2714

We use the imagine-proxy.work to expose the app users build. When a user runs a project, their app is exposed under a generated subdomain like https://3000-<ID>-preview.imagine-proxy.work/. To prevent users from creating a cookie on the apex domain or impacting each other, we would like to add imagine-proxy.work to the public suffix list.

[stnguyen90]

@pencilnav the imagine-proxy.work is used during development while the imagine.diy is a published web app.

If both of these domains are actively used, isn't it necessary to add them both to the PSL?