discussion points and summary
parent
f2280de2ba
commit
1cda712789
110
talk-slides.tex
110
talk-slides.tex
|
|
@ -349,6 +349,7 @@ based on Chord
|
|||
\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}
|
||||
\note[item]{for joining and leaving the DHT see paper}
|
||||
|
||||
\end{frame}
|
||||
|
||||
|
|
@ -391,6 +392,7 @@ distribution of posts per hashtag follows a steep power law
|
|||
\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
|
||||
\note[item]{a simple simulation on the effectivity of the balancing algorithm can be found in the paper}
|
||||
\end{itemize}
|
||||
% for Kolloquium, add simulation result
|
||||
\end{frame}
|
||||
|
|
@ -413,10 +415,6 @@ distribution of posts per hashtag follows a steep power law
|
|||
\end{frame}
|
||||
|
||||
|
||||
|
||||
why even still use classic push federation?
|
||||
|
||||
|
||||
\section{Discussion}
|
||||
|
||||
\begin{frame}{Discussion}{I need YOUR feedback}
|
||||
|
|
@ -427,15 +425,85 @@ I want feedback from all of you, no matter whether it's from a \textit{\LARGE te
|
|||
|
||||
\subsection{Social Considerations}
|
||||
|
||||
\begin{frame}{Social Considerations}
|
||||
Do we even want global hashtags in the Fediverse?
|
||||
|
||||
\begin{itemize}
|
||||
\item positive potential (conversation, coordination) vs. negative potential (spam, harrasment)
|
||||
\item visibility level: public posts only, unlisted, new level necessary?
|
||||
\item relaying post URI only should provide plausible deniability
|
||||
\item Does this circumvent instance-blocks and is this bad?
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
|
||||
\subsection{Technical Considerations}
|
||||
|
||||
CloudFlare
|
||||
\begin{frame}{Technical Considerations}{instance admins}
|
||||
|
||||
\begin{itemize}
|
||||
\item intended as opt-in, domain-based push federation still better for user subscriptions
|
||||
\item assumption: instances offer \(5.5\times\) the storage \& \(2.5\times\) the bandwith of own posts
|
||||
\item performance: Can this be implemented efficiently enough to not DDoS popular hashtag nodes?
|
||||
\begin{itemize}
|
||||
\item batched retrieval of posts from same source
|
||||
\item exponential backoff retries
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
load and capacity factor
|
||||
\begin{frame}{Technical Considerations}{integration into the ActivityPub Fediverse}
|
||||
\begin{itemize}
|
||||
\item This architecture is an unimplemented concept so far!
|
||||
\item integration into ActivityPub ecosystem\note[item]{disclaimer: I'm new to ActivityPub and have no implementation experience}
|
||||
\begin{itemize}
|
||||
\item hashtags may be represented as relay actors with own in- \& outbox, addressed in cc
|
||||
\item relaying to subscribers via SharedInbox
|
||||
\item idea for addressing: new URI scheme that gets transparently resolved to responsible node's domain via DHT\note[item]{application proxy for transparent URI scheme resolving?}
|
||||
\item signalling of error codes and redundancy factors is needed
|
||||
\end{itemize}
|
||||
\item DHT routing communication does not use ActivityPub
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
performance: batching, exponential back-off, no relayable sigs
|
||||
\begin{frame}{Technical Considerations}{node ID assignment}
|
||||
|
||||
\note[item]{Let's talk about the elephant in the room of ``federated services''}
|
||||
\centering
|
||||
\includegraphics<1>[height=0.59\paperheight]{figures/Elephant_Friend_(Greeting).png}
|
||||
\includegraphics<2,4>[height=0.59\paperheight]{figures/hist_num_single_vs.png}
|
||||
|
||||
\note[item]{sorry to all instance admins, but: CloudFlare behaves like a MITM/ Sybil attacker}
|
||||
|
||||
\only<2,4>{1st peak: Masto.host, 2nd peak: Cloudflare}
|
||||
|
||||
\only<3>{{\ttfamily
|
||||
\(h_n =\) hash(IPv6\_addr[0,63] ++ vserver)[0,63] \\
|
||||
++ hash(domain ++ vserver)[0,127] \\
|
||||
++ hash(IPv6\_addr[0,63] ++ vserver)[64,127]
|
||||
}
|
||||
\vspace{2em}
|
||||
|
||||
node ID derivation}
|
||||
|
||||
\end{frame}
|
||||
|
||||
\subsection{Security Considerations}
|
||||
\begin{frame}{Security Considerations}
|
||||
\begin{itemize}
|
||||
\item attacker shall not be able to deliberately gain responsibility for certain hashtags
|
||||
\begin{itemize}
|
||||
\item node ID mainly dependant on IPv6 subnet
|
||||
\end{itemize}
|
||||
|
||||
\item attacker shall not introduce arbitrary number of nodes
|
||||
\begin{itemize}
|
||||
\item valid domain required for node ID derivation, assumption: domains cost money
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
|
||||
\end{frame}
|
||||
|
||||
security: node ID derivation scheme
|
||||
|
||||
\section{Summary}
|
||||
|
||||
|
|
@ -444,15 +512,18 @@ security: node ID derivation scheme
|
|||
% Keep the summary *very short*.
|
||||
\begin{itemize}
|
||||
\item
|
||||
things can be \alert{highlighted}.
|
||||
decentralised architecture for handling posts of the same hashtag:
|
||||
\begin{itemize}
|
||||
\item \alert{subscribe to hashtag} and get posts \alert{relay}ed
|
||||
\item \alert{query stored posts} of a certain hashtag without subscription
|
||||
\end{itemize}
|
||||
\item responsibility for hashtag divided among instances using a DHT
|
||||
\item architecture \alert{balances the load} between nodes and maintains \alert{redundancy}
|
||||
\item several open questions before implementation
|
||||
\end{itemize}
|
||||
|
||||
% The following outlook is optional.
|
||||
\vskip0pt plus.5fill
|
||||
\begin{itemize}
|
||||
\item
|
||||
Outlook
|
||||
\end{itemize}
|
||||
%\vskip0pt plus.5fill
|
||||
\end{frame}
|
||||
|
||||
|
||||
|
|
@ -471,17 +542,18 @@ security: node ID derivation scheme
|
|||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Complete Paper}
|
||||
\center
|
||||
\includegraphics[height=0.45\paperheight]{figures/qr_paper.png}\\
|
||||
\url{https://git.orlives.de/schmittlauch/paper_hashtag_federation/src/branch/master/paper_hashtag_federation.pdf}
|
||||
\begin{frame}
|
||||
|
||||
\center\huge{Questions, comments, feedback?}
|
||||
|
||||
\includegraphics[height=0.4\paperheight]{figures/qr_paper.png}\\
|
||||
\large\url{https://git.orlives.de/schmittlauch/paper_hashtag_federation/src/branch/master/paper_hashtag_federation.pdf}
|
||||
|
||||
\end{frame}
|
||||
|
||||
|
||||
\begin{frame}
|
||||
|
||||
\center\huge{Thank you for your attention!}
|
||||
|
||||
%\includegraphics[height=0.5\textheight]{figures/nomnompingu.png}\tiny\footnote{CC-BY-SA 3.0 by Elektroll}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue