Multi-tenancy with custom domains

More technical look at #897 Idea: Let users point DNS records to an existing instance, configure specific user to be served as-if from that domain. What parts must work correctly for this: - [ ] Separate field for storing whether an account is remote or local rather than relying on `domain` being null - store custom domain in that column? - [ ] All functions that check whether an account is local must check the custom domain as well as the "local domain" of the instance - [ ] Webfinger must answer queries for the faux-remote account - [ ] *Other* accounts must not be served from that custom domain. Accessing the *website* through the custom domain should be limited to only public content from the owner of the domain. Concerns: - Switching instances while keeping the same domain will present the same problem as erasing/reinstalling an old instance on the same domain - other servers will remember data that you don't, any numeric IDs may reset and overlap (but generated string URIs include not just numeric ID, but also timestamp of creation, so that's not a big concern) - Might be the first credible case for exporting/importing data *verbatim*, e.g. including all small details. Just like with local users having a custom domain, statuses should be amended to be local *and* able to have verbatim URIs like remote ones

Posted by Gargron on Apr 30, 2017, 10:31 PM

Tags

• github (Network)

Related issues

• [UPDATE NOW] PHP RCE Vulnerability (CVE-2026-109618 and CVE-2026-109619)
• Server requests and latency increased after upgrading from Next.js 15 to 16
• Leak of Geedge Networks internal documents (100,000+ from Jira, Confluence, GitLab)
• Can't download videos from YouTube on cobalt.tools
• `google_service_networking_connection` produce an error when trying to destroy the resource
• WebGPU-based renderer for the editor