\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?
\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}
\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}
\begin{frame}{Technical Considerations}{node ID assignment}
load and capacity factor
\note[item]{Let's talk about the elephant in the room of ``federated services''}