Gitea: an Issues App to list, read and report bugs #4

New Issue

2026-10-05T09:37:58Z

twisla commented

2026-10-05 09:37:58 +00:00

Idea

An App that talks to the project's Gitea (git.twis.la, twisla/roro9stack). It can list issues, filtered by state and label, and read an issue with its comments. It can also file a new one from the device, with the device's details filled in automatically.

Why

Bugs show up on the device, away from a computer. Reporting from where the bug happens, with the context attached, beats remembering it later.

What's known

API. Gitea's REST API v1: GET /repos/{owner}/{repo}/issues, GET …/issues/{n}/comments, POST …/issues. The repo is public, so listing and reading need no login. Creating an issue needs a token with the write:issue scope.
TLS is a new kind for this firmware.
- git.twis.la has a Let's Encrypt certificate (intermediate YE2).
- Trust on first use is wrong for a public certificate authority, so this needs real chain validation with a CA root on the device: either a couple of roots compiled in, or ESP-IDF's certificate bundle, which costs flash.
- Chain validation also needs a correct clock. We have one (GNSS > NTP), but it must be checked before connecting.
- Let's Encrypt is moving to new roots and shorter-lived certificates, so the choice of roots has to keep up.
Memory.
- It's another TLS connection, so the Q86 floors apply.
- Gitea's issue list JSON is large: the bodies are included, and so is a lot of metadata.
- We'll need a streaming JSON parser, or small pages (limit=10), keeping only the fields we display.
Bug reports with context. The App can fill in the firmware version (with +debug if it's a Debug Build), uptime, free and lowest heap, and the last crash record (reason, PC, backtrace, as in the Debug Console's crash). The user writes the title and description.
The token. It goes into NVS, like the debug token, never into the repo or the logs. It's entered in Settings, or put on the card once and read in.

Questions for the design round

Should it be read-only first, with filing issues as a second step, or both from the start?
Which fields go into a bug report automatically, and which does the user confirm before sending, so nothing gets sent unexpectedly?
Which certificates: ISRG roots compiled in, or the full ESP-IDF bundle (and how much flash does it cost)?
How do we enter the token: type it on the keyboard, read it from the card once, or push it through the Debug Console?
Should it handle only this repo, or also be configurable for other Gitea servers and repos?
Should the App work offline: draft an issue, keep it on the card, and send it when Wi-Fi is back?
Should it cover labels and comments: add a comment, or close an issue?

## Idea An App that talks to the project's Gitea (git.twis.la, `twisla/roro9stack`). It can list issues, filtered by state and label, and read an issue with its comments. It can also file a new one from the device, with the device's details filled in automatically. ## Why Bugs show up on the device, away from a computer. Reporting from where the bug happens, with the context attached, beats remembering it later. ## What's known - **API.** Gitea's REST API v1: `GET /repos/{owner}/{repo}/issues`, `GET …/issues/{n}/comments`, `POST …/issues`. The repo is public, so listing and reading need no login. Creating an issue needs a token with the `write:issue` scope. - **TLS is a new kind for this firmware.** - git.twis.la has a Let's Encrypt certificate (intermediate YE2). - Trust on first use is wrong for a public certificate authority, so this needs real chain validation with a CA root on the device: either a couple of roots compiled in, or ESP-IDF's certificate bundle, which costs flash. - Chain validation also needs a correct clock. We have one (GNSS > NTP), but it must be checked before connecting. - Let's Encrypt is moving to new roots and shorter-lived certificates, so the choice of roots has to keep up. - **Memory.** - It's another TLS connection, so the Q86 floors apply. - Gitea's issue list JSON is large: the bodies are included, and so is a lot of metadata. - We'll need a streaming JSON parser, or small pages (`limit=10`), keeping only the fields we display. - **Bug reports with context.** The App can fill in the firmware version (with `+debug` if it's a Debug Build), uptime, free and lowest heap, and the last crash record (reason, PC, backtrace, as in the Debug Console's `crash`). The user writes the title and description. - **The token.** It goes into NVS, like the debug token, never into the repo or the logs. It's entered in Settings, or put on the card once and read in. ## Questions for the design round 1. Should it be read-only first, with filing issues as a second step, or both from the start? 2. Which fields go into a bug report automatically, and which does the user confirm before sending, so nothing gets sent unexpectedly? 3. Which certificates: ISRG roots compiled in, or the full ESP-IDF bundle (and how much flash does it cost)? 4. How do we enter the token: type it on the keyboard, read it from the card once, or push it through the Debug Console? 5. Should it handle only this repo, or also be configurable for other Gitea servers and repos? 6. Should the App work offline: draft an issue, keep it on the card, and send it when Wi-Fi is back? 7. Should it cover labels and comments: add a comment, or close an issue?

twisla added the

concern/memory concern/security area/gitea labels 2026-10-05 09:37:58 +00:00

twisla referenced this issue

2026-10-05 09:37:58 +00:00

Updates: check Gitea for new releases and install them #6