emanuel@labonneheure.ch@Hubzilla Support Forum In order for us to follow, we need more exlanation from you:
- What is the goal of this project?
- Which use cases is it aimed for?
- What are its advantages and disadvantages compared to the full-php-version of Hubzilla?
- Is it meant to become a community project? If yes, inficate source code management (licence, repository, review mechanism)
- Please provide a glossary to the words you use which are unfamiliar to most of us. You did enter a common ground here in this forum channel. Please start from that common ground and guide us into the territory which is not known to us. Such an empathic approach would not only be appreciated by all of us and raise our interest, but is inherent to the Hubzilla community culture. Thank you for your cooperation. 💪🏽
yani@smarteditor.io
# Peacepharm → Hubzilla core: a few things you might want
We run a Hubzilla fork (**peacepharm**) and have built a stack of enhancements on top of it.
This isn't a PR drop or a demand on your time — it's an offer. **Have a look; if any of it is
useful, it's yours**, and we'll do the work to shape that piece into a clean, mergeable form
against current core. Everything below points at real files so you can judge for yourself.
We've tried to be honest about the two things you actually care about: **how invasive** each
change is, and **whether it needs anything external to work.** Where a feature only shines with
one of our out-of-band Rust daemons, we say so plainly rather than dressing it up.
One up-front correction so we don't waste your time: we do **not** have a global pushState SPA
router, and stock live-feed AJAX is untouched. When we say "fewer page reloads" we mean we
replaced *specific* full-page flows with in-place swaps — not that the app became a SPA.
---
## The easy wins — theme + one addon, no external dependencies
### 1. In-place AJAX for the flows that hurt most
We left stock Hubzilla AJAX alone and replaced the *specific* full-page navigations that grate:
- **Compose preview in a modal** — including an interactive image-resize (drag/double-click)
that rewrites the `[img]/[zmg]` BBCode width/height back into the editor.
- **Inline post edit** — pulls the post back into the jot editor without leaving the page.
- **Editor settings as an overlay** instead of navigating to `/settings/editor/`.
- **Apps browser as an offcanvas card grid** with search + AJAX install/pin/feature/delete.
- **Delivery report, connection profile (slide-in), bug report** — all modal/overlay.
*Where:* `theme/peacepharm/js/pp.js`, `theme/peacepharm/php/theme.php`.
*Why care:* removes the jarring full reload from the highest-frequency actions.
*What we'll own:* much of `pp.js` defensively DOM-patches Redbasic markup (MutationObservers,
class-hunting). You'd want the **ideas re-done against templates**, not a verbatim copy — we're
happy to do that reshaping.
### 2. Extended BBCode editor toolbar via a clean hook
Strikethrough, headings, lists, video, table, hr, spoiler, size, color — injected **server-side
through a `jot_tpl_filter` hook** (not a template fork), with JS insert helpers and a
simple/advanced toggle persisted client-side.
*Where:* `addons/pp_admin_api/pp_admin_api.php:53-116`, `pp.js`.
*Why care:* a richer default editor, added the clean way — a hook, not a patch.
### 3. `Zotlabs\Extend\Route` — a small addon-routing helper
A register/unregister API for addon routes with path normalization. **Pure PHP, zero external
dependency.** Every one of our addons uses it.
*Where:* `zotlabs/Extend/Route.php`.
*Why care:* nicer addon-route ergonomics; the single most trivially-mergeable item here.
### 4. A free bugfix — take this regardless of the rest
`Zotlabs/Module/Regate.php:118` uses **logical `&&` where bitwise `&` was intended** on the role
bitmask: `($isa['account_roles'] && ACCOUNT_ROLE_ADMIN)`. We found it with our own
comment-search tooling. Nothing to merge from us — just a fix worth making.
---
## Optional performance backends — self-contained PHP, external daemon required
Drop-in implementations of standard interfaces that offload work to Rust daemons over unix
sockets. Mergeable as **opt-in** handlers; the benefit needs the daemon, so they'd land disabled
by default. Even if you never run our daemons, the socket-offload pattern may be useful to see.
- **`SessionRust`** — a `SessionHandlerInterface` backed by a Rust session store (sensible TTLs,
fails open on connect error). `zotlabs/Web/SessionRust.php`
- **`RustImage`** — ImageMagick-processing offload. `zotlabs/Lib/RustImage.php`
- **`rust_delivery`** — offloads zot6 federation delivery via the `queue_deliver` hook.
`addons/rust_delivery/`
*Why care:* session storage, image processing, and delivery are classic PHP hot spots; these are
clean, isolated examples of moving them off the request path.
---
## Self-contained addons — mergeable, but need external services
- **`ai_moderation`** — user flag flow + AI moderation queue + poster-response (edit/explain/
delete), banner injected via the `prepare_body_final` hook.
- **`bug_report`** — in-app bug submit / list / respond.
- **`hubzilla_xmpp`** — an in-page messenger widget. Real-time is delegated to **Prosody**
(BOSH/websocket) — we did **not** add a websocket to core — and it needs an `xmpp_tokens`
table. Mergeable as an optional addon, not a drop-in.
---
## Anti-abuse: registration hardening — higher effort, but the primitive is worth it
Live on our hub: **honeypot + timing + signed-stamp** guards on the signup path, enforcing
`max_daily_registrations` / `invitation_only`, fail-open with logging (plus an nginx blocklist +
`limit_req` outside PHP).
*Honest cost:* these are **patches to stock `Register.php` and `view/tpl/register.tpl`**, so they
must be reapplied on update — the harder-to-merge category. But the honeypot/timing/signed-stamp
guard is a genuinely upstreamable anti-bot primitive if you'd want it as a **core feature** rather
than a patch. We'd happily rebuild it that way.
*Also worth knowing:* invite-links-with-preapproval turned out to be **already in core**
(`Regate.php`, `Register.php`, `Invite.php`) — for us it was a config change (`invitation_also=1`),
not new code. Flagging so you don't think we're re-pitching something you already ship.
---
## One integration pattern, offered as an idea only
We surface a per-session token via `<meta name="pp-atom-token">` in `theme.php` (2 lines) that
lets browser JS call a single uniform command bus with client-side caching and idle preload. The
backend engine behind it is a **separate product of ours and NOT something we're pitching to
core.** But one small, self-contained piece might interest you independently: **a same-origin
route that mints a short-lived token from the existing session cookie**, so surfaces served
outside Hubzilla can still authenticate against the session. Clean, scoped, no engine required.
---
## What we are explicitly NOT pitching
To keep this honest: our desktop apps, a browser extension, a TTS/STT daemon, and the "atom"
server itself are **separate products, not Hubzilla changes.** Only their thin Hubzilla-facing
hooks (above) are in scope. We'd rather under-claim than send you chasing code that isn't a
Hubzilla patch.
---
## If you want any of it
Point at any line item and we'll shape that piece into a clean PR against current core —
de-forked, template-based where it belongs, opt-in where it needs a daemon. No obligation and no
hard feelings if the answer is "no thanks" — we just figured some of this might save you work.