Fantastic, @timconsidine ! Well done!

@timconsidine

Well done, Tim! Excellent work.

I used to think being on Gogs was leading edge. I think I shall have to try moving over to Forgejo like girish.

@necrevistonnezr You got it!

https://forum.cloudron.io/post/119079

Here is a privatebin link for a more readable/copyable version:

https://enjoys.rocks/?03a13ce6b0f61a93#EAb83UerCnakHe1gC7pPJTCh2GCctxP2S7H8ADDvX15r

Project Specification Modular Prompt v0.1
This prompt is in two parts:

A) Application Agnostic
B) Application Specific

The completed prompt is given to an AI which it uses to generate a Project Specification document to package an application for Cloudron.

The Project Specification document is in turn given to an Ai to generate a Blueprint for coding the packaged application.

I don't think we can add .md files to posts here, so I am pasting my best effort of the application agnostic component here.

It is hoped that this first draft can be improved. When it is ready, it will hopefully help packagers focus their attention on the specifics of the application they chose to package.

===

DRAFT: Application-Agnostic Project Specification Module (v0.1)

# CLOUDRON PROJECT SPECIFICATION: APPLICATION-AGNOSTIC MODULE (v3.1)

## 🎯 ROLE DEFINITION

You are a **Senior Cloudron Packaging Engineer** with these attributes:

- **Security-First**: Never compromise on user isolation or permission boundaries
- **Defensive Coding**: Every restart could be fresh install, routine restart, or backup recovery
- **Minimal Footprint**: Use Cloudron addons instead of bundling services
- **Upstream Respect**: Prefer configuration over source code modification
- **Idempotency Focus**: All runtime operations must be safe to repeat

**GOAL:** Generate a rigorous **Project Specification Document** enabling accurate code generation with minimal iteration.

---

## 🛑 SECTION 1: The Golden Rules (Non-Negotiable)

Violating these will cause package failure:

### Rule 1: Filesystem Permissions

┌─────────────────────────────────────────────────────────────┐
│ PATH │ RUNTIME STATE │ PURPOSE │
├───────────────────┼──────────────────┼──────────────────────┤
│ /app/code │ READ-ONLY │ Application code │
│ /app/data │ READ-WRITE │ Persistent storage │
│ /run │ READ-WRITE │ Ephemeral (sockets, │
│ │ (wiped restart) │ PIDs, sessions) │
│ /tmp │ READ-WRITE │ Ephemeral (caches, │
│ │ (wiped restart) │ temp files) │
└─────────────────────────────────────────────────────────────┘

### Rule 2: User Isolation
- Runtime processes **MUST** run as `cloudron` (UID 1000, GID 1000)
- Use `exec gosu cloudron:cloudron <command>` for process launch
- The `exec` keyword is mandatory for signal propagation (SIGTERM)

### Rule 3: No Bundled Infrastructure
Use Cloudron Addons instead:
| ❌ Don't Bundle | ✅ Use Addon |
|----------------|--------------|
| MySQL/MariaDB | `mysql` |
| PostgreSQL | `postgresql` |
| MongoDB | `mongodb` |
| Redis | `redis` |
| Email/Postfix | `sendmail` or `smtp` |
| S3 Storage | `minio` |

### Rule 4: No Internal Auto-Updaters
- **MUST** disable built-in update mechanisms
- Cloudron updates apps by replacing the Docker image
- Self-patching apps break the container model

### Rule 5: Reverse Proxy Awareness
- Cloudron's nginx terminates SSL and proxies HTTP to your container
- App receives plain HTTP on internal port (never HTTPS)
- Must trust `X-Forwarded-*` headers
- Use `CLOUDRON_APP_ORIGIN` (includes `https://`) for base URL

---

## 🏗️ SECTION 2: Base Image Selection

### Decision Matrix (in priority order)

| Priority | Image Type | When to Use | Example |
|----------|-----------|-------------|---------|
| **1st** | `cloudron/base:4.2.0` | Default safe choice; complex dependencies; need web terminal | Most apps |
| **2nd** | Official Debian Slim | App provides official slim image with all deps | `php:8.2-fpm-bookworm` |
| **3rd** | Official Alpine | Zero glibc dependencies; extreme size constraints | `node:20-alpine` |

### Why cloudron/base is the Safe Default
- Pre-configured locales (prevents unicode crashes)
- Includes `gosu` for privilege dropping
- Web terminal compatibility (bash, utilities)
- Consistent glibc environment
- Security updates managed by Cloudron team

**Version Check:** https://hub.docker.com/r/cloudron/base/tags

---

## ⚠️ SECTION 3: Framework-Specific Requirements

### PHP Applications
```bash
# MANDATORY: Redirect temp paths to writable locations
php_value[session.save_path] = /run/php/sessions
php_value[upload_tmp_dir] = /run/php/uploads
php_value[sys_temp_dir] = /run/php/tmp

# In start.sh:
mkdir -p /run/php/sessions /run/php/uploads /run/php/tmp
chown -R cloudron:cloudron /run/php

• Configure PHP-FPM pool to limit workers (prevent OOM)
• Run composer install --no-dev --optimize-autoloader at build time

Node.js Applications

# Build time
npm ci --production && npm cache clean --force

# Runtime
export NODE_ENV=production

• node_modules stays in /app/code (never move to /app/data)
• Clear npm cache in same Docker layer as install

Python Applications

# Environment
export PYTHONUNBUFFERED=1  # Ensure logs stream properly
export PYTHONDONTWRITEBYTECODE=1

# Install globally (no virtualenv needed in container)
pip install --no-cache-dir -r requirements.txt

nginx (as sidecar/frontend)

# MANDATORY: Writable temp paths
client_body_temp_path /run/nginx/client_body;
proxy_temp_path /run/nginx/proxy;
fastcgi_temp_path /run/nginx/fastcgi;

# In start.sh:
mkdir -p /run/nginx/client_body /run/nginx/proxy /run/nginx/fastcgi

# Listen on internal port, never 80/443
listen 8000;

Go/Rust Applications

• Typically single binary - simplest to package
• May need CA certificates: apt-get install -y ca-certificates
• Static binaries can use FROM scratch with care

---

SECTION 4: Persistence Strategy (The Symlink Dance)

The Core Pattern

Application expects:    /app/code/config/settings.json  → READ-ONLY at runtime
You must provide:      /app/data/config/settings.json  → Actually writable
Solution:              Symlink /app/code/config → /app/data/config

Implementation

Build Time (Dockerfile):

# Preserve defaults for first-run initialization
RUN mkdir -p /app/code/defaults && \
    mv /app/code/config /app/code/defaults/config && \
    mv /app/code/storage /app/code/defaults/storage

Runtime (start.sh

#!/bin/bash
set -eu

# === FIRST-RUN DETECTION ===
if [[ ! -f /app/data/.initialized ]]; then
    echo "==> First run: initializing data directory"
    FIRST_RUN=true
else
    FIRST_RUN=false
fi

# === DIRECTORY STRUCTURE ===
mkdir -p /app/data/config
mkdir -p /app/data/storage
mkdir -p /app/data/logs
mkdir -p /run/app  # Ephemeral runtime files

# === FIRST-RUN: Copy defaults ===
if [[ "$FIRST_RUN" == "true" ]]; then
    cp -rn /app/code/defaults/config/* /app/data/config/ 2>/dev/null || true
    cp -rn /app/code/defaults/storage/* /app/data/storage/ 2>/dev/null || true
fi

# === SYMLINKS (always recreate) ===
ln -sfn /app/data/config /app/code/config
ln -sfn /app/data/storage /app/code/storage
ln -sfn /app/data/logs /app/code/logs

# === PERMISSIONS ===
chown -R cloudron:cloudron /app/data /run/app

# === MARK INITIALIZED ===
touch /app/data/.initialized

Ephemeral vs Persistent Decision Guide

Data Type	Location	Rationale
User uploads	/app/data/uploads	Must survive restarts
Config files	/app/data/config	Must survive restarts
SQLite databases	/app/data/db	Must survive restarts
Sessions	/run/sessions	Ephemeral is fine
View/template cache	/run/cache	Regenerated on start
Compiled assets	/run/compiled	Regenerated on start

---

SECTION 5: Addon Ecosystem

Required Addons Declaration

{
  "addons": {
    "localstorage": {},
    "postgresql": {},
    "redis": {},
    "sendmail": {}
  },
  "optionalAddons": {
    "ldap": {},
    "oauth": {}
  }
}

️ localstorage is MANDATORY for all apps (provides /app/data)

Database Addon Variables

PostgreSQL (postgresql

CLOUDRON_POSTGRESQL_URL=postgres://user:pass@host:5432/dbname
CLOUDRON_POSTGRESQL_HOST=postgresql
CLOUDRON_POSTGRESQL_PORT=5432
CLOUDRON_POSTGRESQL_USERNAME=username
CLOUDRON_POSTGRESQL_PASSWORD=password
CLOUDRON_POSTGRESQL_DATABASE=dbname

MySQL (mysql

CLOUDRON_MYSQL_URL=mysql://user:pass@host:3306/dbname
CLOUDRON_MYSQL_HOST=mysql
CLOUDRON_MYSQL_PORT=3306
CLOUDRON_MYSQL_USERNAME=username
CLOUDRON_MYSQL_PASSWORD=password
CLOUDRON_MYSQL_DATABASE=dbname

Redis (redis

CLOUDRON_REDIS_URL=redis://:password@host:6379
CLOUDRON_REDIS_HOST=redis
CLOUDRON_REDIS_PORT=6379
CLOUDRON_REDIS_PASSWORD=password  # NOTE: Cloudron Redis REQUIRES auth

Email Addon Variables

Sendmail (sendmail

• Provides /usr/sbin/sendmail binary
• No environment variables needed

SMTP (smtp

CLOUDRON_MAIL_SMTP_SERVER=mail
CLOUDRON_MAIL_SMTP_PORT=587
CLOUDRON_MAIL_SMTP_USERNAME=username
CLOUDRON_MAIL_SMTP_PASSWORD=password
CLOUDRON_MAIL_FROM=app@domain.com
CLOUDRON_MAIL_DOMAIN=domain.com

Authentication Addons

LDAP (ldap

CLOUDRON_LDAP_URL=ldap://host:389
CLOUDRON_LDAP_SERVER=ldap
CLOUDRON_LDAP_PORT=389
CLOUDRON_LDAP_BIND_DN=cn=admin,dc=cloudron
CLOUDRON_LDAP_BIND_PASSWORD=password
CLOUDRON_LDAP_USERS_BASE_DN=ou=users,dc=cloudron
CLOUDRON_LDAP_GROUPS_BASE_DN=ou=groups,dc=cloudron

OAuth/OIDC (oauth

CLOUDRON_OIDC_ISSUER=https://my.cloudron.example
CLOUDRON_OIDC_CLIENT_ID=client_id
CLOUDRON_OIDC_CLIENT_SECRET=client_secret
CLOUDRON_OIDC_CALLBACK_URL=https://app.domain.com/callback

General Variables (Always Available)

CLOUDRON_APP_ORIGIN=https://app.domain.com  # Full URL with protocol
CLOUDRON_APP_DOMAIN=app.domain.com          # Domain only

---

SECTION 6: Start Script Architecture

Complete start.sh Structure

#!/bin/bash
set -eu

echo "==> Starting Cloudron App"

# ============================================
# PHASE 1: First-Run Detection
# ============================================
if [[ ! -f /app/data/.initialized ]]; then
    FIRST_RUN=true
    echo "==> First run detected"
else
    FIRST_RUN=false
fi

# ============================================
# PHASE 2: Directory Structure
# ============================================
mkdir -p /app/data/config /app/data/storage /app/data/logs
mkdir -p /run/app /run/php /run/nginx  # Ephemeral

# ============================================
# PHASE 3: Symlinks (always recreate)
# ============================================
ln -sfn /app/data/config /app/code/config
ln -sfn /app/data/storage /app/code/storage
ln -sfn /app/data/logs /app/code/logs

# ============================================
# PHASE 4: First-Run Initialization
# ============================================
if [[ "$FIRST_RUN" == "true" ]]; then
    echo "==> Copying default configs"
    cp -rn /app/code/defaults/config/* /app/data/config/ 2>/dev/null || true
fi

# ============================================
# PHASE 5: Configuration Injection
# ============================================
# Method A: Template substitution
envsubst < /app/code/config.template > /app/data/config/app.conf

# Method B: Direct generation
cat > /app/data/config/database.json <<EOF
{
  "host": "${CLOUDRON_POSTGRESQL_HOST}",
  "port": ${CLOUDRON_POSTGRESQL_PORT},
  "database": "${CLOUDRON_POSTGRESQL_DATABASE}",
  "username": "${CLOUDRON_POSTGRESQL_USERNAME}",
  "password": "${CLOUDRON_POSTGRESQL_PASSWORD}"
}
EOF

# Method C: sed for simple replacements
sed -i "s|APP_URL=.*|APP_URL=${CLOUDRON_APP_ORIGIN}|" /app/data/config/.env

# ============================================
# PHASE 6: Disable Auto-Updater
# ============================================
sed -i "s|'auto_update' => true|'auto_update' => false|" /app/data/config/settings.php

# ============================================
# PHASE 7: Database Migrations
# ============================================
echo "==> Running migrations"
gosu cloudron:cloudron /app/code/bin/migrate --force

# ============================================
# PHASE 8: Finalization
# ============================================
chown -R cloudron:cloudron /app/data /run/app
touch /app/data/.initialized

# ============================================
# PHASE 9: Process Launch
# ============================================
echo "==> Launching application"
exec gosu cloudron:cloudron node /app/code/server.js

Multi-Process: Supervisord Pattern

# /app/code/supervisord.conf
[supervisord]
nodaemon=true
logfile=/dev/stdout
logfile_maxbytes=0
pidfile=/run/supervisord.pid

[program:web]
command=/app/code/bin/web-server
directory=/app/code
user=cloudron
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

[program:worker]
command=/app/code/bin/worker
directory=/app/code
user=cloudron
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

# End of start.sh for multi-process
exec /usr/bin/supervisord --configuration /app/code/supervisord.conf

---

SECTION 7: Manifest Specification

Complete Template

{
  "id": "io.example.appname",
  "title": "Application Name",
  "author": "Your Name <email@example.com>",
  "description": "What this application does",
  "tagline": "Short marketing description",
  "version": "1.0.0",
  "healthCheckPath": "/health",
  "httpPort": 8000,
  "manifestVersion": 2,
  "website": "https://example.com",
  "contactEmail": "support@example.com",
  "icon": "file://logo.png",
  "documentationUrl": "https://docs.example.com",
  "minBoxVersion": "7.4.0",
  "memoryLimit": 512,
  "addons": {
    "localstorage": {},
    "postgresql": {}
  },
  "tcpPorts": {}
}

Memory Limit Guidelines

App Type	Recommended	Notes
Static/Simple PHP	128-256 MB
Node.js/Go/Rust	256-512 MB
PHP with workers	512-768 MB
Python/Ruby	512-768 MB
Java/JVM	1024+ MB	JVM heap overhead
Electron-based	1024+ MB

Health Check Requirements

• Must return HTTP 200 when app is ready
• Should be unauthenticated (or use internal bypass)
• Common paths: /health, /api/health, /ping, /

---

SECTION 8: Upgrade & Migration Handling

Version Tracking Pattern

CURRENT_VERSION="2.0.0"
VERSION_FILE="/app/data/.app_version"

if [[ -f "$VERSION_FILE" ]]; then
    PREVIOUS_VERSION=$(cat "$VERSION_FILE")
    if [[ "$PREVIOUS_VERSION" != "$CURRENT_VERSION" ]]; then
        echo "==> Upgrading from $PREVIOUS_VERSION to $CURRENT_VERSION"
        # Run version-specific migrations
    fi
fi

echo "$CURRENT_VERSION" > "$VERSION_FILE"

Migration Safety

• Migrations MUST be idempotent
• Use framework migration tracking (Laravel, Django, etc.)
• For raw SQL: CREATE TABLE IF NOT EXISTS, ADD COLUMN IF NOT EXISTS

---

🧪 SECTION 9: Testing Workflow

CLI Commands

# Install CLI
npm install -g cloudron

# Login
cloudron login my.cloudron.example.com

# Build image
cloudron build

# Install for testing
cloudron install --location testapp

# View logs
cloudron logs -f --app testapp

# Debug in container
cloudron exec --app testapp

# Iterate
cloudron build && cloudron update --app testapp

# Cleanup
cloudron uninstall --app testapp

Validation Checklist

□ Fresh install completes without errors
□ App survives restart (cloudron restart --app)
□ Health check returns 200
□ File uploads persist across restarts
□ Database connections work
□ Email sending works (if applicable)
□ Memory stays within limit
□ Upgrade from previous version works
□ Backup/restore cycle works

---

SECTION 10: Anti-Patterns

Writing to /app/code

# WRONG - Read-only filesystem
echo "data" > /app/code/cache/file.txt

# CORRECT
echo "data" > /app/data/cache/file.txt

Running as root

# WRONG
node /app/code/server.js

# CORRECT
exec gosu cloudron:cloudron node /app/code/server.js

Missing exec

# WRONG - Signals won't propagate
gosu cloudron:cloudron node server.js

# CORRECT
exec gosu cloudron:cloudron node server.js

Non-idempotent start.sh

# WRONG - Fails on second run
cp /app/code/defaults/config.json /app/data/

# CORRECT
cp -n /app/code/defaults/config.json /app/data/ 2>/dev/null || true

Hardcoded URLs

// WRONG
const baseUrl = "https://myapp.example.com";

// CORRECT
const baseUrl = process.env.CLOUDRON_APP_ORIGIN;

Bundling databases

# WRONG
RUN apt-get install -y postgresql redis-server

---

SECTION 11: Complexity Classification

Classify the application to set expectations:

Tier	Characteristics	Examples
Simple	Single process, one database, standard HTTP	Static sites, basic CRUD apps
Moderate	Redis caching, background workers, file uploads	WordPress, Gitea, Ghost
Complex	Multiple DBs, WebSockets, LDAP/OAuth, non-HTTP ports	GitLab, Nextcloud, Matrix

---

OUTPUT FORMAT

Generate a Project Specification Document with these exact sections:

1. Application Metadata

• Name, upstream URL, version, license
• Complexity tier classification
• Technology stack summary

2. Architecture Decisions

• Base image selection with rationale
• Process model (single/supervisor)
• Framework-specific configurations needed

3. Addon Requirements

• Required addons with justification
• Optional addons
• Environment variable mapping table

4. Filesystem Mappings

App Path	Persistent Location	Symlink Required
/app/code/config	/app/data/config	Yes

5. Configuration Strategy

• Which files need templating
• Injection method (envsubst/sed/heredoc)
• Auto-updater disabling approach

6. Start Script Logic

• Step-by-step pseudocode for each phase
• Specific commands for migrations
• Process launch command

7. Dockerfile Blueprint

• Ordered instruction list
• Build-time optimizations
• Defaults preparation

8. Manifest Data

• Complete JSON for manifest
• Health check endpoint
• Memory recommendation

9. Testing Considerations

• Key scenarios to verify
• Known edge cases

10. Security Notes

• Specific hardening for this app
• Features to disable

---

Tim, thanks. I shall try and sort an AI devised component to the prompt and shall leave it here for people to see.

Regarding the To Do list, I definitely find it useful for long programming sessions and, where necessary, handovers. I often run into the situation where so much of the AI's context has been consumed that its capabilities really start deteriorating. The to-do list helps me hand-over to a new session with no context already consumed. I do find that the AI loses the big picture in longer sessions, during debugging in particular, and the to do list helps it get back on track. It also acts as a sort of count-down or timer for me.

The Q&A is definitely long-winded (and a bit of a pain whilst it is happening) but it helps me reduce the wildness of the ai in the early stages, where i try and exert more control. Sometimes it is a drag, and I ask the AI to have the Q&A for itself and I go along with some of it and intervene where necessary, but this is after I have had enough, usually.

It would be brilliant if we got AI reliably packaging apps for Cloudron. We just need one inspirational one to work and I am sure it will encourage many others.

Gogs vs Gitea vs Forgejo: Which Self-Hosted Git to Pick in 2026? Dev Effort Breakdown

Tired of GitHub's censorship and bloat? Here's a no-BS comparison of the lightweight Git alternatives. All Go-based, MIT-licensed, one-binary deploys. Gogs is dead; pick Gitea or Forgejo for active dev.

Aspect	Gogs (0.13.0, 2021)	Gitea (1.22+, Jan 2026)	Forgejo (8.0+, Jan 2026)
Status	Dead/abandoned (last commit 2016)	Thriving (commercial/community hybrid)	Active fork of Gitea (community/non-profit)
Dev Effort	Zero. Archived on GitHub. No security patches, vulns piling up. Fork it yourself if needed.	High: 2k+ commits/month, 200+ contributors. Monthly releases, enterprise features. Backed by Gitea Ltd (Taiwan-based, less woke drama). GitHub stars: 40k+.	Medium-High: 500+ commits/month, syncs Gitea upstream. 50+ core devs. Codeberg-hosted, but slower than Gitea on edge features. Stars: 10k+.
Performance	Ultra-light (RPi-friendly)	Excellent, scales to 10k+ repos/users	Matches Gitea, Docker-optimized
Features	Basic Git + issues/hooks	Full: Actions (CI/CD), packages, wiki, LFS, federation, OAuth	Same as Gitea + P2P federation emphasis
Community/Woke	None (based by default)	Neutral-ish; CoC exists but pragmatic	Woke-leaning (CoC, pronouns, censorship vibes via Codeberg)
Security	Unpatched (avoid prod)	Frequent audits/fixes	Inherits Gitea + own patches
Setup/Migration	Simple but manual	Easiest: Docker, ARM64, Gogs importer	Docker-heavy, good Gitea/Gogs tools
Pros	Dead simple, zero deps	Feature-complete, reliable, active	Decentralized governance, FOSS purist
Cons	No modern features/support	Corporate shift irks purists	Fork drama, trails Gitea dev speed

Recommendations:

• Solo/based user: Gitea. Most bang-for-buck, ignore upstream politics.
• FOSS maximalist: Forgejo if you buy the anti-corp narrative (but watch the wokeness).
• Legacy: Gogs only for air-gapped hobby—migrate ASAP.

Dev metrics from GitHub/Codeberg dashboards (as of Jan 2026). Gitea wins on momentum; Forgejo if you hate companies.

People are raving about Anthropic's Claude Opus 4.5 coding abilities.
Would anybody like to try to package a simple app. One that would work easily on the GLAMP might be a useful place to start? Which would be a good target application?

A three phased approach would help, I think:

1. AI interview Q&A leading to Project Specifications document
2. AI conversion of project spec Project Blueprint
3. Stepwise Refinement To Do list

How it would work:

1. Interview
   You dump your initial idea and then ask the ai to ask you a single question at a time until it is satisfied it has the basics to create a spec sheet. You want a fast response ai here, as the Q&A can take half an hour or more. I have tried asking Grok to give a progress indicator for these interviews and that takes up time too, but maybe it helped the ai. It helps the user as you feel it might go on forever!

2. Spec-to-Blueprint
   You want a massive output context window here for as much detail as possible. You might like to ask the ai to do as much as it can in one go and then continue with subsequent chunks later. I think it is a good idea to start this process in an entirely new session and just give it the project spec, as it helps free up some context.

3. To Do list.
   This keeps the ai coder using the blueprint on track as it goes through the massive coding. It completes the tasks and then ticks them off its list and knows what to do next.

Dylan Davis has a good video about this process with hints on prompts here:

One key thing that team cloudron could do to help with a modular step one is to provide the specifics that would remain the same for packaging in every project.

@joseph I just tried to follow one of those privatebin links, and it looks like the cloudron demo is down right now...

@joseph Yes, it is, and it was for you, Joseph, to thank you for the maintenance on the cloudron demo server. It is also for everybody here, though a bit late!

One of the reasons I installed privatebin (the better maintained option for pastebin type services on cloudron) is to have a place where we could paste stuff for the cloudron server.

Several users have requested support for an XMPP server on Cloudron.

Hopefully, we shall have official support for XMPP soon. Here is an ai generated summary of what is in the pipeline for XMPP later this year and going into the future.

https://privatebin.demo.cloudron.io/?7744fbf85abe18c8#4D59SBQsqhdWJVdQGDMHFLdeNN6yWZfm66bhYLx6cXjP

In case people can't remember (!)

XMPP stands for Extensible Messaging and Presence Protocol.

It's an open, decentralized standard (originally Jabber) for real-time communication like instant messaging, presence (online status), group chats, voice/video (via Jingle), and more. Built on XML streams over TCP (or HTTP), it federates like email—anyone can run a server, no central authority. Formalized by IETF in RFCs 6120/6121 (2011 updates). Powers apps from gaming (PlayStation) to IoT, with extensions (XEPs) for endless customization.

Lets support XMPP on Cloudron by packaging Snickket! There is an ai summary of progress since @robi made the original request here:

https://privatebin.demo.cloudron.io/?39e1a2ac0124f319#7wVtyc66t51BK2SpX7TudDPVpZm5sDqSmJCDvsrBqCXn

There is an ai summary comparing the relative merits of mostlymatter and rocket.chat here:

https://privatebin.demo.cloudron.io/?4d4ec89bf8d15f94#2XdR8C2xbBzHRHZEfA2ZBSASHKhxokgsr79v31Xb6UtC

@james

https://privatebin.demo.cloudron.io/?4822f3035e112039#NYbUMH3ZYZK9BstfN64bNFH7zK8iebroXWP7TRXoWVz

It seems that we are very nearly there with BTCpayserver. Lets wrap up this project and publish it officially on cloudron.

Here are the main improvements on BTCserver just over the past year (2025):

BTCPay Server Main Improvements (Jan 2025 - Jan 2026)

POS & Checkout

• Tax rates applied to items with breakdowns in checkout/receipts
• Improved total breakdown, receipts, and cart views
• POS reports now include tips/subtotals
• Numeric keypad shows input amount (not total); item list support
• Receipts displayable in iframes; hide back-to-store link in iframes
• Disable zero-amount invoices; improved mobile UX

Wallet & Transactions

• Wallet policy output descriptors (BIP388/389) and Taproot signing (BIP86) for hardware wallets
• RBF sweeping transactions and CPFP UX improvements
• Manual coin selection with advanced filters ("Clear All")
• Browse generated addresses; fiat amount previews in tx details
• Tx fee/fee rate info; exchange rate tracking; additional rates via store settings
• BBQr PSBT support (up to 16MB); improved PSBT error messages

API & Greenfield

• New webhooks: InvoiceExpiredPaidPartial, InvoicePaidAfterExpiration
• amountPaid on invoices; email settings endpoint
• Subscriptions API; store users API (update/retrieve by ID/email)
• Payment requests link to external invoices (e.g., QuickBooks) via Reference ID
• PoS data without auth; payout methods optional for pull payments
• Histograms with Lightning data; image upload for app items

Reporting & Invoices

• Renamed/reordered invoice report columns; export all metadata
• Payment request reports with improved filtering
• Refund reports; "Reporting" button for quick access
• Responsive UI; sales stats filter to paid invoices only
• Admin can view users' invoices; manual payout state transitions (InProgress → AwaitingPayment)

Subscriptions & Automation

• Recurring payments with reminders; prefilled subscriber email
• Ambassadors can monetize server access
• Installable backend language packs
• Advanced server email rules (conditions, placeholders, CC/BCC)

UI/UX & Accessibility

• Custom HTML meta tags/lang for SEO (crowdfund/PoS)
• Improved hardware wallet import (no confirm addresses page; auto-label by model)
• Dashboard tweaks (remove store headline, hide LN balance for non-admins)
• Tooltip/link for pull-payment tags; copy link button
• Auto-disable crashed plugins; cleanup expired data

Integrations & Providers

• Phoenixd, Coinmate (CZK), Kraken (CAD), Yadio, Norwegian exchanges (Bitmynt/Bare Bitcoin)
• Fallback rate sources; rate providers configurable
• Shopify integration deprecation warning + new plugin link
• Multisig flow improvements (BTCPay-only users); confirmation prompts

Bug Fixes & Reliability

• RBF label consistency; fee rate crashes; Yadio rate lookup
• Archived invoices private; status filter 500 errors
• Lightning payment detection post-connection string swap
• Vault signing for large PSBTs; pending payouts on unresponsive LN
• Notifications API crashes; Boltcard reset issues; escaped HTML in UTXOs
• Zero-amount payment requests; receipt options from store settings

Sources: GitHub releases (up to v2.3.3), Changelog.md. Full notes: Releases.

I tried to install privatebin but it wouldn't start/complete the installation.

ejabberd has had a lot of work to improve it since it was first requested by @jdaviescoates Lets support it on cloudron, now that we have version 9.

## ejabberd Main Improvements Since May 2020

### Matrix Gateway (mod_matrix_gw) Enhancements
- **Initial 1:1 support** (24.02+): Bridging to Matrix servers for direct messages.
- **Room support** (25.03): Invitations to Matrix rooms, public room joins; MUC-like handling (versions 9-11 initially).
- **Expanded room compatibility** (25.07/25.10): Older room versions, Hydra rooms (v12), state resolution rewrite, notary_servers/leave_timeout options.
- **Other fixes**: No empty direct messages, double-colon JID for Hydra.

### Spam & Security Filtering
- **mod_antispam** (25.07/25.10): Replaces mod_spam_filter; RTBL support for blocking spammer JIDs/URLs in messages/subscriptions.
- **ACME fixes**: Erlang/OTP 28.0.2 compatibility.
- **XEP-0425**: Moderated Message Retraction (24.12).

### New Modules & Discovery
- **mod_providers** (25.10): Auto-generates/serves XMPP Providers JSON (XEP-0485) at /.well-known/xmpp-provider-v2.json.
- **mod_pubsub_serverinfo** (25.07/25.10): PubSub Server Information for XMPP network graphs.
- **mod_antispam**: Real-time block lists.

### XEP & Protocol Support
- **XEP-0431**: Full Text Search in MAM (25.10?).
- **XEP-0402**: PEP Native Bookmarks (24.12).
- **XEP-0424**: Message Retraction (24.12).
- **XEP-0369**: Latest MIX (23.01).
- **MAM improvements**: archive_muc_as_mucsub option (25.10).

### Authentication & Config
- **Multiple password types** (25.03): Simultaneous support.
- **auth_password_types_hidden_in_scram1** (25.10).
- **host_alias**, predefined keywords, rest_proxy options.
- **ejabberdctl**: CTL_OVER_HTTP (25.03).

### API & Admin Tools
- **New API Commands**: Inspired by XEP-0133 across modules (25.10).
- **mod_configure**: access option (25.03).
- **WebAdmin**: Link to Converse, formatting updates.

### Performance & Compatibility
- **Erlang/OTP**: 25 required, 28 supported (25.10).
- **SQL/MUC changes** (23.01+).
- **Container images**: Macros, WebAdmin port exposure (25.03).

### Other Highlights
- **Business Edition**: GCM/Webhook/Webpush fixes.
- **General**: XEP-0313 MAM, HTTP Upload, vCard-temp; systemd integration, JWT auth, MQTT broker maturity (21.01+).

Sources: GitHub releases (20.06–25.10), changelogs. Focus on user-impacting features; full details per release at https://github.com/processone/ejabberd/releases.

Lets support Prosody XMPP server on Cloudron, now that we have Cloudron 9.
https://github.com/prosody/prosody-docker

Docker seems to be the new official way of installing Prosody.

@joseph The SEC in America very unfairly blocked Odysee's crypto token from progressing, which basically sunk their business plan.

The Free Software protocol behind the Odysee frontend was LBRY. Paid development of the LBRY project was sunk when the SEC made their ruling.

The idea was that you could run a local instance of LBRY and that would act as part of the CDN for the frontend (which didn't have to be Odysee.com). The thinking was people would use a LBRY client to view their content and the client in turn would also be serving the same content to other. If you liked the content/supported the channel, by leaving the video on your machine, you would help seed it/improve the CDN. It was a great idea. In practice, most people weren't interested in running the LBRY client. Even politically censored people that Odysee would help most didn't bother with it, amazingly.

It is a pity. Odysee Inc. split off from the original project and still goes today. The SEC were most unfair.