abuzar-ansarii/privatepixelprompt

1. Overall shape

PortableLM is a cross-platform, portable local-AI package. The repository is mostly a set of OS-specific launch/install wrappers around one shared runtime and one shared web UI/server.

2. Platform boundary

The Windows, Linux, and Mac folders contain only thin entrypoint scripts:

- install/uninstall scripts

- start scripts

These are platform adapters; they do not appear to implement the AI logic themselves.

3. Shared runtime boundary

The Shared folder is the core of the architecture. It holds the cross-platform assets that are meant to be reused regardless of host OS:

- chat_server.py for the local service

- FastChatUI.html for the browser UI

- config/ for model and asset metadata

- scripts/ for setup, cleanup, and asset download helpers

4. Local server + browser UI

The main runtime appears to be a Python HTTP server (Shared/chat_server.py) that serves the UI and provides the local API for chat/image/TTS actions. The browser is the client, and the server listens locally by default on localhost:3333, with LAN access also supported for devices on the same network.

5. UI delivery

Shared/FastChatUI.html is the front-end entrypoint. The README indicates the UI is offline-capable and “network proxied,” so the browser page is likely delivered from the local server along with bundled assets rather than pulling from external CDNs.

6. Model and asset configuration

Shared/config/models.json is the key metadata boundary for what models are available and how they are presented/selected. ui-vendor-assets.json likely maps which vendor UI assets/fonts/scripts must be bundled locally to keep the interface fully offline.

7. Supporting scripts

Shared/scripts/ contains operational helpers:

- download-ui-assets.sh / .ps1 for fetching local UI dependencies

- config_query.py for reading/querying configuration state

- uninstall-common.sh for shared cleanup

This suggests the repo separates one-time provisioning from runtime execution.

8. Persistent data boundary

The README’s folder architecture shows persistent state lives under Shared as shared storage, including:

- chat history

- generated images

- TTS outputs

- downloaded models

This is the data plane that survives across OSes and across launches.

9. Engine boundary

The README describes packaged local engines for LLMs, image generation, and TTS; these are treated as isolated binaries under the shared storage concept. The repository’s scripts likely install and launch those engines, but the engines themselves are external payloads rather than source code in this tree.

10. Execution flow

Typical flow is:

- run the OS install script

- download/extract shared assets, models, and engine binaries

- launch the OS start script

- the Python server starts

- the browser opens to the local UI

- UI actions are routed to local model engines and results are written back into shared storage

11. Operational constraints

The architecture is explicitly offline-first and air-gapped after setup. There is no cloud service dependency in the repo structure; the main runtime boundary is between local browser clients and the local Python/server-plus-engine stack.

12. How to diagram it

A good architecture diagram should show:

- three OS-specific launcher boxes feeding into one shared runtime

- a Python local server in the middle

- browser clients on localhost and optional LAN devices

- shared persistence/config/model storage underneath

- local AI engines as separate binaries behind the server