test: demo slide fit-to-screen options 4+5 on copies
Adds -fit-test copies of the labdesign and messaging decks that apply container-query font sizing (option 5) and a max-height cap on mermaid SVGs (option 4) so we can compare overflow behavior side-by-side against the originals. Includes a comment explaining why option 2 (custom canvas size) cannot be demoed inline and would require registering a custom theme via marp.config.mjs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
sjat
parent
fa7fd32dcd
commit
b5d882415c
2 changed files with 368 additions and 0 deletions
178
docs/infrastruktur/labdesign-fit-test.md
Normal file
178
docs/infrastruktur/labdesign-fit-test.md
Normal file
|
|
@ -0,0 +1,178 @@
|
||||||
|
---
|
||||||
|
marp: true
|
||||||
|
pagination: true
|
||||||
|
size: 16:9
|
||||||
|
---
|
||||||
|
|
||||||
|
<!--
|
||||||
|
Option 2 (larger canvas — NOT applied here): the `size:` frontmatter
|
||||||
|
only accepts sizes the active theme has declared via @size. The
|
||||||
|
bundled `default`/`gaia` themes only declare 16:9 (1280x720) and 4:3
|
||||||
|
(960x720). To get a 1920x1080 canvas you must register a custom
|
||||||
|
theme via marp.config.mjs / --theme that contains
|
||||||
|
@size fhd 1920px 1080px;
|
||||||
|
and then reference it as `size: fhd`. Inline <style> blocks cannot
|
||||||
|
declare theme metadata, so a one-file demo of option 2 isn't possible
|
||||||
|
without touching the build pipeline.
|
||||||
|
-->
|
||||||
|
|
||||||
|
<style>
|
||||||
|
/* Option 5: make each slide a query container so children can size
|
||||||
|
themselves relative to the slide (1cqh = 1% of slide height). */
|
||||||
|
section {
|
||||||
|
container-type: size;
|
||||||
|
font-size: clamp(0.9rem, 2.4cqh, 1.6rem);
|
||||||
|
}
|
||||||
|
section h1 { font-size: clamp(1.8rem, 5.5cqh, 3.6rem); }
|
||||||
|
section h2 { font-size: clamp(1.4rem, 4.2cqh, 2.8rem); }
|
||||||
|
section h3 { font-size: clamp(1.2rem, 3.4cqh, 2.2rem); }
|
||||||
|
|
||||||
|
/* Option 4: cap mermaid by BOTH width and height so tall diagrams
|
||||||
|
shrink to fit instead of overflowing the slide vertically.
|
||||||
|
85cqh = at most 85% of slide height, leaving room for the heading. */
|
||||||
|
.mermaid svg {
|
||||||
|
max-width: 100% !important;
|
||||||
|
max-height: 85cqh !important;
|
||||||
|
width: auto !important;
|
||||||
|
height: auto !important;
|
||||||
|
}
|
||||||
|
</style>
|
||||||
|
|
||||||
|
# Introduction
|
||||||
|
|
||||||
|
This is assorted notes on what could go into the MakerFLOSS lab
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Requirements
|
||||||
|
|
||||||
|
- A space to experiment with new software
|
||||||
|
- A place where software could be "test run" for some time
|
||||||
|
- A place where errors are not causing IP loss
|
||||||
|
- even if errors are real big !!
|
||||||
|
|
||||||
|
## More details
|
||||||
|
|
||||||
|
- Firewalled off from the production network
|
||||||
|
- Accessible from outside
|
||||||
|
- Potential for exposing services externally
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Constraints
|
||||||
|
|
||||||
|
- Cost conscious
|
||||||
|
- Support constant change
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Proposals
|
||||||
|
|
||||||
|
## Short term
|
||||||
|
|
||||||
|
A VPS in a (European) cloud with one public IP
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Midterm
|
||||||
|
|
||||||
|
Complement the VPS with some local hardware:
|
||||||
|
|
||||||
|
- Firewall with zones (VLANs, DNS/DHCP)
|
||||||
|
- Netbird access to services in Lab
|
||||||
|
- Switching infrastructure
|
||||||
|
- A primary "stable" Proxmox host
|
||||||
|
- A secondary experimentation machine
|
||||||
|
- A backup server
|
||||||
|
- Tunnel for external access via VPS public IP
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Basic Services in Lab
|
||||||
|
|
||||||
|
- Git: Forgejo
|
||||||
|
- ...
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Lab Diagram
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph LR
|
||||||
|
subgraph External
|
||||||
|
Internet[🌐 Internet]
|
||||||
|
VPS[FLOSS VPS<br/>88.99.32.236]
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph OrangeMaker["Orange Makerspace"]
|
||||||
|
OMFirewall[OrangeMaker Firewall]
|
||||||
|
ProdNet[Production Network]
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph FLOSSLab["MakerFLOSS Lab"]
|
||||||
|
Switch[Switch]
|
||||||
|
Proxmox1[LabZone 1<br/>Test Proxmox]
|
||||||
|
Proxmox2[LabZone 2<br/>Experimental]
|
||||||
|
|
||||||
|
subgraph TAPPaaS
|
||||||
|
FLOSSFirewall[MakerFLOSS Firewall<br/>DNS/DHCP/VLANs]
|
||||||
|
PreProd[Pre-production Zone]
|
||||||
|
Backup[Backup Server]
|
||||||
|
end
|
||||||
|
end
|
||||||
|
|
||||||
|
Internet --> VPS
|
||||||
|
Internet --> OMFirewall
|
||||||
|
VPS -.->|Tunnel| FLOSSFirewall
|
||||||
|
VPS -.->|Netbird| FLOSSFirewall
|
||||||
|
OMFirewall --> ProdNet
|
||||||
|
OMFirewall --> FLOSSFirewall
|
||||||
|
FLOSSFirewall --> Switch
|
||||||
|
FLOSSFirewall --> PreProd
|
||||||
|
Switch --> Proxmox1
|
||||||
|
Switch --> Proxmox2
|
||||||
|
Switch --> Backup
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### TAPPaaS Diagram
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph TB
|
||||||
|
subgraph TAPPaaS
|
||||||
|
subgraph Firewall["Firewall"]
|
||||||
|
Zones[Zones]
|
||||||
|
Caddy[Caddy]
|
||||||
|
Certs[Certificates]
|
||||||
|
DHCPDNS[DHCP/DNS]
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph PreProd["Pre-Production"]
|
||||||
|
Proxmox[Proxmox]
|
||||||
|
Authentik[Authentik]
|
||||||
|
CICD[CI/CD]
|
||||||
|
Forgejo[Forgejo]
|
||||||
|
More[...]
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph BackupSrv["Backup"]
|
||||||
|
BackupService[PBS Backup Service]
|
||||||
|
end
|
||||||
|
end
|
||||||
|
|
||||||
|
Firewall --> PreProd
|
||||||
|
Firewall --> BackupSrv
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Long term
|
||||||
|
|
||||||
|
replace VPS with a direct IP pinhole access
|
||||||
|
|
||||||
|
replace the "stable" FLOSS services running on VPS with modules runing on "stable" machine locally
|
||||||
|
|
||||||
|
|
||||||
|
# Design of Mid term solution
|
||||||
|
|
||||||
190
docs/møder/2026-05-11_messaging-presentation-fit-test.md
Normal file
190
docs/møder/2026-05-11_messaging-presentation-fit-test.md
Normal file
|
|
@ -0,0 +1,190 @@
|
||||||
|
---
|
||||||
|
marp: true
|
||||||
|
theme: gaia
|
||||||
|
class: invert
|
||||||
|
paginate: true
|
||||||
|
size: 16:9
|
||||||
|
---
|
||||||
|
|
||||||
|
<!--
|
||||||
|
Option 2 (larger canvas — NOT applied here): the `size:` directive
|
||||||
|
only accepts sizes the theme has declared via @size. Gaia ships only
|
||||||
|
16:9 (1280x720) and 4:3 (960x720). To get a 1920x1080 canvas you
|
||||||
|
must register a custom theme via marp.config.mjs / --theme containing
|
||||||
|
@size fhd 1920px 1080px;
|
||||||
|
and then set `size: fhd`. Inline <style> blocks cannot declare theme
|
||||||
|
metadata, so this can't be demoed in a single file.
|
||||||
|
-->
|
||||||
|
|
||||||
|
<style>
|
||||||
|
/* Option 5: each slide becomes a query container; tables size against
|
||||||
|
slide height (1cqh = 1% of slide height) instead of the root font. */
|
||||||
|
section {
|
||||||
|
container-type: size;
|
||||||
|
}
|
||||||
|
table { font-size: clamp(0.55rem, 1.9cqh, 1.1rem); }
|
||||||
|
th, td { padding: 0.25em 0.6em; }
|
||||||
|
section.dense table { font-size: clamp(0.45rem, 1.4cqh, 0.9rem); }
|
||||||
|
section.dense th, section.dense td { padding: 0.2em 0.5em; }
|
||||||
|
|
||||||
|
/* Option 4: cap mermaid by BOTH dimensions so tall diagrams shrink. */
|
||||||
|
.mermaid svg {
|
||||||
|
max-width: 100% !important;
|
||||||
|
max-height: 80cqh !important;
|
||||||
|
width: auto !important;
|
||||||
|
height: auto !important;
|
||||||
|
}
|
||||||
|
</style>
|
||||||
|
|
||||||
|
# Messaging Without Big Tech
|
||||||
|
|
||||||
|
### Free & Open Alternatives to WhatsApp and Messenger
|
||||||
|
|
||||||
|
MakerFLOSS · May 2026
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Why Are We Here?
|
||||||
|
|
||||||
|
Most people use WhatsApp, Messenger, or iMessage.
|
||||||
|
|
||||||
|
- **WhatsApp** — owned by Meta; metadata harvested
|
||||||
|
- **Messenger** — no E2EE by default in groups; ad tracking
|
||||||
|
- **Telegram** — _not_ E2EE by default; closed server
|
||||||
|
- **iMessage** — Apple lock-in; no Android or Linux
|
||||||
|
|
||||||
|
These apps are _convenient_ — but the cost is your data.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Wish-list
|
||||||
|
|
||||||
|
| Property | Why it matters |
|
||||||
|
| ------------------------- | ------------------------------------------- |
|
||||||
|
| End-to-end encryption | Only sender and recipient can read messages |
|
||||||
|
| Open source | Anyone can audit the code |
|
||||||
|
| Self-hostable | You control the server and the data |
|
||||||
|
| No phone number required | Less identity linkage |
|
||||||
|
| Cross-platform | Linux, Android, iOS, Windows |
|
||||||
|
| Federated / decentralized | No single point of failure or control |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## The Landscape at a Glance
|
||||||
|
|
||||||
|
_All apps below support end-to-end encryption._
|
||||||
|
|
||||||
|
| App | Open source | Self-host | No phone# | Federation |
|
||||||
|
| -------------------- | ----------- | --------- | --------- | ---------- |
|
||||||
|
| **Signal** | Partial | ✗ | ✗ | ✗ |
|
||||||
|
| **Matrix / Element** | ✓ | ✓ | ✓ | ✓ |
|
||||||
|
| **XMPP + OMEMO** | ✓ | ✓ | ✓ | ✓ |
|
||||||
|
| **Briar** | ✓ | N/A | ✓ | N/A |
|
||||||
|
| **Session** | ✓ | Partial | ✓ | Partial |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Signal — The Gold Standard for E2EE
|
||||||
|
|
||||||
|
Non-profit Signal Foundation. The Signal Protocol powers WhatsApp, Google RCS, and Messenger secret chats.
|
||||||
|
|
||||||
|
**Pros**
|
||||||
|
|
||||||
|
- Simplest UX — works like a normal messaging app
|
||||||
|
- Audited, battle-tested cryptography; no ads, no tracking
|
||||||
|
|
||||||
|
**Cons**
|
||||||
|
|
||||||
|
- Phone number required — links identity to account
|
||||||
|
- Centralized — Signal's servers, Signal's rules
|
||||||
|
|
||||||
|
**Best for:** journalists, activists, everyday secure messaging
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Signal — Under the Hood
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
sequenceDiagram
|
||||||
|
participant A as Alice's phone
|
||||||
|
participant S as Signal Server
|
||||||
|
participant B as Bob's phone
|
||||||
|
A->>S: encrypted message
|
||||||
|
Note over S: sees: who, when, how often<br/>does NOT see: content
|
||||||
|
S->>B: encrypted message
|
||||||
|
Note over B: decrypts with private key
|
||||||
|
```
|
||||||
|
|
||||||
|
Metadata still matters — [Signal subpoena responses](https://signal.org/bigbrother/)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Matrix — The Federated Open Standard
|
||||||
|
|
||||||
|
Matrix is a **protocol**, not an app — like email for real-time chat.
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph LR
|
||||||
|
EC[Element client] --> YH[your homeserver]
|
||||||
|
YH <-->|federation| OH[another homeserver]
|
||||||
|
FC[FluffyChat] --> OH
|
||||||
|
```
|
||||||
|
|
||||||
|
- **Servers**: Synapse (Python), Conduit (Rust), Dendrite (Go)
|
||||||
|
- **Clients**: Element, FluffyChat, Cinny, Fractal, Nheko
|
||||||
|
- **Bridges**: WhatsApp, Telegram, Signal, IRC, Discord…
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Matrix — Pros and Cons
|
||||||
|
|
||||||
|
**Pros**
|
||||||
|
|
||||||
|
- Fully open source, top to bottom
|
||||||
|
- Self-host your server — you own your data
|
||||||
|
- Federated — no single company controls the network
|
||||||
|
- Bridges consolidate all your chats in one place
|
||||||
|
|
||||||
|
**Cons**
|
||||||
|
|
||||||
|
- E2EE key management is clunky (cross-signing, key backup)
|
||||||
|
- Synapse is resource-hungry (~1 GB RAM)
|
||||||
|
- The UX of Element is still maturing
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Matrix Bridges — Stay Connected During the Transition
|
||||||
|
|
||||||
|
A bridge relays messages between Matrix and another network — both ways.
|
||||||
|
|
||||||
|
| Bridge | Network | Notes |
|
||||||
|
| ------------------------- | ---------- | ------------------------------------------ |
|
||||||
|
| `mautrix-whatsapp` | WhatsApp | Puppeting — your real WA account |
|
||||||
|
| `mautrix-telegram` | Telegram | Puppeting — very stable |
|
||||||
|
| `mautrix-signal` | Signal | Fragile — Signal actively breaks 3rd-party |
|
||||||
|
| `meshtastic-matrix-relay` | Meshtastic | LoRa mesh ↔ Matrix — off-grid messaging |
|
||||||
|
|
||||||
|
**Catch:** Puppeting bridges hold your credentials. WhatsApp's ToS prohibits it — occasional bans occur.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## XMPP (Jabber)
|
||||||
|
|
||||||
|
The _original_ federated chat standard — 1999. Still alive and kicking.
|
||||||
|
|
||||||
|
- Extremely mature and lightweight
|
||||||
|
- E2EE via OMEMO
|
||||||
|
- Good clients: **Conversations** (Android), **Monal** (iOS/macOS), **Gajim** (desktop)
|
||||||
|
- Con: fragmented client quality; less beginner-friendly than Signal or Matrix
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Briar
|
||||||
|
|
||||||
|
Peer-to-peer messaging — _no server at all_.
|
||||||
|
|
||||||
|
- Works over Tor, local WiFi, or Bluetooth (offline!)
|
||||||
|
- Censorship-resistant by design
|
||||||
|
- Con: Android-first; no desktop client; both parties must be online to first connect
|
||||||
|
|
||||||
|
**For:** activists, disaster scenarios, high-censorship environments
|
||||||
Loading…
Add table
Reference in a new issue