discussion points and summary

Trolli Schmittlauch 2019-09-02 16:45:41 +02:00
parent f2280de2ba
commit 1cda712789
1 changed files with 91 additions and 19 deletions

View File

@ -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
\note[item]{for joining and leaving the DHT see paper}
@ -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}
% for Kolloquium, add simulation result
@ -413,10 +415,6 @@ distribution of posts per hashtag follows a steep power law
why even still use classic push federation?
\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?
\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?
\subsection{Technical Considerations}
\begin{frame}{Technical Considerations}{instance admins}
\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?
\item batched retrieval of posts from same source
\item exponential backoff retries
load and capacity factor
\begin{frame}{Technical Considerations}{integration into the ActivityPub Fediverse}
\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}
\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
\item DHT routing communication does not use ActivityPub
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''}
\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}
\(h_n =\) hash(IPv6\_addr[0,63] ++ vserver)[0,63] \\
++ hash(domain ++ vserver)[0,127] \\
++ hash(IPv6\_addr[0,63] ++ vserver)[64,127]
node ID derivation}
\subsection{Security Considerations}
\begin{frame}{Security Considerations}
\item attacker shall not be able to deliberately gain responsibility for certain hashtags
\item node ID mainly dependant on IPv6 subnet
\item attacker shall not introduce arbitrary number of nodes
\item valid domain required for node ID derivation, assumption: domains cost money
security: node ID derivation scheme
@ -444,15 +512,18 @@ security: node ID derivation scheme
% Keep the summary *very short*.
things can be \alert{highlighted}.
decentralised architecture for handling posts of the same hashtag:
\item \alert{subscribe to hashtag} and get posts \alert{relay}ed
\item \alert{query stored posts} of a certain hashtag without subscription
\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
% The following outlook is optional.
\vskip0pt plus.5fill
%\vskip0pt plus.5fill
@ -471,17 +542,18 @@ security: node ID derivation scheme
\begin{frame}{Complete Paper}
\center\huge{Questions, comments, feedback?}
\center\huge{Thank you for your attention!}
%\includegraphics[height=0.5\textheight]{figures/nomnompingu.png}\tiny\footnote{CC-BY-SA 3.0 by Elektroll}