artlu99/foss-farchiver-xyz

FOSS services at farchiver.xyz

FOSS services at farchiver.xyz

Lightweight services to benefit the ecosystem. Designed to work permissionlessly and decentralized, with maintenance-light responsibilities.

Permission granted to clone, fork or copy, as per MIT license.

Backend on Cloudflare Workers + KV. Frontend based on borodut.ch frontend starter template.

Host-side setup

1. deploy Cloudflare Pages by pointing to this Git repository
2. create CNAME DNS record pointing (sub-)domain to the deployment
3. bind KV namespace to variable KV in this Pages deployment
4. call the hubs/reset endpoint to pre-populate KV
5. update KV store from existing instances, e.g., foss.farchiver.xyz

Local launch

1. Install dependencies with yarn
2. Run the server with yarn start

foss-farchiver-xyz's Issues

add sorting to HubsViewer

Issue: would be useful to order the Hubs list by relevance

Diagnosis: displayed order can be random due to async-await

Solution: choose sort method (e.g., most messages, version, most Fid Events processed, response time(?!) ) and sort client-side

version 1.10.0 should be greater (more up to date) than 1.9.9

Issue: the latestVersion endpoint returns 1.9.9 when some Hubs have updated to 1.10.0

Diagnosis: the sort happens alphabetically, not semantically

Solution: sort properly -- possibly split on . separators, then do sub-sorts

initial HubsViewer loading is slow

Issue: HubsViewer load feels slow

Diagnosis: the client-side loop has to await all the hubs in the list. If any Hub in the list is unresponsive, it delays the display of the entire list.

Solution 1: progressive display

Solution 2: store the results in localStorage and refresh

Solution 3: refresh button for each Hub / all Hubs

Hub operater fid may change at any time, permissionlessly

Issue: hub operator fid is currently hard-coded as a semi-static value

Diagnosis: an operator may change the Fid, for benign or malicious purposes. The dashboard should update in real-time

Solution: pass through the Fid returned by the Hub's info endpoint

add meta-data indicators for each Hub

Issue: users should be able to see which Hubs are open for writes (as opposed to read-only), and operators should have an optional way to be reached about their Hub

Diagnosis: the Hubs themselves are relatively anonymous. This is good.

Solution: add (and maintain) meta-data about the list

script to update Hubs list in KV store

Issue: KV data store is maintained manually

Diagnosis: was fine initially, when the Hub network was more static. In times when it is dynamic (e.g., lots of staged version updates), this gets more usage and requires more manual monitoring.

The KV cannot be updated in serverless functions, because the ports are blocked due to being non-standard

Solution: a script to be run locally and scheduled, permissioned to update the KV data store