docs: streamline todos and remove fit-test sandboxes
- Delete two stale single-meeting todos: 2026-03-16_todo.md and 2026-05-05.md. - Rename `2026-04-14 TODO.md` -> `2026-04-14_todo.md` to match the underscore convention used by the other dated files, and update the CLAUDE.md reference. - Remove the two Marp/CSS fit-test sandboxes (labdesign-fit-test.md and 2026-05-11_messaging-presentation-fit-test.md); the responsive experiments were never folded back into the canonical decks. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
b9722f082f
commit
9310396fac
6 changed files with 1 additions and 379 deletions
|
|
@ -8,7 +8,7 @@ This is a **documentation-only repository** for the MakerFLOSS initiative at Ora
|
||||||
|
|
||||||
## Working Norms
|
## Working Norms
|
||||||
|
|
||||||
From `docs/todo/2026-04-14 TODO.md`:
|
From `docs/todo/2026-04-14_todo.md`:
|
||||||
|
|
||||||
- **Language**: English for code, docs, commits (meeting notes may be in Danish)
|
- **Language**: English for code, docs, commits (meeting notes may be in Danish)
|
||||||
- **Git**: Trunk-based development, feature branches, simple commit messages
|
- **Git**: Trunk-based development, feature branches, simple commit messages
|
||||||
|
|
|
||||||
|
|
@ -1,178 +0,0 @@
|
||||||
---
|
|
||||||
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
|
|
||||||
|
|
||||||
|
|
@ -1,188 +0,0 @@
|
||||||
---
|
|
||||||
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
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 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
|
|
||||||
|
|
@ -1,5 +0,0 @@
|
||||||
# ToDos efter første møde
|
|
||||||
|
|
||||||
- [ ] Beskriv ønsker til hardware og spørg ud i makerspace-gruppen om nogen har noget de vil donere
|
|
||||||
- [ ] Få et underdomæne fra bestyrelsen (fx makerfloss.orangemakerspace.com) og sæt relevant DNS api op.
|
|
||||||
- [ ] Konkretiser netværksbehov til bestyrelsen
|
|
||||||
|
|
@ -1,7 +0,0 @@
|
||||||
# ToDo
|
|
||||||
|
|
||||||
ø Facebook rekleme
|
|
||||||
|
|
||||||
- Indkøbsliste
|
|
||||||
g Netværk inden mandag
|
|
||||||
- Skaf penge
|
|
||||||
Loading…
Add table
Reference in a new issue