meshbay.git/packages/meshbay-hub/src/meshbay_hub/static/style.css, branch 0.14

fix(ui): sidebar stays above a phone's address bar and does not scroll the page

2026-09-15T00:21:01Z

Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01XuNrwLf5EFWCMHzfoEvnpm

feat(ui): an indexing dock above the music bar, on every page

2026-09-14T09:17:42Z

Adding a large directory left the operator nothing to look at once they left the Settings panel that started it, and nothing at all when it was added from another machine. A band now sits above the music bar on every page: one row per group with indexing under way, naming the root being walked, percent, bytes and files, and the roots waiting their turn; "indexing finished" for a few seconds at the end. A click opens the group's Settings, and × hides the row until that group is idle. Two sources feed it. On the node's own machine the desktop client polls the loopback `GET /api/index-status` for every group, whatever the route. An operator's group page forwards MNP `index_progress` pushes, resolving the root from the roots table it opened; an ordinary member keeps the sidebar dot only, and a page clears its row when it lets go of the group. Where both describe a group, loopback wins. Reconcile passes and watchdog bursts show only past 1 GB or 5 s, so a single dropped file does not flash a bar. The logic lives in index-dock-model.js, which has no imports and is tested under node. The dock publishes `--index-dock-h` and the sidebar stops above it and the music bar. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01T6jPTeocXA1BePekdsgPya

feat(hub): the mail state is a panel section, and a ceiling falling is an event

2026-09-12T14:36:54Z

The figure was a line beside the settings form, which is where it is changed and not where it is watched. It sits with the other live figures under Statistics now — four cards and, above them, a banner saying which of the two ceilings has fallen. The two states are not the same to whoever is reading: one means newcomers are turned away, the other means somebody locked out of their account cannot get back in. The settings block keeps a line pointing at it. And an operator no longer has to be looking. When a global ceiling is reached the administrators are notified — in `mail.py`, in its own session, never raising, because this runs while a request is being refused and an alert that fails must not turn a refusal into a 500. Once per hour, keyed on a row rather than a flag in memory: a flood is what spends the budget, so one alert per refusal would bury the message under its own cause, and a hub that is refusing mail is a hub somebody is about to restart. `/v1/admin/mail` gains `general_exhausted` and `all_exhausted` rather than leaving the panel to compare two numbers. Labels in all ten catalogues; `.warn-msg` for the middle state, on the `--warn` token both themes already define. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01T4YmK41VsEURWFdop4EEeT

feat(hub): the mail bounds are settings, with a panel to change them

2026-09-12T14:36:54Z

They were constants in two modules, so an operator could not touch them without editing code and redeploying — and the hour a budget runs out is not when anyone wants to do that. `[mail]` in hub.toml carries the defaults; the live values live in `hub_settings`, read at each use. A missing row falls back to what the configuration file says, so an instance that never opens the panel behaves as its file describes. The panel sends only what changed, the hub clamps each value to a stated range and refuses a key it does not know, and the response is what gets rendered — so a clamped value is never shown as stored. `GET /v1/admin/mail` is the other half. There was no way to see any of this: a refusal was a line in the journal, so an instance that had stopped sending sign-up codes looked, from the panel, exactly like one with no sign-ups. It reports the hour's use, what is left for sign-ups, and what is left for recovery — the difference between those two being the reserved share made visible. Labels in all ten catalogues. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01T4YmK41VsEURWFdop4EEeT

feat(hub): legal information link at the foot of the sidebar

2026-09-11T11:57:34Z

A small link to the hub's legal pages, pinned to the bottom of the sidebar once signed in. It opens in a new tab: the desktop application refuses to navigate away from its interface and hands a new window to the system browser, and in a browser it keeps the session on screen. The address comes from hubBase(), so it is the legal pages of the hub in use. The sidebar now sticks under the navigation bar at the window's height; otherwise, on a long file list, the link would sit at the bottom of the page. The music bar, pinned to the bottom of the window as well, publishes its height through useStickyBand as --music-bar-h and the sidebar stops above it. On a phone the slide-out panel does the same. test_sidebar_legal_measured.py measures the real stylesheet: the link at the bottom of the window on a 3000px page, and above the music bar, at phone and desktop widths. Checked signed in on a local hub in Chrome and Firefox 155. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01D9MCBBWSm9GhBESmqzJxNy

feat(hub): say what MeshBay is on the sign-in page

2026-09-11T11:05:21Z

The browser sign-in page now carries the project's pitch beside the form: what MeshBay is, the applications, what it is for, and what meshbay.org does and never sees, with links to the downloads and the legal pages. Text on the left and the form on the right on a desktop; one column, form first, below 1000px. Not shown in the desktop application, whose user has already downloaded it. All ten catalogues carry the text. Every claim is held to MESHBAY_DESIGN.md 2.3: the page says content never reaches the hub, not that the hub can read nothing (T3), and "end-to-end" means device to node. Signed out there is no sidebar, so the 960px main column sat at the left of the window and the sign-in, register and reset forms were centred in it (x=290 in 1440). `.page-center` pages now lift that cap. test_welcome_layout_measured.py measures the real stylesheet in Chrome: no horizontal overflow from 320 to 1440px, form first on narrow screens, form right of the text on desktops, pair centred in the window. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01D9MCBBWSm9GhBESmqzJxNy

fix(hub): a pinned band's ring stops eating the form above it

2026-09-10T10:19:30Z

The tab bar paints an opaque ring of page colour around itself, `--band-margin` wide, so the gap it keeps in the flow is still there once it pins. A box-shadow spread goes out on all four sides, and above the tab bar there is only whatever the element before it happened to leave: the join-code form under a group's title leaves 12px, the ring is 16px, and the form came back with the bottom 4px of its field and its button painted over — page colour at z-index 30, against content that has none to answer with. Reported as "the form is slightly cut off", which is exactly what it looks like and says nothing about a stylesheet. The same 4px went off the bottom of the "could not reach this node" banner, the other thing that stands between a group's title and its tabs. The band reserves that room itself now. `* +`, so it is the gap between two elements rather than a margin the band always carries: `.search-bar` is a first child on the Search page, and a margin-top there would collapse through the page root and take the whole page down with it. Between siblings the two margins collapse to the larger of the pair, so everywhere that already leaves enough is untouched and only what was being painted over moves. Only the two bands that pin against the navigation bar, and that is the rule rather than an economy. Written for all six it fails 22 of the sticky-header cases: the gap *between* two bands is the upper one's `--band-margin` and nothing else — the number `--chrome-h` carries and the offset the lower band pins at — so a lower band's own margin-top wins the collapse wherever it is the bigger of the two and leaves the flow layout wider than the pinned one, at every phone width in every media view. A band under another band needs no room above it anyway: what is there is a band of higher z-index, which a ring cannot paint over. Measured against the shipped GroupPage in the state that was reported — a node answering `code_required` — in Chrome: 12px of clearance under a 16px ring before, 16 against 16 after. test_sticky_band_ring.py holds the two selector lists together out of the source rather than in a browser, because what a browser shows is the 4px at one width in one of the states that happen to put something above a band, while what has to hold is which bands are in which list. docs/apps.md sends the author of a new application to that section to make its toolbar pin; this is what says the toolbar they add does not get the gap, and why. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01BAJawZ25MZPBJ7TKgnVA1n

feat(hub): pin the app controls while a library scrolls

2026-09-10T08:29:12Z

Files, Videos, Music and Photos are read by scrolling, and everything that steers that reading left with the first screenful. Three bands now pin under the navigation bar, in a group and on the Search page alike: the tab bar (the search field, on Search), the application's own toolbar, and the file table's column heads. The group's name and description still scroll — they say nothing a reader needs while walking a directory, and the height they would cost is height the list does not get. A band's offset is the heights of the bands above it, and those are not constants: the toolbar wraps to three rows on a phone, grows a field while a folder is being named, and loses its filter on Search. So each band measures itself and publishes `--chrome-h` / `--toolbar-h` (static/sticky.js) and the stylesheet does the arithmetic in calc(), rather than a number written down twice — the fault CLAUDE.md already records against this layout twice over. A band publishes height *plus its own bottom margin*, and paints that margin as a ring of page colour, so the pinned layout is pixel-identical to the flow layout and nothing shifts at the moment a band pins. Three overflow faults came out of it, all of the same class and all of them what "the header does not stay" actually meant on Android — a document wider than the screen leaves everything pinned attached to a viewport the reader can no longer see, the navigation bar included: - a directory's name cell was a bare , so an unbreakable folder name (`Rage_Against_The_Machine_Discography_1992-2000_FLAC`) set the column's minimum: a 527px table in a 390px window - Search's group column did the same at 442px with an underscored group name. It also goes entirely below 768px, where there is no room for it and the breadcrumb already names the group - the shared-directories table has four columns of controls with a combined minimum near 440px, none of it compressible. On a phone the row stops being a row: the name and its eject/remove pair on one line, the two switches — each carrying the column head's own string as a label — on the next - and, found by measuring at 360px, the tab bar itself was 19px too wide `.file-table` moves to separated borders: a collapsed border belongs to the table rather than to the cell, so the column heads lost their rule the moment they pinned. Measured, not read. tests/harness/sticky_header_probe.py drives the shipped GroupPage and SearchPage against a stub node, walks to each application, scrolls to the end and reports every rectangle — 11 views x 4 widths x 2 engines. Its fixture says what real data says: the first version used `note-007.txt` and `un groupe`, which fit any screen, and found none of the above. A fixture narrower than real data tests the fixture. Also: `test_desktop_shell` no longer looks for the CSP after the first `-->`, which made it fail on correct markup as soon as a comment was added above it, and `search-page.js` joins test_hook_ordering's file list. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Tx16FhyD2BUdpooGb5jcyN

fix(spa): say why a download cannot be paused

2026-09-09T12:24:59Z

Reported from Chrome, with a screenshot: four downloads with no pause button and an upload beside them with one, and nothing anywhere saying why. The reason is real. Without a granted download folder the browser writes through the service worker — a download it already owns, which cannot be paused without stalling it somewhere we can neither see nor resume. An upload writes to the node, which keeps the position, so it is always pausable. But that was stated only in a Settings line nobody reads on the way to a download, and a gap where the row above has a button is not an explanation. So a download that cannot be paused now shows a dimmed pause icon where the button would be, carrying the reason and the remedy in its tooltip. Not a button: there is nothing to click, and a disabled one invites the click anyway. And only where the advice can be taken. Firefox and Safari have no folder to choose — the streamed path is the only target they have, which is what §6.5 of ~/next/improve-downloads.md costs out — so telling someone there to choose one would be advice they cannot follow. Nothing is drawn. Hub suite 866 passed. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01HCGdheDLxGReuKHga3BtST

feat(spa): pause and resume a download, in session

2026-09-09T08:48:49Z

Stage 7a of ~/next/improve-downloads.md: pausing within a session, on the targets that can actually do it. Resuming across a reload is 7b. A paused transfer holds **nothing**. Its slot goes back to the node the moment it stops and resuming rejoins the queue at the tail, because anything else lets one member close a node by pausing four downloads and going to lunch. So the lease is taken inside the run loop rather than before it, and pause is refused outright for a transfer that could not ask for another one. Resuming is exact rather than approximate: the pipeline stops between two chunks and never inside one, so what is on disk is always a whole number of chunks and `fromChunk` is a verified position. The failure mode being avoided is a file that looks complete and is quietly corrupt. The target has to survive it, so a pause no longer reaches the `abort()` that a failure does -- that would delete Electron's `.part` or the file just created in the granted folder, leaving nothing to continue. And the in-memory fallback keeps its accumulated chunks rather than starting a second array. The button is drawn only where the target says it can. A service-worker stream says no, in its own code and for its own reasons: the browser is already writing an HTTP response into its own download folder, not feeding it stalls that download where we cannot see or resume it, and an idle worker is terminated within seconds. Firefox and Safari therefore keep cancel and get no pause, which is the decision recorded in §6.5. Cancelling a paused transfer ends it. A paused run is parked on a promise; without waking it the row said "cancelled" over work that had not stopped and a target that was still open. Six cases, each checked against the unfixed source. Hub suite 842 passed. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01HCGdheDLxGReuKHga3BtST