HOSN-app/thesis/content/05-proof-of-concept/runtime-view.tex

This section describes concrete processes and relationships between building blocks for two selected scenarios. The first is to write and post a tweet and the second is to display the home timeline. In addition to the description, the two scenarios are also documented by flowcharts.

The goal is to make clear how the building blocks of the system perform their respective tasks and communicate with each other at runtime. The two scenarios were therefore deliberately selected because they are of particular importance and require special documentation due to their complexity.

\subsection{Post a Tweet}
\label{sec:post-a-tweet}

On the write-tweet page, new tweets can be written and posted using a form. In addition to the input field for the message text, there is also a status display that informs the user about the character limit, a switch that decides about the target network, and a button to send. The process of writing and publishing a tweet is shown in the flow chart in Figure \ref{fig:post-tweet-flow-chart}. Figure \ref{fig:post-tweet-building-block-view} shows the involved components in the block view.

\begin{figure}[h!]
	\centering
	\includegraphics[width=1.0\textwidth]{post-tweet-flow-chart}
	\caption{Flow chart of the process for posting a new tweet either on the public Twitter network or on the private P2P network}
	\label{fig:post-tweet-flow-chart}
\end{figure}

\begin{figure}[h!]
	\centering
	\includegraphics[width=1.0\textwidth]{post-tweet-building-block-view}
	\caption{Building block view of the interaction between the different modules when posting a new tweet}
	\label{fig:post-tweet-building-block-view}
\end{figure}

After entering the message in the input field, determining the destination network, and pressing the \enquote{TWEET!} button, processing starts in the WriteTweetPage class. If the message is destined for Twitter, the Twitter API provider sends a HTTP POST request with the data to the \texttt{statuses/update}\footnote{https://developer.twitter.com/en/docs/tweets/post-and-engage/api-reference/post-statuses-update} interface. In this case, nothing more needs to be done, as the Twitter API takes over the preparation of the data and extracts, for example, hashtags, mentions and URLs.

When publishing in the private network, the system first checks whether the public key has already been published. The Crypto provider performs this check using the Twitter API provider (for further information about the handling of public keys see the section about security \ref{sec:security}). If the public key has not yet been published, the user receives a warning and the posting process is aborted. Otherwise the private tweet will be constructed. The entered text is converted into a simplified tweet object (see Twitter documentation for original tweet object\footnote{https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/tweet-object.html}) that contains the essential information.

Beside the message (\texttt{full\_text}) the Twitter user id (\texttt{user\_id}) and the timestamp (\texttt{created\_at}) are set. In addition, there is a flag (\texttt{private\_tweet: true}) to distinguish the private tweet, which later influences the design. The \texttt{display\_text\_range} indicates the beginning and end of the relevant part in \texttt{full\_text}. For private tweets this is always the entire text, for tweets from the Twitter API an additional URL may be appended, which is not necessary due to clipping. Furthermore, the tweet entities are extracted. This includes URLs, hashtags and user mentions. An example of a private tweet is shown in Listing \ref{listing:private-tweet}.

\lstinputlisting[label=listing:private-tweet, caption=Private Tweet in JSON format]{listings/private-tweet.json}

The encryption of the private tweet data is performed by the crypto provider. The RSA algorithm is used for asymmetrical encryption. The encrypted data is transmitted via the P2P storage provider via POST request to Infura for storage in IPFS. The response contains the hash under which the data can be found in IPFS. This hash is stored in Gun together with the time stamp and the author's Twitter user id. This is done through the P2P DB provider. In addition, the previously extracted hash tags with the time stamp are also stored in Gun with the same provider, so that the data in the dashboard is accessible to the service provider without having to draw conclusions about individual users.

\subsection{Load the Home Timeline}
\label{sec:load-home-timeline}

When opening the home page, the logged in user gets the latest tweets of the accounts he follows chronologically presented. The tweets are loaded in batches of 20 tweets from the Twitter API and enriched with the private tweets for this time period. If the user scrolls to the end of the feed, the reloading of the next batch is triggered and automatically inserted at the end. A pull to refresh can be triggered at the top of the feed. The process is shown in Figure \ref{fig:home-timeline-flow-chart} as a flow chart and in Figure \ref{fig:home-timeline-building-block-view} as a building block view of the interacting components.

\begin{figure}[h!]
	\centering
	\includegraphics[width=1.0\textwidth]{home-timeline-flow-chart}
	\caption{Flow chart of the process for loading the home timeline for a user}
	\label{fig:home-timeline-flow-chart}
\end{figure}

\begin{figure}[h!]
	\centering
	\includegraphics[width=1.0\textwidth]{home-timeline-building-block-view}
	\caption{Building block view of the interaction between the different modules when loading the home timeline of a user}
	\label{fig:home-timeline-building-block-view}
\end{figure}

Starting point is the home page, which is accessed by the user. Using several components, the data obtained from the feed provider is displayed. Using the Twitter API provider, the feed provider loads the latest 20 timeline tweets via the corresponding interface (\texttt{statuses/home\_timeline}\footnote{https://developer.twitter.com/en/docs/tweets/timelines/api-reference/get-statuses-home\_timeline.html}) via a HTTP GET request.

The next step is to load the private tweets that match the time period marked by the current timestamp and timestamp of the 20th (the oldest) tweet. Furthermore, the user ids of the users the user follows (so called friends) are required. These must initially be requested from the Twitter API (\texttt{friends/list}\footnote{https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-friends-list}) via the Twitter Feed provider using a HTTP GET request. The loaded user ids are cached in order to keep the number of requests to the Twitter API to a minimum for later loading processes. For each user id a lookup for private tweets in the given time span is performed. This is done by the P2P DB provider who queries Gun. If there are private tweets, the hashs for IPFS are returned together with the \texttt{created\_at} timestamp. If no private tweets are available for the period, the feed provider returns the data of the public tweets to the home page.

Otherwise, the private tweets must be loaded and decrypted. First, the P2P Storage provider is used to load the data behind the hash addresses from IPFS via Infura. For this purpose, the hash is transferred to Infura with a HTTP GET request and the data is received from IPFS as response. To decrypt the data, the author's public key is required. The public key is stored in the user's public key history. This is loaded and decrypted via the Crypto provider, which in turn uses the Twitter API provider. The private tweet is then decrypted with the appropriate public key.

Finally, the private and public tweets are merged and sorted according to their \texttt{created\_at} timestamp in descending order. This data is returned to the home page. If the user triggers a reload by reaching the end of the feed or by pull to refresh, the previously described process starts again.