commit babd55b6d2461d637fee2f7a06dc4e4e1f1c8365
parent 0319d58c823e50fc8f7776408f1e07dcf20aea65
Author: Andrew Laack <andrew@laack.co>
Date: Wed, 4 Feb 2026 16:05:16 -0600
Took some notes on interesting pieces of software
Diffstat:
9 files changed, 265 insertions(+), 10 deletions(-)
diff --git a/docs/Briar.md b/docs/Briar.md
@@ -0,0 +1,59 @@
+# Briar
+
+## High Level
+
+- Peer to peer over (functionally) any medium
+ - Tor
+ - WiFi
+ - Bluetooth
+ - etc.
+- Uses delay cryptographic protocols tailored for delay-tolerant p2p communciation
+ - BHP
+ - BQP
+ - BTP
+- Claimed forward security
+- Resistant to
+ - eavesdropping
+ - tampering
+ - traffic analysis
+
+## Specifics
+
+- Bramble
+ - Underlying decentralized framework for Briar
+- Bramble handshake protocol (BHP)
+ - Key agreement protocol that allows two peers to establish a shared key
+- Bramble QR code protocol (BQP)
+ - Key agreement protocol that allows peers to establish an ephemeral shared key locally
+- Bramble rendezvous protocol (BRP)
+ - Discovery protocol, allowing two peers having exchanged keys to setup a P2P connection
+- Bramble synchronisation protocol (BSP)
+ - Application layer data synchronization protocol, allowing group members to sync messages over dealy-tolerant networks
+- Bramble transport protocol (BTP)
+ - Transport layer security protocol in Briar
+
+- Account setup (all done locally)
+ - set nickname and password
+ - generates
+ - a signing key pair (spk, ssk)
+ - a handshake key pair (hpk, hsk)
+ - NOTE: There is no way to transfer accounts
+ - I don't really know why tbh, seems possible, just copy state...
+
+- Adding contacts
+ - QR code
+ - two peers nearby scan each other's QR codes containing an ephemeral public key (epk)
+ - derive a shared key mk
+ - these QR codes are generated uniquely every time
+ - Handshake links
+ - two peers exchange their handshake links out-of-band, which contain their handshake public keys
+ - use BRP to establish a Tor connection protected by a static key
+ - run BHP over the connection to create a shared secret key mk
+ - Introduction
+ - A user may introduce two of their contacts by sending requests to both of them
+ - Both contacts accept the introduction
+ - The introduced can relay protocol messages between the contacts
+ - The contacts cna then derive a shared secret key mk, unknown to the introducer and exchange their contact info
+
+- Sending messages
+ - Messages are synced between peers using the BSP.
diff --git a/docs/ComputerSecurity.md b/docs/ComputerSecurity.md
@@ -1,6 +1,6 @@
# Computer Security
-Main index for notes related to CSCI 370, Computer Security
+Main index for notes related to CSCI 370, Computer Security, and other security topics>
## Chapter 1 - Background
@@ -90,3 +90,12 @@ Main index for notes related to CSCI 370, Computer Security
### 9.1
- [RSA](RSA.md)
+
+## Other Topics
+
+- [XMPP](XMPP.md)
+- [Briar](Briar.md)
+- DoubleRatchet
+- SASL
+- Tor
+- [OnionService](OnionService.md)
diff --git a/docs/Cryptography.md b/docs/Cryptography.md
@@ -4,8 +4,6 @@
**Chapter:** 1.6
-
-
**Definition:** Cryptography is the transformation of data from one form to another.
This can be thought of mathematically as a function.
diff --git a/docs/FreeSoftware.md b/docs/FreeSoftware.md
@@ -1,12 +1,12 @@
# Free Software
-## Bad Software
+## Note Taking
-- GIF
-- TIFF
-- JPG
-- LZW Compression
+### Graphical
-## Good Software
+- Emacs
+- [QOwnNotes](QOwnNotes.md)
-- PNG
+### Terminal
+
+- VIM / VI
diff --git a/docs/MachineLearning.md b/docs/MachineLearning.md
@@ -184,3 +184,4 @@ Links to ML Notes
- [Data Augmentation](DataAugmentation.md)
- [SMOTE](SMOTE.md)
- [Latent Space](LatentSpace.md)
+- [Shapley Value](ShapleyValue.md)
diff --git a/docs/OnionService.md b/docs/OnionService.md
@@ -0,0 +1,32 @@
+# Onion Service (Tor Hidden Service)
+
+**Definition:** An onion service is site accessed through the Tor network.
+
+## How It Works
+
+### Registering the Server
+
+#### Setup
+
+1. Compute a public private key pair
+2. Compute the hash of the two to serve as the domain name
+ - Can be done a bunch of times with the public private key gen to get a name you want
+3. Connect to Tor
+4. Contact a bunch of Tor relays, asking them to be your introduction point
+ - Can have many introduction points at the same time
+
+#### Discovery
+
+1. Create Onion Service descriptor with a list of introduction points and authentication keys signed with private key
+2. Upload the signed descriptor to a distributed hash table
+
+### Resolution
+
+1. Client has Onion address
+2. Lookup signed descriptor for the Onion service
+3. Verify signature
+4. Client picks a Tor relay and establishes a Tor circuit
+5. Client asks Tor relay to become rendezvous point and gives it a one-time-secret
+6. Introduction point passes details to the hidden service
+7. Onion service checks validity of data and connects to the rendezvous point
+8. Rendezvous point relays encrypted messages from client to service and vice versa
diff --git a/docs/QOwnNotes.md b/docs/QOwnNotes.md
@@ -0,0 +1,34 @@
+# QOwnNotes
+
+**Source:** [https://www.qownnotes.org/](https://www.qownnotes.org/)
+
+**Date reviewed:** 2026/02/01
+
+## Features
+
+- Qt based, primarile written in C++
+- GPL v2.0 License
+- Notes stored as plaintext
+- Multi-platform support and nice integration options
+ - I don't care about this, but might be nice to some
+- First party encryption
+- Automatic git versioning feature
+
+## Anti-Features
+
+- Default on user tracking
+ - [https://github.com/pbek/QOwnNotes/issues/1710](https://github.com/pbek/QOwnNotes/issues/1710)
+ - Sane response from maintainer, but dissapointing
+- Auto-updating withouth the ability to diable
+ - [https://github.com/pbek/QOwnNotes/issues/1711](https://github.com/pbek/QOwnNotes/issues/1711)
+
+## My Notes on Usage
+
+- Unable to render in-line latex
+- Lots of layout options
+- AI integrations
+ - Default off so almost acceptable
+
+## Conclusion
+
+Without the ability to disable auto-updating, this is a non-starter for me. A necessary feature of any note-taking applicaton I would consider is it must be possible to disable all network requests from the base application.
diff --git a/docs/ShapleyValue.md b/docs/ShapleyValue.md
@@ -0,0 +1,61 @@
+# Shapley Value
+
+**Source:** [https://en.wikipedia.org/wiki/Shapley_value](https://en.wikipedia.org/wiki/Shapley_value)
+
+**Definition:** The Shapley value is a method for distributing gains / costs among a group that contributed to an objective.
+
+## Collaborative Game Theory Formalization
+
+Assume we have a group of players who are trying to win rewards by cooperating (forming a coalition). For a given coalition $S$ the reward function $v(S)$ gives the total sum of rewards for each member of the coalition when cooperating.
+
+The Shapley value gives a way to divide the reward created by a coalition among its members. According to this metric:
+
+$\phi(i) = \frac{1}{n!} \sum_R [v(P^R_i \cup \{i\}) - v(P_i^R)$
+
+Where $i$ is the player, $n$ is the total number of players, $R$ is all permutations of players, $v$ is defined as above, $P^R_i$ is the set of players from $N$ which preced $i$ in the order $R$.
+
+## Approximation for Machine Learning
+
+In machine learning we don't have the luxury of computing true Shapley values because evaluating all possible coalitions of features is often too expensive, and we can't do counter-factual evaluations across all possible coalitions, so we settle for different approaches that attempt to quantify the same idea. One popular approximation uses Monte-Carlo sampling, referred to as the Monte Carlo Shapley value. Below is this formalization.
+
+$\phi(i) = \frac{1}{n} \sum_{\sigma\in\Pi} [v([\sigma]_{i-1} \cup \{i\}) - v([\sigma]_{i-1})]$
+
+For a uniform smaple of permutations $\Pi$ of size $n$.
+
+### Example
+
+1. Assume our baseline output $a$ is $E[f(X)]$.
+2. Initialize $\phi$ as array of size $n$ with all zeroes
+3. For m = 1 to M
+ - Sample a random permutation $\sigma$ of $\{1,2,...,n\}$
+ - $S = \empty$
+ - $\text{current\_value} = \text{baseline}$
+ - for feature j in $\sigma$
+ - $S = S \cup \{j\}$
+ - new_value $= E[f(X) | X_S = x_S]$
+ - $\phi[j] = \phi[j] + (\text{new\_value} - \text{current\_value})$
+ - current_value = new_value
+4. For i = 1 to n
+ - $\phi[i] = \phi[i] / M$
+
+### Put Simply
+
+To calculate the approximate Shapley value for a given sample $x$ from the dataset:
+
+- We start with a baseline of the average output across our dataset $X$ with respect to the model $f$. We call this baseline $a$.
+- We then create our baseline importance score vector with all zeroes, each index representing how much the given feature contributes to the output of the function $f$.
+- We then repeat the following procedure M times:
+ 1. Shuffle the features randomly
+ 2. Start with the empty set of known features
+ 3. Go through the features one by one in the shuffled order
+ - Replace the baseline feature's value for the specified feature with the feature's value in $x$.
+ - Compute how much this impacts the model's output
+ - current iteration's output - prior iteration's output wrt. $f$
+ - Add this change to the feature's score in the importance score vector
+- We then divide each feature's score from the importance score vector by $M$ to find the average change the feature caused wrt. the baseline.
+
+The above calculates the approximate Shapley value for a single sample from the dataset where $M$ is the number of permutations we test for the given sample. We often do the above loop (inner loop) a number of times to average across randomly selected samples from our dataset to compute an approximation for the Shapley value across the dataset.
+
+### Implementation
+
+TODO
diff --git a/docs/XMPP.md b/docs/XMPP.md
@@ -0,0 +1,61 @@
+# XMPP
+
+**Source:** RFC 6120
+
+**Definition:** XMPP is a protocol for the distribution of XML stanzas (small bits of XML) over a network between two or more entities.
+
+## Important Info
+
+- Federated
+- Runs over TLS
+- Clients may choose to support E2E encryption
+ - OMEMO is the main way of doing this
+-
+
+## Specifics
+
+- Presence stanzas are used to inform other entities about the precsence of a given entity
+- Persistent streams
+ - Point-to-point hops use persistent XML streams over long-lived TCP connections\* to enable parties to push data to each other for immediate routing or delivery
+ - There are implementations over HTTP, but the standard specifies TCP
+- XML stanzas are sent over an XML-stream for communication
+ - The root of these stanzas includes the from and to addresses, which are JIDs (Jabber IDs for historical reasons), that have the same format as email where the domain name is the domain name for the server.
+ - One nuance is the resource part of the domain is for multi-client support per account.
+ - Possible examples
+ - andrew@smt.example.com/phone
+ - andrew@smt.example.com/desktop
+- This is a client-to-server server-to-client protocol for messaging. There are no P2P elements, even though there are some XMPP-like systems that use P2P with XML streams and stanzas
+- A client establishes a stream with a server after performing a SASL negotiation for authentication
+ - Once done, the client can send stanzas to the server which will then be routed to the local client on the same server or the home server of the remote client
+- Core server responsibilities
+ - Manage XML streams with clients and deliver XML stanzas
+ - Manage XML streams with remote servers and route XML stanzas
+- Some possible secondary responsibilities of servers are
+ - Store data used by clients
+ - Contact lists, presence applications, etc
+ - These are to be handled by the server on behalf of the client and are not to be routed to remote servers
+ - Add-on services
+ - Additional services that are beyond the scope of RFC 6120
+ - Examples being multi-user conferencing and pub-sub services
+ - These are frequently accessible via subdomains
+- Standard client port is 5222
+- Standard server port is 5269
+
+## Message Types
+
+- Presence
+ - Notify entities of your existence
+- IQ
+ - Info / query
+- Message
+ - contains to parameter and body of the msesage
+
+These messages are sent as stanzas which are simply elements within the \<stream\> tag.
+
+## E2E
+
+The XMPP spec **does not** support E2E encryption. It does support TLS encryption for communication channels, but messages will be sent in plaintext underneath the TLS. The common approach to achieving E2E with XMPP is with OMEMO encryption.
+
+### OMEMO
+
+OMEMO uses the double ratchet encryption algorithm for forward secrecy and X3DH for shared key consensus.
