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.

  • Ananace@lemmy.ananace.dev
    link
    fedilink
    Svenska
    arrow-up
    3
    arrow-down
    2
    ·
    1 äžȘæœˆć‰

    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.

    • Coelacanth@feddit.nu
      link
      fedilink
      arrow-up
      5
      ·
      1 äžȘæœˆć‰

      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?

      • Ananace@lemmy.ananace.dev
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        1 äžȘæœˆć‰

        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.

        • hanke@feddit.nu
          link
          fedilink
          arrow-up
          4
          ·
          1 äžȘæœˆć‰

          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.

          • Ananace@lemmy.ananace.dev
            link
            fedilink
            arrow-up
            1
            ·
            1 äžȘæœˆć‰

            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.

    • Svenssons Nyheter@feddit.nuOP
      link
      fedilink
      arrow-up
      3
      ·
      1 äžȘæœˆć‰

      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
        ·
        1 äžȘæœˆć‰

        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 äžȘæœˆć‰

            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.