this post was submitted on 10 Mar 2026
7 points (100.0% liked)

IT och Teknik

275 readers
5 users here now

IT och Teknik

Ett simpelt community där man kan diskutera teknik, dela med sig av nyheter, och ställa frågor. Svenska artiklar är att föredra, men inte ett krav.

founded 2 years ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] Svensson@feddit.nu 2 points 1 month ago (1 children)

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.

[–] ace@lemmy.ananace.dev 1 points 4 weeks ago (1 children)

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.

[–] Svensson@feddit.nu 1 points 3 weeks ago (1 children)

Jag tror också att det kan vara så. Men det är också ungefär så som Nostr fungerar.

[–] ace@lemmy.ananace.dev 1 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

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äer A, B, C, D, och E. 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-E i det här fallet), och varje relä tar sedan och vidarebefodrar det till de användare som är intresserade. Min nod - 'a skickar då ut fem utgående meddelanden, och varje relä A-E skickar 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 'a kommer då behöva skicka 50 kopior till användarna i A, 50 kopior till användarna i B, 50 kopior till användarna i C, 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 att A behöver skicka ut 50 nya meddelanden till användarna som är ansluta till den med den existerande kopian. Min nod 'a märker inte detta alls.
För Fluxers beskrivna design däremot så har inte A rätt att lagra mitt meddelande, så alla användare i A måste nu få en ny kopia av meddelandet, vilket betyder att min nod 'a behö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.

[–] Svensson@feddit.nu 1 points 1 week ago

Tack för resonemanget.