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.

  • Svenssons Nyheter@feddit.nuOP
    link
    fedilink
    arrow-up
    3
    ·
    2 months ago

    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.

    • Ananace@lemmy.ananace.dev
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      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.

        • Ananace@lemmy.ananace.dev
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          1 month ago

          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.