25.02.2024-5:05:45 :: Remember, remember, the velvet November


node:	25.02.2024-5:05:45
template:	4
parent:	personal cloud services
owner:	rzelnik
viewed by:
created:	25.02.2024 - 05:05:45

cwbe coordinatez:
101
63540
2111157
7930434
9130262

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

localfirstweb.dev - všetko o local-first web development - textové podklady a dokumentácia, videá - prednášky a prezentácie, vývojárske nástroje, ľudia hodní sledovania, online komunity, demo aplikácie

000001010006354002111157079304340913026209130415

Robil som male experimenty. Hlavne co sa tyka slobody pouzivat vlastne backendy/sync nody - zostalo mrzenie. Mal som za ciel najst skutocne pseudoanonymne p2p (idealne tazko cenzurovatelne).

Rozbehal som Yjs cez matrix adapter a bol to teda porod. Matrix Synapse som rozbil minimalne 4 krat nez sa mi to podarilo rozbehnut, nastavit a nerozbit obskurny yaml config. Nehovoriac o tom ze autor (Yusef) co napisal yjs-matrix integraciu (famozny typek!) tak uz na tom nepracuje takze yjs nepodporuje verziu matrixu s e2ee. Zkusal som to prepisovat ale cely ten stack daval zabrat a dobre som si narazil drzku. Tool na moderaciu (Mjolnir) je story sama o sebe. (na margo matrix ux hell -> https://blog.koehntopp.info/2024/02/13/the-matrix-trashfire.html)

Potom som hladal alternativy k p2p signalingu -> projekty ako coturn (ktore vo vysledku je potreba na produkcne prostredie) vyzeraju ako master blaster overkill. Maju 300 open issues a na ich kontrolu bude potreba Swarm alebo Kubernet (a tie dalsie veci k tomu...)

Dalsia nadej mi svitala ked som videl DHT/Kademlia implementacie v kombinacii s holepunchingom - typci z https://keet.io co robili hyper/swarm to maju odmakane. Ked som si ale cital viac o tej holepunch technike doslo mi ze aj tak je potreba pevne body v infra cez ktore sa tie nody na seba uvidia. Takze anonymita, resp necenzurovatelnost v tomto zmysle tiez nehrozi.

Vlastne mi z toho vzislo ze najlepsie je pouzit websockets alebo napisat si zase vlastny backend. Tak ci tak budes muset niekde bezat a manazovat tu infra. "Skutocne p2p" bez par bodov kde to bude cele zranitelne sa uplne neda zrealizovat.

eot

e: sorry za typos

00000101000635400211115707930434091302620913041509131140

Toto som si všimol aj ja, že vlastne všetky fancy P2P technológie majú niekde nejaký server/relay na pozadí. V local-first dokumentoch sa dokonca priamo zdôrazňuje, že im primárne nejde o P2P a že prepájací server pre nich nie je problém. Nebude to tým, že súčasný internet vlastne nie je na P2P stavaný?
Takže vlastne rozdiel medzi local-first a client/server architektúrou je hlavne v tom, že pri local-first sú tie dáta primárne uložené u koncového používateľa a nemusia sa spoliehať na server, odkiaľ sa tie dáta stiahnu. No a P2P zabezpečuje iba to, že tie dáta nemusia byť uložené na jednom konkrétnom mieste, ale môžu sa replikovať na viacerých miestach, aby niektoré uzly občas mohli byť vypnuté / mať výpadok. Toto je asi podstatné si uvedomiť, že to nie je tak, ako sa to kreslí v tých ilustračných grafoch, kde peers komunikujú medzi sebou napriamo - to je iba idealizovaná predstava.