diff --git a/figures/finger_table_routing_1.pdf b/figures/finger_table_routing_1.pdf new file mode 100644 index 0000000..439c8c1 --- /dev/null +++ b/figures/finger_table_routing_1.pdf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:e75de148f295222e8906158b8a20ca7d4d072687160b6e3ca6234e940e5aeadb +size 22361 diff --git a/figures/finger_table_routing_2.pdf b/figures/finger_table_routing_2.pdf new file mode 100644 index 0000000..4e71a92 --- /dev/null +++ b/figures/finger_table_routing_2.pdf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:30775cc629157ec93e3e00dceb8ad637e83a03bbeb3777b621986e563352763f +size 17675 diff --git a/figures/redundancy_ring.pdf b/figures/redundancy_ring.pdf new file mode 100644 index 0000000..8d9bbb4 --- /dev/null +++ b/figures/redundancy_ring.pdf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:9805289da0aa5ba0fb7e2af71b34d9b3e414bc31fd6a550678f23a12bc29df7e +size 8733 diff --git a/figures/redundancy_ring.svg b/figures/redundancy_ring.svg new file mode 100644 index 0000000..e485596 --- /dev/null +++ b/figures/redundancy_ring.svg @@ -0,0 +1,115 @@ + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + original + first redundancy level + second redundancy level + + diff --git a/shell.nix b/shell.nix index 90f1f17..bea4e51 100644 --- a/shell.nix +++ b/shell.nix @@ -29,6 +29,9 @@ mkShell { logreq koma-script xits + stix + stix2-otf + stix2-type1 opensans ; @@ -38,9 +41,9 @@ mkShell { }; }) biber - opensans-ttf - xits-math - stix-otf + #opensans-ttf + #xits-math + #stix-otf fontconfig # for instance DNS query script @@ -63,5 +66,5 @@ mkShell { ]; # for font discovery - FONTCONFIG_FILE = makeFontsConf { fontDirectories = [ lmodern opensans-ttf xits-math stix-otf ]; }; + FONTCONFIG_FILE = makeFontsConf { fontDirectories = [ lmodern texlive.opensans.pkgs texlive.stix.pkgs ]; }; } diff --git a/talk-slides.tex b/talk-slides.tex index 9c61fb8..ddedbce 100644 --- a/talk-slides.tex +++ b/talk-slides.tex @@ -44,6 +44,7 @@ \usepackage[backend=biber, sorting=none]{biblatex} \usepackage{ccicons} +\usepackage{wrapfig} \usepackage{ifluatex} @@ -298,14 +299,124 @@ Hashtags are used for marking posts about certain topics or events: \end{itemize} \end{frame} -\begin{frame}{System Architecture}{adding a P2P backend to the fediverse} +\begin{frame}{System Architecture}{adding a DHT backend to the fediverse} -core idea: distributing responsibility for tags using a \textbf{D}istributed \textbf{H}ash \textbf{T}able \note{distribute responsibility for posts of a hashtag = relaying \& storage} +core idea: distribute responsibility for tags among instances using a \textbf{D}istributed \textbf{H}ash \textbf{T}able, \note{distribute responsibility for posts of a hashtag = relaying \& storage} + +based on Chord + +\note[item]{DHT: structured P2P networks providing efficient (log N) key-value storage and lookup} +\note[item]{self-organising, no central authority} \end{frame} +\begin{frame}{System Architecture}{adding a DHT backend to the fediverse} +\begin{columns} +\begin{column}{0.4\textwidth} + \begin{itemize} + \item calculate hash value of keys and node IDs + \item place these hashes onto the same circular name space + \item each node keeps routing table of \(\log \#number\_nodes\) entries\note[item]{joining and leaving covered in paper} + \end{itemize} +\end{column} + +\begin{column}{0.6\textwidth} + \includegraphics[height=0.62\paperheight]{figures/finger_table_routing_1.pdf} +\end{column} +\end{columns} +\end{frame} + +\begin{frame}{System Architecture}{adding a DHT backend to the fediverse} +\begin{columns} +\begin{column}{0.55\textwidth} + \begin{itemize} + \item next nodeID \(\geq\) \texttt{hash(hashtag)} (mod keyspace size) is responsible for handling posts containing \texttt{hashtag} + \item DHT used for iterative lookup of responsible relay/ storage node + \end{itemize} +\end{column} + +\begin{column}{0.45\textwidth} + \includegraphics[height=0.62\paperheight]{figures/finger_table_routing_2.pdf} +\end{column} +\end{columns} +\end{frame} + +\begin{frame}{Publishing, Relaying and Storage}{lifecycle of posts} + \begin{enumerate} + \item publishing instance looks up responsible relay instance on DHT for each included hashtag + \item publishing instance sends post to responsible relay instance + \item relay instance looks up responsible storage node on DHT + \item relay instance verifies incoming post's signature, then relays post URI (ID) to all subscribers + storage node\note[item]{only post ID relayed, but not full post content. Reasons: LDSignatures not supported everywhere, deniability \& revocation} + \item subscribing instances can now retrieve the full authenticated post from received post URI + \end{enumerate} + +\end{frame} + +\begin{frame}{Publishing, Relaying and Storage} +\begin{itemize} + \item separate DHTs for relay and storage instances + \item all actions after DHT lookup supposed to be done using ActivityPub via HTTPS + \item subscription to hashtags/ querying posts is done at the responsible instance +\end{itemize} + +\end{frame} + +\begin{frame} +\note{so far so easy. But load distribution issues} +\begin{itemize} + \item node ID determines set of hashtags handled by instance + \item problem: for security reasons, node \textbf{must not} choose their IDs freely + \item Can instances be overloaded by their assigned hashtag posts? +\end{itemize} +\end{frame} + +\begin{frame}{Distribution of Posts per Tag} +\includegraphics[width=0.49\textwidth]{statistics/twitter_hashtags_total.png} +~ +\includegraphics[width=0.49\textwidth]{statistics/geraspora_hashtags_total.png} + +\note{analysis of a 1 month dump of Twitter, Geraspora (Diaspora) and Friendica posts\\ +Twitter: 70\% of posts used just once\\ +note the logarithmic axis!} + +distribution of posts per hashtag follows a steep power law + +\note{So what if a small node gets several large hashtags? => need for load balancing} +\end{frame} + +\begin{frame}{Load Balancing}{of hashtags between nodes} + \begin{itemize} + \item \textit{k-choices} algorithm by Ledlie and Seltzer + \item each node can choose from \(\kappa\) possible IDs + \item nodes have a \textbf{capacity} and choose set of active IDs according to lowest mismatch of own and neighbour node capacity + \item querying load of potential IDs before joining, periodic re-balancing + \item independent load balancing of relay and storage nodes due to independent DHTs + \end{itemize} +% for Kolloquium, add simulation result +\end{frame} + +\begin{frame}{Redundancy} +\begin{columns} +\begin{column}{0.55\textwidth} +\begin{itemize} + \item store redundant copies of hashtag data at equal distances on Chord ring\note{resilience against node failure, allows data validation through cross-checking} + \item default redundancy: \(2^2 = 4\), scalable in powers of 2 + \item \textbf{relay nodes}: hot standby nodes take over in overload situations (load spikes) + \item \textbf{storage nodes}: overloaded nodes can split stored posts by content hash and double redundancy set +\end{itemize} +\end{column} + +\begin{column}{0.45\textwidth} + \includegraphics[width=\textwidth]{figures/redundancy_ring.pdf} +\end{column} +\end{columns} +\end{frame} + + + why even still use classic push federation? + \section{Discussion} \begin{frame}{Discussion}{I need YOUR feedback} @@ -322,6 +433,10 @@ CloudFlare load and capacity factor +performance: batching, exponential back-off, no relayable sigs + +security: node ID derivation scheme + \section{Summary} \begin{frame}{Summary}