A month or two ago, when Dubvee was down for a while, I noticed that my self hosted instance of Tesseract (pointed to my Lemmy instance) was also not working. I could browse it just fine, but once I would try to sign in, I believe the problem was that it would just infinitely load. That made me rather wary of using Tesseract at all, wondering how tied it is to your personal infrastructure. Can you ease my privacy-focused mind on what happens to my credentials when I attempt to log in?
You must log in or # to comment.
Shouldn’t be tied to any instance or rely on my infrastructure at all.
The only hardcoded instance is Lemmy World, and that’s just the default instance it uses if it’s not deployed with the
PUBLIC_INSTANCE_URLenvironment variable (when set, that variable overrides the hardcoded fallback one and is the only env var I have marked as required in the docs).All API calls go directly from your browser to your Lemmy homeserver. Tesseract doesn’t even use SSR, so everything happens locally.
There are a few API endpoints internal to Tesseract, but they’re relative to the deployment (e.g.
/tesseract/api/loops/lookup). There’s also the media proxying/caching module which will rewrite images to go through Tesseract’s web server, but again, those are relative to the deployed instance. The proxy/cache module also has to be explicitly enabled by the admin when deploying Tesseract and by the user in their app settings (it’s default disabled in both)Just to make sure I didn’t leave some weird test case in place, I just did a
grep -r dubvee.org src/*on the codebase, and the only reference to my instance is in the footer for the Lemmy community link.ptz@dev01:build/tesseract$ grep -r dubvee.org src/* src/lib/components/ui/SidebarFooter.svelte: <Link href="https://dubvee.org/c/tesseract" newtab={true} title="Lemmy"> ptz@dev01:build/tesseract$ grep -r lemmy.world src/* src/lib/instance.ts:export const DEFAULT_INSTANCE_URL = env.PUBLIC_INSTANCE_URL || 'lemmy.world'
