Privacy first approaches

[Utzel-Butzel]

Here are some ideas to build a local mode which is more focused on privacy:

Website on ESP32

All the dithering is done on a website hosted directly on the ESP32
Similar to https://github.com/9carlo6/E-Paper

• No additional infrastucture needed

• Works only in same Wifi
• Slow and underpowered hardware
• No integrations possible

Local Mode

Use exisitng app, but without server infrastructure (e.g. do all the dithering locally). Could theoretically work in local Wifi/Bluetooth and avoid any server.

• No more server (data outside)

• Works only local
• Reduced functionality
• No integrations possible

Selfhosted

Our application can be completely self hosted and modified

• Same features as current app
• Same codebase
• Could work remotely

• Not as easy to setup
• Needs substantial refactoring

Privacy settings

Deleting the image after upload (only remains on the screen).

• Only temporary stored

• No way to see or edit the existing image in the app

Other ideas

End-to-end encryption to the frame?

[amigthea]

a self-hosted containerized image would be really awesome for those like me who runs an home lab, keep it up, amazing project

[kuechenwurzel]

I'd love to try this as well!

[Utzel-Butzel]

This one is related: paperlesspaper/paperlesspaper-firmware#2

By supporting a configurable update URL, the device could update from any endpoint, either local or remote (online). This would eliminate the need to manually flash firmware in most cases.

All configuration could be handled through a simple browser-based tool (using WebBLE), which could be hosted online or run locally. That would greatly simplify setup, while also making the system more flexible for advanced users and custom deployments.

[Utzel-Butzel]

Here is an update on the approaches:
There will be the (quick) option to have a little website to onboard new devices via Bluetooth and setup any image endpoint on the local network: paperlesspaper/paperlesspaper-firmware#2

And we will containerize the App/backend. I'm currently refactoring it so it will be more independent. There is no ETA yet for the full container setup.

[andreaslinke]

I'd vote for the "Local Mode" in a simplified form with fallback to the central server.

The benefit of the central paperlesspaper server is that it's always available. Local servers run by end users can crash, get mis-configured, IP addresses will change/never be reassigned, software gets outdated etc. If the device will only connect to the local server it can easily be bricked.

My suggestion would therefore be a two-fold approach: Add a new field "Prefer loading image from local endpoint" in the central web app configuration which is sent to the local device with every update, just like the sleep time. When the device wakes up, and has a local endpoint configured, it first tries to load an image from there. If it cannot do that (server not found, timeout, invalid payload etc), it will fall back to the central server and do everything as before, including loading an updated configuration.

On the local endpoint, you have a very simple server running which just serves a plain dithered image in the format expected by the device. This could even be just a python/node.js script. No configuration UI, no integrations etc. How the image is created is up to the end user. In the simplest approach, the local server would just read a jpg/png from the file system and convert/dither/serve it.

If the user wants to switch to a different configuration/new endpoint, they just stop the server and on the next cycle the device will not find the local server and connect to the central paperlesspaper server.

[amigthea]

the fallback solution you're suggesting should be absolutely optional, the maintenance of a local mode should be always on user responsibility. I do not want this kind of automated balancing where a local server/network misconfiguration could unpredictably lead to external connections, that would be blocked by my firewall either way, in a local-only scenario.

[andreaslinke]

In the fallback scenario the device would not get any privacy relevant data (unless you've uploaded such data to the central server). It would simply be able to get a new configuration, which for various reasons you might no longer be able to provide on the local endpoint, thus avoiding the brick/hard reset issue.
If the configuration on the central server is unchanged, it would try again against the local server after the next sleep time.

[amigthea]

that kind of mixed flow would be not possible in a forced offline environment, that is what I would like to achieve instead. I'm all for giving users the right to choose, but no outbound connection should be imposed for convenience

[kuechenwurzel]

I made a Claude Code attempt to get this achieved in a DYI approach, but had to give up when it could not figure various token/auth/API issues. I'd really, really like to have this running on a docker container on my NAS. Please make it happen. Or release enough of the specs for an LLM to figure out the details and spin up a local instance

[Utzel-Butzel]

Since a lot has been done on this side, can you please share an update @smarthomeagentur ? :)

[smarthomeagentur]

There is a offline firmware that supports multible ways to get data to the frame now. feature discussions and changes now in the firmware repo: https://github.com/paperlesspaper/paperlesspaper-firmware-offline