Compare commits

...

2 commits

Author SHA1 Message Date
sjat
f401f98d47 docs(todo): refresh OM_services and indkøbsliste
All checks were successful
Build docs site / build (push) Successful in 31s
Build slides / build (push) Successful in 51s
- Add 'touch display med kalender etc.' to the OM services wishlist.
- Reset indkøbsliste into an empty wish/get list ('Ønske/skaffe-liste').

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-18 16:21:31 +02:00
sjat
9310396fac 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>
2026-05-18 16:21:26 +02:00
8 changed files with 3 additions and 384 deletions

View file

@ -8,7 +8,7 @@ This is a **documentation-only repository** for the MakerFLOSS initiative at Ora
## 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)
- **Git**: Trunk-based development, feature branches, simple commit messages

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -1,7 +0,0 @@
# ToDo
ø Facebook rekleme
- Indkøbsliste
g Netværk inden mandag
- Skaf penge

View file

@ -5,3 +5,4 @@
- Bo's invetory system and DNS for his QR-codes
- Task management system for BuildDays
- Display systemet Konrad
- touch display med kalender etc.

View file

@ -1,5 +1 @@
# Indkøbsliste
- Rack-studs
- 3 =< 3B+
- Kølepasta
# Ønske/skaffe-liste