this repo has no description
meta: Import from old vault
+24
+24
notes/Imported from old vault/Concepts/Backend and API's/Polling system.md
+24
notes/Imported from old vault/Concepts/Backend and API's/Polling system.md
···
1
+
The `Ephew/Peonies` polling system, or _inter-instance timelining_ might just be one of the hardest and most interesting part of the project.
2
+
3
+
> [Warning]
4
+
> This document is imported from an earlier iteration of the Lumina/Peonies project and might not be so up to date with today's preferred concepts.
5
+
6
+
# Walkthrough
7
+
This process is best explained in steps.
8
+
## Step 1: The polling request
9
+
`[instance A]` makes a HTTP GET request to `[instance B]`'s `/api/ii/poll/{id}/{size}`, where `{id}` is `[instance A]`'s ID (or host/domain name), and `{size}` is the requested amount of history. This is referred to as the polling request.
10
+
## Step 2: Identification
11
+
The `[instance B]` receives this polling request and checks if the submitted instance ID is on the sync list.
12
+
13
+
If not, it'll add the instance to its waiting list, meaning an administrator should decide if the instance will be allowed manually.
14
+
%%
15
+
Earlier, an authentication method was also added, but timelines are in fact supposed to be public, and so, this shouldn't be the default.
16
+
17
+
In case this'll ever become necessary or preferred again, this is a part of those 'deleted ideas'.
18
+
19
+
Then send a GET request to `instance A`'s `/api/ii/passcode/{id}/{passcode}`. `{id}` being `instance B`'s ID, and `{passcode}` being a one-time-passcode specific to this polling request. %%
20
+
## Step 3: Response
21
+
If listed, `[instance B]`'ll send a JSON array of post-ID's (including comments) (referred to as PID's) appearing recently on the timeline or gaining popular interactions (calculated by a threshold based on time between interactions, that'll all be in [interaction handling](Interaction%20handling.md)) and falling in the top of whatever the `{size}` is to `[instance A]`.
22
+
Identification is also used to see comments from `[instance B]` on posts on `[instance A]`, *because why transfer comment IDs of posts that don't exist on the instance*?
23
+
## Step 4: Organisation
24
+
On `[instance A]`, these PID's, prefixed with their hosting instance (`[instance B]`, in this case) are collected into a database, duplicates are eliminated in the process. The [timeline generator](Timeline%20generation.md) will use this later on to fetch posts and their comments. Comments and posts themselves are **ALWAYS** stored **ONLY** on the instance they were made on. PID's are the only things stored on other instances than their own.