[bug] the new ozone (bluesky-social/ozone) is not configurable, by the web front-end ignoring all environment variables.

[itaru2622]

related to #2404 and bluesky-social/ozone#94 and migrated here from those.

introduction
the new ozone (https://github.com/bluesky-social/ozone) provides the next.js-based web front-end with atproto/packages/ozone as backend and the REST server.

next.js provides the way to configure front-end by environment variables prefixed NEXT_PUBLIC_.

the code in new ozone trying to follow the above mechanism to tune web front-end behavior by involving NEXT_PUBLIC_PLC_DIRECTORY_URL besides OZONE_DID_PLC_URL for PLC endpoint, and so on.

---

as I reported in bluesky-social/ozone#94,

expected behavior:
when NEXT_PUBLIC_PLC_DIRECTORY_URL is configured, its value is used to change PLC endpoint from default. and other environment variables also work respectively.

actual behavior
all environment variables are ignored by front-end, then it does not work as expected.

for example, even I set both NEXT_PUBLIC_PLC_DIRECTORY_URL and OZONE_DID_PLC_URL to my-own PLC,
front-end keeps accessing its hard-coded default value, then sign-in process failed in front-end, and ozone doesn't work on my deployment.

remarkable things is:
the REST server (express) recognizes the all environment variables including NEXT_PUBLIC_PLC_DIRECTORY_URL and OZONE_DID_PLC_URL as expected.
so I guess environment variables are lost in somewhere while front-end booting process.

[itaru2622]

After some investigation and debugging, I finally found that this issue was caused by a mismatch between the use of NEXT_PUBLIC_XXX env vars and its aims(flexibility on deployment).

as described below in next.js official document, NEXT_PUBLIC_XXX is frozen at build time, so it's cannot use for URL endpoint which should be flexible to deployment.

In order to make the value of an environment variable accessible in the browser, Next.js can "inline" a value, at build time, into the js bundle that is delivered to the client, replacing all references to process.env.[variable] with a hard-coded value. To tell it to do this, you just have to prefix the variable with NEXT_PUBLIC_

While investigating work around, I found below page which describes choices to support runtime configuring next.js front-end.
https://notes.dt.in.th/NextRuntimeEnv

I think below choice is simple and the best, because server side( REST server) detects runtime env vars as we expected.
more over this approach is not depends on next.js. then robust to bumps versions, and changes of front-end framework.

Client-side-rendered components fetch the data from an REST API

to achieve this choice, it just needs:

1. make REST endpoint to return runtime env vars(process.env.*) for front-end request.
2. front-end (Component) fetches the above endpoint using react useEffect() and keeps values by react useState() if needed.
3. front-end may need to pass envs to client(lib/client.ts) , then lib/identity.ts etc according to call stacks.

before making code, I'd like to confirm if maintainers agree the above choice. or let me know preferable alternative for maintainers.

[itaru2622]

I finally succeeded to sign-in self-hosting ozone by patch based on the above.

my patch currently has about 200 lines but it may need more patch to work completely.
anyway, good news.

[itaru2622]

I started testing and found it seems lots of features are already working, beyond my expectation as below:

• join ozone(labeler) to self-hosting env.
• sign-in to ozone-UI then auto-adding record as labeler in DID doc, when the account was created via sign-up on social-app. (<= i.e becoming as labeler in lazy)
• configure a label on ozone-UI at /configure.
  - [ok] 'labels' tab apears in profile page on social-app.
  - [ok] 'subscribe to labeler' button apears in profile page on social-app.
• switch subscribe /unsubscribe labeler' on social-app profile page => it apears/disapears in moderation-list in user's profile pages on social-app.
• send report to labeler from social-app for post ( dotted pulldown menu in each post)
• receive and view report on ozone-UI (both in /events and /reports)
• others: not yet.

[astrojuanlu]

Is your patch public @itaru2622 ? It's not very clear to me how else, if not with env variables, are users expected to make Ozone run.

[itaru2622]

@astrojuanlu
my patch is public at below:
https://github.com/itaru2622/bluesky-selfhost-env/blob/master/patching/120-ozone-runtimeEnvVars.diff

ozone docker image built with above patch is also public at https://hub.docker.com/r/itaru2622/bluesky-ozone/tags
refer README.md at https://github.com/itaru2622/bluesky-selfhost-env for detail.