Source Research — Original Architecture Notes (provenance)¶

Validation status: Historical source document, preserved verbatim below. Superseded and expanded by the Communication Architecture Reconsideration (2026-06-13), which re-evaluated these candidates against current evidence and corrected several conclusions.

This is the seed document for the reconsideration — the working notes that framed MPowerUp as "compose existing apps rather than build from scratch." It is kept for provenance, and because it carries two pieces the reconsideration folded in by reference rather than rewriting: the four-architecture Mermaid diagram (§7) and the graph-database survey for the research knowledge graph (§5).

Where its conclusions changed (see the verdict):

The original treats Jami as the secure-zone anchor / likely adoption. The reconsideration found Jami exposes IP to peers and is battery-heavy → not adopted; Briar / SimpleX / Cwtch are the stronger metadata-resistant candidates, and the recommendation is a hybrid (build-the-app, adopt-the-component), not "compose existing apps."

The original four-architecture taxonomy is expanded to six in architecture-taxonomy (splitting out anonymity-network and no-identifier shapes). The §7 diagram below is the original four; the taxonomy note carries the expanded model.

The three-axis zone insight (§3) is carried forward and made central in zones-model.

The graph-DB survey (§5) is out of scope for the comms reconsideration but preserved here; its tools are tracked in tools.md.

The §9 scorecard is the direct seed of tools.md, now reconciled and extended.

Below: the original document, reproduced verbatim.

MPowerUp — Communication & Networking Architecture Research¶

Working research notes for MPowerUp: a privacy-first platform concept integrating existing secure/decentralized apps (Jami, Nostr/Damus, federated social) plus custom code. This document captures the architectures considered, their privacy trade-offs, the "security zones" model, graph-database options for research, and reference links. Intended for import into a separate Claude Code instance.

1. Project Framing¶

MPowerUp is a shift toward composing existing secure / private / decentralized communication software rather than building everything from scratch. Original candidates: Jitsi, Jami, Mastodon, "and others," plus custom integration code.

Key architectural realization¶

The named building blocks span three different architectures, not one:

Component	Architecture	P2P?
Jami	True peer-to-peer (OpenDHT)	Yes
Jitsi	Client–server, self-hostable (media routed through Jitsi Videobridge for multi-party)	Partial (1:1 only)
Mastodon	Federated (ActivityPub, server-to-server)	No

Decision in this session: drop Jitsi, keep Jami as the true-P2P core, and evaluate alternatives to Mastodon for the social layer.

The real engineering problem¶

The individual apps each run fine on their own. The hard part is that they do not share identity, contacts, or a trust model: - Jami → DHT cryptographic fingerprints - Mastodon → instance@handle - Jitsi → room URLs / JWT - Nostr → public/private keypair (npub / nsec)

Stitching these into one coherent "account" is the core work, and it determines whether MPowerUp is a launcher/wrapper or a genuine platform.

Licensing caution¶

Jami and Jitsi are significant copyleft (GPL/AGPL-family) codebases. Bundling them with custom code has real licensing consequences for the surrounding code. Evaluate this early.

The decisive choice is the protocol, not the app — the protocol determines federation behavior.

ActivityPub family (federated, server-based — like Mastodon)¶

Pleroma / Akkoma — lightweight ActivityPub servers; run on Raspberry-Pi-class hardware.
Misskey / Sharkey — more feature-rich, also ActivityPub.
GoToSocial — single-binary, very low resource; best fit for federated but minimal.

P2P / no-server-required (closer to Jami's philosophy)¶

Nostr — client–relay model; identity is a keypair you own; no instance to run or be deplatformed from. Composes well with Jami because both use "you are your key" identity.
Scuttlebutt (SSB) — genuinely P2P, gossip-based, works offline; niche.
Briar — P2P encrypted messaging over Tor / Bluetooth / WiFi; no servers. Architecturally a natural "P2P zone" messenger.

Recommended pairing¶

Nostr for the social layer (key-based identity, censorship-resistant) + Jami or Briar for the P2P comms layer. Shared "identity = cryptographic key" model solves the identity-stitching problem.

3. Security Zones Model¶

A deliberate architecture of distinct trust domains (conceptually related to how Qubes OS separates security domains, and how some messengers expose trust levels).

The three zones¶

Zone	Description	Cost / Trade-off
P2P zone	No servers; no third-party metadata leakage; strongest privacy (Jami / Briar / self-run Nostr relays)	Harder discovery; unreliable offline delivery; smaller reach
Federated zone	Distributed servers chosen by trust (ActivityPub / Nostr relays)	Server operators see metadata; moderation & availability depend on them
Unsecured / open zone	Public, plaintext-or-standard-TLS; maximum reach & interoperability	Assume fully observable

What makes the design work (vs. become a trap)¶

The user must always know which zone they are in.
Data must not silently cross zone boundaries.
Classic failure: a P2P-zone message gets quoted/forwarded into the open zone.
Classic failure: a contact's identity in one zone is correlated to another.
Zone boundaries must be explicit in the UI and enforced in code, not conventions.

Open design questions¶

Are zones a property of a conversation/channel (this chat is P2P, that one federated), or of the user's current mode (I am in secure mode right now)? Different designs follow.
When something must cross zones (e.g. inviting a federated-only contact into a P2P conversation): block, warn-and-downgrade, or bridge with an explicit security label? This single decision is most of the platform.

A single zone label is too coarse. A zone must be defined by at least three independent axes: 1. Content confidentiality — is the payload encrypted? 2. Metadata exposure — is the social graph / timing / size visible? 3. Network identity — is your IP / key-linkage exposed?

Damus scores differently on each axis simultaneously; collapsing it to one "level" hides the exact risk that matters.

4. Damus / Nostr — Detailed Privacy & Networking Model¶

Damus is a Nostr client, so its properties are Nostr's properties. It does not fit cleanly into one zone — it straddles them, which is precisely why it is instructive.

Architecture in one sentence¶

The client connects outward to multiple independent relays over WebSocket. There is no Damus server to log into. Identity is a keypair the user holds. If a relay censors, the user switches relays while keeping identity and content history.

Not P2P (relays sit in the middle) and not federated like Mastodon (relays do not sync with each other — the client fans out and aggregates). It is a third shape: client–relay.

Privacy by data type (within the same app)¶

Data type	Behavior	Zone-equivalent
Public posts (notes)	Plaintext, broadcast to many relays, designed to be replicated/visible	Open / unsecured
Direct messages	Content encrypted, but who-you-DM (metadata) is public	Federated-grade privacy in "secure" clothing
Identity / connection	IP exposed to relays & third-party media hosts; relay ties your pubkey to your IP. Official guidance: use a VPN. No anonymous mode by default.	Deanonymizing to relay operators unless a network-privacy layer is added

Lesson for MPowerUp¶

Encrypted content alone does not qualify something for the secure/P2P zone if metadata leaks.
Damus is a strong candidate for the federated/open social layer, but its DMs should not be presented as secure-zone messaging.
For the secure zone, Jami remains better — it does not route identity-linked requests through third-party relays.
To put Nostr in the secure zone you would need: (a) self-run relays, (b) a network anonymity layer (Tor/VPN), (c) a metadata-resistant DM scheme — at which point you have largely rebuilt what Jami already provides.

Containment vs. reach decision¶

Nostr's core value is public reachability and interoperability with thousands of other clients. If you want MPowerUp users contained (not discoverable from any Nostr client), you must run private relays — which starts to look like federation again.

5. Graph Database Options (for Research Knowledge Graph)¶

Goal: research projects and maintain a graph of people, orgs, resources, actions, events, connected to projects. This is a textbook property graph — nodes typed by category, edges like attended, funds, authored, member_of, references.

True graph databases (server, query language, scales)¶

Neo4j Community Edition — default answer. Mature, huge ecosystem, Cypher query language, excellent visualization (Browser/Bloom). GPLv3; Community lacks some clustering/security features (irrelevant for a solo researcher).
Memgraph — Neo4j-compatible (Cypher), in-memory/fast, real-time. Source-available license — check against needs.
ArangoDB — multi-model (graph + document + key-value). Good if "resources" are messy documents. Apache 2.0 / BSL depending on version.
Kùzu — embedded graph DB (SQLite-for-graphs), Cypher-compatible, MIT, no server. Best fit for embedding inside MPowerUp / a custom tool.
Apache AGE — PostgreSQL extension adding graph queries. Best if you already want Postgres.

RDF / semantic graphs (linked data, ontologies, interoperability)¶

Apache Jena (+ Fuseki) / Blazegraph — RDF triples + SPARQL. Formal vocabularies (schema.org, FOAF) for person/org/event; portable & reasoning-capable. Likely overkill unless interoperability is a goal.

Personal-knowledge-graph tools (lower effort, less power)¶

Logseq — open source (MIT-family), local Markdown files (fits data-sovereignty), built-in graph, outliner, zero infrastructure. Productive immediately.
Obsidian — graph view, free for personal use but not open source; plain Markdown.

Recommendation for MPowerUp's ethos¶

To think / research now → Logseq (open source, local Markdown, owns its data, zero infra).
To query / build features on the graph → Kùzu (embedded, MIT) or Neo4j Community (visualization + ecosystem). Kùzu fits "embed inside MPowerUp"; Neo4j fits "explore & visualize first."

6. The Four Architectures — Reference Summary¶

#	Architecture	Example	Servers in data path?	Servers sync each other?	Identity	Privacy profile	Authoritative reference
1	Peer-to-Peer	Jami	No	N/A	DHT crypto fingerprint	Strongest (content + metadata)	https://docs.jami.net/ · https://github.com/savoirfairelinux/opendht
2	Client–Relay	Nostr / Damus	Yes (relays)	No (client fans out)	Keypair (npub/nsec)	Censorship-resistant; weak metadata privacy; IP exposed to relays	https://github.com/nostr-protocol/nips
3	Federated	Mastodon / ActivityPub	Yes (instances)	Yes (server-to-server)	`instance@handle`	No single control point; home server sees all your data/metadata	https://www.w3.org/TR/activitypub/
4	Centralized / Open	Conventional baseline	Yes (one provider)	N/A (single)	Provider account	Max reach; operator sees everything; single point of failure	https://datatracker.ietf.org/doc/html/rfc8446 (TLS 1.3 baseline)

Key distinction to remember¶

The difference between client–relay (zone 2) and federated (zone 3) is whether the servers talk to each other: - Relays do NOT sync → your client does the work and sees everything. - Federated instances DO sync → your home server does the work and sees everything.

That distinction decides where metadata lives, which is the real privacy question for MPowerUp.

Reference notes¶

ActivityPub is a W3C Recommendation, standardized 23 January 2018, by the Social Web Working Group; it defines a client-to-server API plus a federated server-to-server API. Used by Mastodon, PeerTube, Threads, and others.
Nostr ("Notes and Other Stuff Transmitted by Relays") uses a client–relay model and public-key (Bitcoin-style) authentication; NIPs are the spec of record.
Damus official privacy guidance: your IP is exposed to relays and third-party media hosts; relays tie your pubkey to your IP; DM content is encrypted but DM metadata (who you message) is public; consider a VPN.

7. Architecture Diagram (Mermaid)¶

graph TD
    subgraph Z1["1 · PEER-TO-PEER  (Jami)"]
        direction LR
        A1(("Peer A")) <-->|direct encrypted| A2(("Peer B"))
        A1 <-->|direct encrypted| A3(("Peer C"))
        A2 <-->|direct encrypted| A3
        DHT["OpenDHT<br/>(discovery only,<br/>no message data)"]
        A1 -.lookup.-> DHT
        A2 -.lookup.-> DHT
        A3 -.lookup.-> DHT
    end

    subgraph Z2["2 · CLIENT-RELAY  (Nostr / Damus)"]
        direction LR
        C1["Client A<br/>(holds keypair)"]
        C2["Client B<br/>(holds keypair)"]
        R1["Relay 1"]
        R2["Relay 2"]
        R3["Relay 3"]
        C1 -->|publish / subscribe| R1
        C1 --> R2
        C1 --> R3
        C2 --> R1
        C2 --> R2
        R1 -. "relays do NOT<br/>sync each other" .- R2
        R2 -. "no server-to-server" .- R3
    end

    subgraph Z3["3 · FEDERATED  (Mastodon / ActivityPub)"]
        direction LR
        U1["User A"] --> S1["Instance 1<br/>(home server)"]
        U2["User B"] --> S2["Instance 2<br/>(home server)"]
        U3["User C"] --> S3["Instance 3<br/>(home server)"]
        S1 <-->|"server-to-server<br/>federation"| S2
        S2 <-->|federation| S3
        S1 <-->|federation| S3
    end

    subgraph Z4["4 · CENTRALIZED  (conventional baseline)"]
        direction LR
        B1["Client A"] --> CS["Single Provider<br/>Server"]
        B2["Client B"] --> CS
        B3["Client C"] --> CS
        CS -->|operator sees all| DBx[("Central DB")]
    end

    Z1 -->|"privacy down / reach up"| Z2
    Z2 --> Z3
    Z3 --> Z4

    classDef p2p fill:#d8f5e3,stroke:#1b7a44,color:#0a3d22;
    classDef relay fill:#dbe9ff,stroke:#1f5fbf,color:#0a2a5e;
    classDef fed fill:#efe0ff,stroke:#7a3fc0,color:#3a1a5e;
    classDef cen fill:#ffe0e0,stroke:#c0392b,color:#5e1a14;
    class A1,A2,A3,DHT p2p;
    class C1,C2,R1,R2,R3 relay;
    class U1,U2,U3,S1,S2,S3 fed;
    class B1,B2,B3,CS,DBx cen;

Reading the gradient: moving top → bottom (P2P → centralized), privacy and user-sovereignty decrease while reach, discovery, and convenience increase. This is the same spectrum as the MPowerUp security zones — Jami anchors the secure end; Nostr/Damus and Mastodon occupy the federated middle (with different metadata profiles); centralized is the open/unsecured baseline.

8. Open Questions Carried Forward¶

Purpose: What is the single thing MPowerUp lets a user do that they cannot do today? Who is the user?
Scope: Unified app embedding these / self-hostable bundle / integration layer or SDK?
Zone binding: Are zones a property of the conversation or the user's current mode?
Cross-zone policy: block / warn-and-downgrade / bridge-with-label?
Social layer reach: publicly reachable by design, or contained within MPowerUp?
Graph tool fork: thinking/notetaking surface (Logseq) vs. queryable data store (Kùzu / Neo4j)?
Licensing: copyleft implications of bundling Jami (and any GPL/AGPL components) with custom code.

9. Evaluated Tools — Scorecard¶

Tools rated on three independent privacy/trust axes. This is the same three-axis model the Damus analysis forced (Section 3): a single "secure/not secure" label is too coarse, so each tool is scored per axis.

The three axes¶

Private — does it avoid tracking/profiling and keep your data/metadata from third parties? (Distinguish policy-based privacy from architecture-based privacy.)
Autonomous — is it decentralized / self-sovereign, with no single operator you must trust and no single point of control or failure?
Secure — encrypted in transit and (where relevant) at rest; sound transport and content security.

Scoring key: ✓ = yes/strong · ~ = partial/conditional · ✗ = no/weak Privacy basis: Architecture (structure removes the ability to surveil) vs Policy (operator can, but promises not to). Architecture is more durable.

Tool	Category	Private	Autonomous	Secure	Privacy basis	Notes
Jami	P2P comms	✓	✓	✓	Architecture	No server in path; DHT discovery; content + metadata protected. Secure-zone anchor.
Briar	P2P messaging	✓	✓	✓	Architecture	Tor/Bluetooth/WiFi; no servers; offline-capable.
Nostr / Damus	Client–relay social	~	~	~	Mixed	Key-based identity & censorship-resistant, but IP exposed to relays; DM content encrypted yet DM metadata public. Not secure-zone for DMs.
Mastodon / ActivityPub	Federated social	~	~	✓	Policy (per-instance)	No single control point, but home instance sees your data/metadata; trust shifts to operator.
GoToSocial	Federated social (minimal)	~	~	✓	Policy (per-instance)	Single-binary, low-resource self-host; same federation trust model, but you can be the operator.
Scuttlebutt (SSB)	P2P social	✓	✓	✓	Architecture	Gossip-based, offline-first; niche/quirky.
Jitsi	Video conferencing	~	✗	✓	Policy + self-host	1:1 can be P2P; multi-party routes through Videobridge. Self-hostable. (Dropped from MPowerUp.)
DuckDuckGo	Centralized search	~	✗	✓	Policy	Blocks 3rd-party trackers, doesn't profile; but centralized US company that receives your IP and promises not to log. Zone-4 example.
Logseq	Knowledge graph (local)	✓	✓	~	Architecture (local files)	Open-source, local Markdown; privacy by staying on-device. "Secure" depends on your own disk/sync choices.
Kùzu	Embedded graph DB	✓	✓	~	Architecture (embedded)	MIT, no server; runs inside your app. Security = your host environment.
Neo4j Community	Graph DB (server)	~	~	✓	Self-host	Private if self-hosted; you operate it. GPLv3 Community edition.

How to read this for MPowerUp¶

Architecture-based privacy beats policy-based privacy for the secure zone. Jami/Briar/SSB qualify; DuckDuckGo/Mastodon rely on operator trust.
"Autonomous ✗" tools are inherently zone-4 (centralized) regardless of how good their privacy policy is — DuckDuckGo is the clearest case: private ✓ (policy), secure ✓ (transport), autonomous ✗ (centralized company).
A tool can be excellent yet wrong-zone: DuckDuckGo is a fine private search engine but structurally the opposite of MPowerUp's thesis (remove the need to trust an operator).

This scorecard is maintained going forward with the tool-eval skill (add / list / view tools with research status new / tried / evaluated / adopted / rejected and a score).

End of research notes.