En ung svensk utvecklare vid namn Hampus Kraft har under fler Är Àgnat sig Ät att försöka ta fram ett alternativ till Discord, Programmet har han döpt till Fluxer. Han har ocksÄ ett bolag som heter Fluxer Platform AB sÄ i förlÀngningen Àr det förmodligen ett kommersiellt projekt.
Lösningen pÄ att en centraliserad kommersiell plattform stÀller till problem för sina anvÀndare Àr verkligen inte att skapa en ny centraliserad plattform, speciellt inte om den ocksÄ planerar att bli en kommersiell produkt.
V har redan bevisat att det gÄr att skapa distribuerade/federerade lösningar för det hÀr, som dÄ ocksÄ Àr helt sÀkra mot problemen som Discord just nu uppvisar. Det skulle vara mycket bÀttre om folk fokuserade mer pengar och utvecklartid mot sÄdana lösningar istÀllet, sÄ att vi inte blir sittande i den hÀr sitsen igen i framtiden.Detta Àr ett open source projekt som har satt federering högt pÄ listan av prioriteringar och ett av de första punkterna pÄ deras 2026 roadmap. SjÀlvhosting kommer ocksÄ stödjas (det gÄr tekniskt sett redan nu Àven om det Àr litet bökigt och dokumentering inte finns Ànnu).
Vad exakt Àr dina invÀndningar?
Mina invÀndningar Àr mer runt hur folket beter sig kring det hÀr Àn hur projektet i sig fungerar.
Men Ă€ven dĂ€r sĂ„ lutar det mot att deras âfedereringâ kommer vara en egenutvecklad lösning som Ă€r mer lik en multi-anslutande klient med delegerad auth Ă€n ett faktiskt federerande system.SĂ„ lĂ€nge jag bara behöver ett konto och upplevelsen Ă€r bekvĂ€m sĂ„ bryr jag mig inte hur det fungerar under the hood.
Bara det Àr open source och gÄr att self-hosta gratis ser jag inget problem.
Problemet med delegerad auth / relÀ - om de inte lyckas bli övertalade att faktiskt göra Àkta federering - Àr att alla sjÀlv-hostade servrar dÄ mÄste vara kraftiga nog för att kunna hantera alla andra anvÀndare pÄ alla andra servrar ocksÄ, eftersom alla anvÀndare pratar direkt mot alla servrar de interagerar med.
Hans plan Àr ju att skapa ett decentraliserat alternativ som sedan ocksÄ ska fÄ federering. SÄ jag förstÄr inte riktigt din invÀndning. Men problemet Àr vilket federerat protokoll han tÀnker anvÀnda. Det avgör ju om det blir federerat pÄ riktigt eller inte. Och hur. Matrix? XMPP? AcitivityPub?, AT?, Nostr?. Det verkar oklart.
Om man lÀser i de diskussioner som skett kring federering i projektet sÄ har det redan ratats att anvÀnda nÄgon W3C eller IETF standard för federering, sÄ ett egenutvecklat protokoll av nÄgot slag ser troligast ut, dÀr kommentarerna ocksÄ lutade hÄrt emot att federering med icke-Fluxer mjukvaror sÄgs som en bugg mer Àn en funktion.
Det lĂ€t rĂ€tt mycket som att âfedereringâ egentligen kommer betyda delegerad auth, dĂ€r din klient - kanske med hjĂ€lp av ett relĂ€ pĂ„ din instans - pratar separat mot varenda server i federeringen, istĂ€llet för att bygga en faktiskt federerad lösning.
Jag tror ocksÄ att det kan vara sÄ. Men det Àr ocksÄ ungefÀr sÄ som Nostr fungerar.
Med vissa skillnader och begrÀnsningar.
Nostr Àr byggd kring att data rekommenderas att spridas över mÄnga relÀer, vilket ökar - men ocksÄ naturligt balanserar - lasten, och eftersom varje relÀ lagrar datan sÄ kan de alla skicka ut den till klienter ocksÄ. Olika NIP:ar hanterar grupper olika i protokollet, men alla har nÄgon idé runt att mÄnga relÀer kan hantera samma grupp. Och anvÀndare kan nÄs över flera olika relÀer samtidigt ocksÄ.
Fluxers beskrivna design dĂ€remot krĂ€ver att all data för en specifik anvĂ€ndare eller rum mĂ„ste skickas till och lĂ€sas av just den noden som âĂ€gerâ anvĂ€ndaren eller rummet, vilket betyder att oavsett vilket relĂ€ du gĂ„r igenom i deras âfedereringâ sĂ„ kommer all datan i slutĂ€ndan gĂ„ mot samma nod, vilket centraliserar lasten.Edit:
För att beskriva lite djupare runt problemet;
Anta att jag har en nod som heter
'a, och det finns fem servrar/relĂ€erA,B,C,D, ochE. Anta sedan att varje relĂ€ har 50 anvĂ€ndare som Ă€r intresserade av mina meddelanden. (d.v.s. i Nostr har en subscription, och i Fluxer Ă€r med i rummet)Jag skickar nu meddelandet âHejâ med min nod.
Med Nostr sÄ gÄr det meddelandet ut till de relÀer jag pekat ut (
A-Ei det hÀr fallet), och varje relÀ tar sedan och vidarebefodrar det till de anvÀndare som Àr intresserade. Min nod -'askickar dÄ ut fem utgÄende meddelanden, och varje relÀA-Eskickar sedan ut kopior av meddelandet till sina 50 anvÀndare.
Totalt har min nod hanterat en förfrĂ„gan - skicka meddelandet âHejâ, och skickat fem utgĂ„ende meddelanden till federeringen.Om jag nu gör samma sak i Fluxer; D.v.s skriver meddelandet âHejâ i ett rum i min nod.
DĂ„ kommer det meddelandet gĂ„ till min nod -'a- som kommer skicka ut det till varje anvĂ€ndare pĂ„ varje server/relĂ€, (A-E) eftersom jag Ă€ger meddelandet. SĂ„ min nod'akommer dĂ„ behöva skicka 50 kopior till anvĂ€ndarna iA, 50 kopior till anvĂ€ndarna iB, 50 kopior till anvĂ€ndarna iC, etc⊠Totalt har min nod fortfarande bara hanterat en förfrĂ„gan - skicka meddelandet âHejâ, och sedan skickat 250 utgĂ„ende meddelanden om detta till alla intresserade anvĂ€ndare.Om en av relĂ€erna - sĂ€g
A- nu helt plötsligt förlorar lÀnkar för sina anvÀndare, pÄ ett sÄdant sÀtt sÄ att de mÄste lÀsa om datan.
För Nostr kommer det dÄ betyda attAbehöver skicka ut 50 nya meddelanden till anvÀndarna som Àr ansluta till den med den existerande kopian. Min nod'amÀrker inte detta alls.
För Fluxers beskrivna design dÀremot sÄ har inteArÀtt att lagra mitt meddelande, sÄ alla anvÀndare iAmÄste nu fÄ en ny kopia av meddelandet, vilket betyder att min nod'abehöver skicka ut de 50 kopiorna igen.Nu har jag dÄ med Nostr fortfarande bara skickat 5 utgÄende meddelanden totalt, men med Fluxer har jag behövt skicka 300, och kommer ocksÄ behöva fortsÀtta skicka fler kopior allt efter tiden gÄr.





