|
|
@@ -51,6 +51,6 @@ When opening the home page, the logged in user gets the latest tweets of the acc
|
|
|
|
|
|
The starting point is the home page, which is accessed by the user. Several components display the data obtained from the feed provider. 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/yapi-reference/get-statuses-home\_timeline.html}) via an HTTP GET request.
|
|
|
|
|
|
-The next step is to load the private tweets that match the 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 an 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 period is performed. The P2P DB provider queries Gun. If there are private tweets, the hashes 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, next, the private tweets are 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 an HTTP GET request, and the data is received from IPFS as the response. The author's public key, which can be obtained from the user's public key history, is needed for decryption. The public key history is loaded and decrypted via the Crypto provider, which in turn uses the Twitter API provider. Afterward, the private tweet is decrypted.
|
|
|
+The next step is to load the private tweets that match the 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 an 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 period is performed. The P2P DB provider queries Gun. If there are private tweets, the hashes 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, next, the private tweets are 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 an HTTP GET request, and the data is received from IPFS as the response. The author's public key, which can be obtained from the user's public key history, is needed for decryption. The public key history is loaded and decrypted via the crypto provider, which in turn uses the Twitter API provider. Afterward, the private tweet is decrypted.
|
|
|
|
|
|
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 \enquote{pull to refresh}, the previously described process starts again.
|
