Apps Hub

What Apps Hub is

Apps Hub is the public-facing layer of a self-hosted mvmOS installation. It lets selected installed apps be used outside the administrator’s Linux desktop: from a normal browser, a phone, a standalone public page, or an installable PWA. It is the boundary between private server administration and the public experiences an app chooses to offer.

Public pages are separate from the desktop

A visitor to a public app does not receive a Linux account, a desktop session, Terminal access, or access to the server filesystem. Public users sign in to an Apps Hub profile that belongs only to that self-hosted installation. An administrator decides which installed apps may have a public page and can turn each public app on or off. When a public page is off, direct visits receive a clear private-page notice instead of the app content.

Public profiles

Apps Hub provides lightweight profiles for people using public pages. A profile can have a username, display name, avatar, language, theme, font-size, date format, time format and currency preferences, favourites, notifications, and a session token. These display and regional choices follow the account between devices and are available to public apps, while leaving the browser or installation defaults in place until the profile chooses an override. Self-registration can be allowed or closed by the installation administrator; administrators can also create, edit, remove, or promote public profiles from Apps Hub.

The administrator can separately allow invitations. Each signed-in public user can then create a single-use registration link that expires after seven days, with up to 20 unused invitations at a time. Invitations may be used while public registration is open, or the administrator can close public registration and leave invitations enabled to make new accounts invitation-only. Used, expired, disabled, or otherwise invalid links cannot create an account. A user's own invitations are listed in the Invitations tab of the public Apps Hub page, reached from the profile menu: links still waiting show when they expire and can be copied again, accepted ones show who registered with them, and any invitation can be deleted, which stops a waiting link from working while an account created with it stays.

Public app directory and PWA

The Apps Hub public portal lists the apps that the administrator has enabled for public access. It is installable as a PWA, so it can be added to a phone or desktop home screen. Public app pages can also have their own standalone PWA; this is intentionally separate from the main mvmOS desktop PWA described in Mobile and PWA.

An app whose public endpoint only answers requests from another page, such as statistics fetched by another application, is not offered as a public page to switch on. Its author marks it with "public_api_only": true in the app's manifest, and it keeps working wherever that other page uses it.

The Clipboard is a built-in app with a public page of its own, so it appears in this directory as soon as the administrator enables it. It lets a profile move text, photos and files between a phone and the computer; see Clipboard.

Each profile chooses its own home screen

The public portal has two views of the same list. **Apps** is the profile’s own home screen; **Store** is everything the administrator has published, grouped by category, with a description for each app. Search in Store finds apps across all categories. Adding an app from the Store puts it on the home screen, removing it takes it off again.

Removing is only hiding: nothing the app stored for that profile is deleted, and adding the app back returns it exactly as it was. A brand-new profile starts with an empty home screen and builds it from the Store; profiles that were already using apps keep the ones they had opened.

The chosen apps, the sort order and the selected category belong to the profile and are kept on the server, so the same account sees the same home screen on a phone and on a computer. Set the Apps sort order under Settings → Apps. Favourites are available from the profile menu in the shared header.

Switching public apps

The app button in the shared public header opens Home and up to ten apps from your own home screen, following its selected category and alphabetical, recent or frequent order. The current app is also shown when it falls outside that list. Visitors without a profile see published apps alphabetically. Opening an app here updates its usage history, and the menu closes with Escape or a tap outside.

Profile searches match names without case differences in any script, including Cyrillic.

Community

Community is a tab of the public Apps Hub page where signed-in profiles of the same installation share with each other. It is closed: nobody outside the installation sees a post, and the author chooses who may. A post can be free text (links and YouTube addresses are recognised), up to four photos of up to 10 MB each, or a repost of someone's post. Others can like, comment on and repost it, and the author is notified of each. A red dot on the Community tab shows that others have shared something since the profile last looked, and older posts load on demand.

Each post has an audience: everyone with a profile, only the profile's favourites, or chosen people searched by name; chosen people are notified. Only posts for everyone can be reposted. The audience new posts start with is set in Settings under Sharing, and can still be changed for each post.

Every public app page has a New post button in the shared header. It opens the composer from inside the app, and offers the recent things the visitor did in that app, such as adding a listing or logging a drink, as values to put into the text, so a post can be written in a moment. The list of recent activity is kept only in the visitor's own browser, is shown only to them and can be cleared. Texts can be saved as templates for an app, up to 50 for each app. Apps do not have to be written for this and none is named in it.

The public Settings page is split into sections: Appearance, Apps, Language and formats, Sharing, and, for profiles that have it, the API. Links to the API open that section.

What is happening now

When an app reports live activity for a profile, a compact panel appears under the header of every public page, for example an app timer with its title and a clock that keeps counting. Tapping it opens the app. A running timer always appears first. If several timers are running, the one most recently started or resumed appears first. When no timer is running, the most recent activity appears first. A +N button reveals the other items. The panel is only there while there is something to show and it belongs to the profile alone; nobody else sees it.

An app takes part by offering a get_live_activity function in its app API, and it is shown only for apps that the profile keeps on its home screen. It can provide ISO timestamps as started_at for a running timer and activity_at (or created_at) for other activity so Apps Hub can place the newest item first. The administrator's app-to-app switch is not needed, because the profile only reads its own data on its own page. An item can also carry compact buttons beside the timer — pause, resume, stop or done — each naming a function of the same app. The page can only run a button the app offered a moment before for that profile. The function is for the page itself and is not listed in the External APIs or in Automations.

App-to-app communication

Apps Hub is also the switchboard for server-side app-to-app calls. An app may expose a small app_api.py surface, but Apps Hub keeps that API disabled until the administrator enables it for the target app. Calling apps use the central Apps Hub API rather than importing another app directly, so the permission gate remains enforceable. For any app that exposes one, Apps Hub also lists the individual actions it makes available — name, parameters, and a short description read straight from the function's own docstring — so an administrator can see exactly what an integration would be able to call before enabling it.

Enable an app API only when there is a concrete integration to support. It is a server-side trust decision: public-page access and app-to-app API access are separate controls.

With the External APIs Premium module, an administrator can separately open selected Store app APIs to scripts and programs outside mvmOS. A public app must be enabled in Apps Hub before it can be opened this way. Public profiles then see an API tab and make their own tokens, each limited to the functions selected for it; on installations without the module, the tab is absent entirely.

Credits for public users

Credits are an optional Apps Hub Premium module for an installation. When the Credits module exists, each public profile has a balance and a visible transaction history. The feature is absent entirely on an installation without that module; public users do not see a purchase prompt.

An administrator can open any public user’s credit panel, add credits, deduct credits, provide a reason, and review the transaction history. Credits are not a payment processor: they are a balance controlled by the administrator of that self-hosted installation.

The same Premium module lets an administrator assign a separate public display name to Apps Hub or any published app. The custom name appears in the public page title, Apps Hub directory, and navigation while the internal app identifier and URL remain unchanged. On an installation without the module, the rename control remains visible in the desktop but opens the Premium prompt; public pages simply use the original app names.

Free versus credit-priced features

An app can declare the features or services that it is able to charge for. In the **Paid Apps** tab of the Apps Hub window, the administrator sees every installed app that declares such a feature, whether or not the app has a public page, and chooses the price for each one:

• A price of 0 keeps that feature free for public users.
• A positive price makes the app deduct that number of credits when the user chooses the feature.
• The administrator can change a price later without changing the app code.

Apps use the central credit service to charge or grant balances. Charges are atomic and idempotent, which prevents a retried request or two simultaneous requests from charging the same action twice. An app can also grant credits for a reward, correction, refund, or other workflow chosen by the installation administrator.

Browser extensions

Some installed apps can provide a companion browser extension. mvmOS generates the shared extension shell from the app’s declared metadata and can target Chrome and Firefox. The extension connects to the user’s chosen self-hosted mvmOS server; it is not a browser extension operated by a central mvmOS cloud.

Apps Hub has its own extension, mvmOS Apps, offered from the extension button in the Apps Hub window. Its popup shows the Apps Hub public page of your server, with the usual header, so you can move from one public app to another inside the popup, and it reopens on the page you were on last time; the home button returns to Apps Hub. A public app shown in it can learn which site the current browser tab is on and, when you ask it to, read that page as you see it. It can also ask to read up to twenty other pages of the same site, one after another in that tab, as you see them when signed in there. Before that, the popup lists the pages and asks you, and you can allow it once or for that app on that site from then on. Outside the extension, public pages behave as before.

Extensions request only the permissions declared by the app. Review the app’s extension description, browser permissions, host permissions, and supported browser versions before installing it.

Operating Apps Hub safely

• Enable public pages only for apps that are ready to be exposed.
• Use HTTPS for all public pages.
• Close public registration when you do not need new accounts.
• If invitations are enabled, treat invitation links as temporary registration credentials and share them only with their intended recipient.
• Enable app-to-app APIs only for the specific integration you intend to use.
• Treat public-user administration and credit changes as sensitive operational actions.
• Review browser extension permissions before installation.