···11+The server should a poll-inspired syncing system for Federating posts with other servers (instances). This is a [[High-level requirements#^4c6bf0|must]].
22+33+Having established this, a _how_ remains. In an earlier iteration of Lumina/Ephew (`Lumina:Peonies:itr1`), this how was conceptually answered by introducing HTTP requests fetching other instances' post IDs and then letting the client fetch the actual post content. This is a sound strategy in theory, however, you would possibly fetch posts from an instance impersonating the instance you talked to previously.
44+To keep this from happening, a choice was made to only accept domain names as instance ID's, this choice is still present in the current iteration, however, DNS is not infallible.
55+66+To solve that, some form of key checking has to be done. Either by sharing a secret token and having an instance store it, or... more sane, by `ed25519`?
77+88+Furthermore, these relatively big HTTP requests would be rate-limited on the requesting side, on the serving side, request spammers would be autoremoved from the allowlist.
99+1010+That initially created the concept of WebSocket connections, preferably ones that stay open forever (which is a long time). However, more recently, the [polyproto](https://polyproto.org) has been on my mind.
1111+1212+### Polyproto
1313+1414+I have to look into protocol-specific details later, however, each Lumina instance could also be a Polyproto 'homeserver', thereby allowing the instance to communicate to other instances using an instance user e.g., `iic@peonies.xyz`, AND as users on the instance, e.g. `user+comment@peonies.xyz`. Then federating timelines would of course go over the iic username, however things like comments or DM's, that'd require more direct federation, would be sent directly using JSON from `<username>+<reason>@<instance>` to the instance user of another instance. One of the pitfalls of the earlier conceptual implementation, was that due to the rate-limits of HTTP polling, there was at least 30 seconds of delay, this concept seems to resolve that fantastically.
+4
notes/High-level requirements.md
···11+- Must provide a timeline for 'global' and user-specific (dynamic timelines), viewable on the front end.
22+- Must be able to federate, and users be able to interact with "external" content ^4c6bf0
33+- Must have a responsive web client implementing all 'Must' end-user-features.
44+- Must have a web admin panel
-24
notes/Imported from old vault/Concepts/Backend and API's/Polling system.md
···11-The `Ephew/Peonies` polling system, or _inter-instance timelining_ might just be one of the hardest and most interesting part of the project.
22-33-> [Warning]
44-> 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.
55-66-# Walkthrough
77-This process is best explained in steps.
88-## Step 1: The polling request
99-`[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.
1010-## Step 2: Identification
1111-The `[instance B]` receives this polling request and checks if the submitted instance ID is on the sync list.
1212-1313-If not, it'll add the instance to its waiting list, meaning an administrator should decide if the instance will be allowed manually.
1414-%%
1515-Earlier, an authentication method was also added, but timelines are in fact supposed to be public, and so, this shouldn't be the default.
1616-1717-In case this'll ever become necessary or preferred again, this is a part of those 'deleted ideas'.
1818-1919- 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. %%
2020-## Step 3: Response
2121-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]`.
2222-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*?
2323-## Step 4: Organisation
2424-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.
+14
notes/README.md
···11+This is `Lumina/Peonies`'s Obsidian vault for design choices, philosophies and concepts or even psuedocode.
22+## Earlier iterations
33+44+`Lumina:Peonies:itr2` is the current and seemingly final iteration of this project, as of 2026. It uses a Rust server and Gleam/Lustre SPA as web frontend.
55+66+This project has been conceptualised and prototyped into many earlier iterations before, each with different approaches and final result. Some known older iterations had different names, listing a few:
77+88+| Codenamed | About | Introduced |
99+| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
1010+| _Peonies-Lumina_ | factually `Lumina:Peonies:itr1`, had a much bigger approach where multiple backends were explored, including ones based on the BEAM (Gleam-Erlang backend to be precise), is what itr2 draws most inspiration of.<br><br>Having multiple backends with non-matching features proved to be too complicated to maintain or draw straight. | Federation, conceptually |
1111+| _Lumina-Ephew_ | A concept-only iteration that never made it past the drawing board. | Lumina's principles and the global chronological timeline |
1212+| _Ephew_ | A near-complete PHP implementation with a plain HTML+CSS frontend (no scripts), fell apart due to the quickly aging PHP ecosystem at the time. | introducing the idea that 'multiple types of posts can feel native' |
1313+| FNew | A public text-only message pinboard | ~~Criticism, mostly~~ |
1414+The current iteration is a more well-documented and slower approach, giving time to learn and chances to refactor. It also comes in a time where the tech for it is perfect and