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