Fluxer är inte federerat än. Varje instans, även fluxer.com, är separat, och ett konto på en instans kan inte gå med i communities på en annan. Federering är punkt 3 i vår Roadmap 2026, med ett experimentellt utkast planerat till 2026 och en stabil version under första halvåret 2027, och varje instans kommer alltid att kunna välja om den ska slå på den.
Vad är federering?
Federering låter personer på olika instanser prata med varandra, som e-post fungerar mellan olika leverantörer. Den kommer alltid att vara valfri, och alla instanser kan köras utan den.
I Fluxer handlar federering främst om identitet. Den kommer att ge dig en identitet för att logga in i communities på andra instanser och låta dig flytta ditt konto. Allt annat förblir Fluxers eget protokoll mellan din app och instansen som är värd för en community. Vår experimentella implementation har inte börjat än, så detaljer kan ändras, men vi vill hålla federeringen enkel och kommer inte att göra Fluxer till ett nytt Matrix.
Är Fluxer federerat eller decentraliserat?
Inte i dag. Fluxer är öppen källkod, så vem som helst kan driva en egen instans, men instanserna pratar inte med varandra, och ingen kod för federering har släppts. När federering kommer kan varje instans välja om den ska slå på den, och alla instanser fortsätter att fungera utan den.
Är Fluxer byggt på Matrix?
Nej. Fluxer har ett eget API och en egen gateway i realtid, och när federeringen kommer bygger vi den på polyproto-core, grundspecifikationen i polyproto, med egna tillägg.
Vad är polyproto?
polyproto är en familj av protokoll för federering som underhålls av projektet Polyphony, och polyproto-core är dess grundspecifikation. För en introduktion kan du titta på How to outlive your home server, ett föredrag på 43 minuter av Flori Ava Star på Datenspuren 2026.
I oktober 2026 var polyproto-core i version v1.0-beta.14, och specifikationen kallade sig själv en tidig beta. Den lämnar meddelandeformat och chattfunktioner till tillägg, som den kallar p2-tillägg, och det officiella chattillägget polyproto-chat är i tidig alfa. Vi kommer att skriva egna tillägg för Fluxers funktioner, och om en ändring skulle hjälpa andra implementationer av polyproto också föreslår vi att den läggs till i själva specifikationen.
Kommer ett konto att fungera på flera instanser?
Ja, det är planen. polyproto-core definierar en identitet som fungerar mellan instanser. Din hemserver är instansen där du har ditt konto, till exempel fluxer.com eller din egen, och den kommer att ge dig en identitet i formen namn@domän som du använder för att logga in i communities på andra instanser. Du kommer inte att behöva skapa ett separat konto på var och en av dem.
Varje gång du loggar in skapar din enhet ett nyckelpar för den sessionen och behåller den privata nyckeln. Din hemserver ger sedan din enhet ett certifikat för den publika nyckeln, ett så kallat ID-Cert. För att bevisa vem du är för en annan instans signerar din enhet en utmaning från den instansen, som sedan kontrollerar ditt certifikat hos din hemserver.
Kan en annan instans utge sig för att vara jag?
Nej. Din enhet signerar varje meddelande som du skickar, och andra instanser och appar kontrollerar signaturen mot ditt certifikat och din hemservers. En instans som du besöker har aldrig din privata nyckel och kan inte förfalska ett meddelande från dig. Det gäller så länge ingen har tagit sig in i din enhet och din hemserver drivs ärligt.
Varför polyproto och inte Matrix?
Det viktigaste skälet är var en community lagras. Matrix är det mest kända federerade chattprotokollet, och varje Matrix-server med en medlem i ett rum har en egen kopia av rummet, medan en community på Fluxer bara kommer att lagras på instansen som är värd för den.
Det valet gör att en instans administratör bara ansvarar för innehåll som hen har valt att ta emot, håller nere kostnaden för att driva en egen instans och gör en enda kopia av varje community lättare att få rätt. polyproto-core låter dig också flytta ditt konto till en annan instans och låter Fluxer behålla sitt eget API. Nackdelen är att en community inte går att använda medan dess instans ligger nere.
Var kommer en federerad community att lagras?
En federerad community på Fluxer kommer bara att lagras på instansen som är värd för den. Personer från andra instanser loggar in på den instansen med identiteten från sin hemserver, och deras app ansluter direkt till den, eller via deras hemserver om de föredrar det. Hur som helst lagrar eller cachar deras hemserver ingen kopia av communityn, dess meddelanden eller dess filer.
Det är vårt eget val, eftersom polyproto-core inte bestämmer var en communitys data lagras. Vi använder det så att folk kan logga in på andra ställen med sin hemidentitet, och om ett användningsfall någon gång kräver mer än så kommer vi att sätta gränser och behålla en enda kopia av varje community.
I Matrix är varje kanal ett eget rum, och rum kan grupperas i ett space. Ett rum tillhör inte en enda server, och varje server med en medlem i rummet har en egen kopia. Med tiden innehåller den kopian rummets hela aktuella tillstånd, alltså dess namn, inställningar, medlemmar och behörigheter, och varje meddelande som har skickats sedan servern gick med.
Äldre historik hämtas från andra servrar i rummet när användare skrollar bakåt. Ingen kopia är den officiella, och varje server räknar ut tillståndet från de händelser den har.
Vad händer när jag raderar ett meddelande på en annan instans?
I Fluxer är det bara instansen som är värd för en community som lagrar dess meddelanden. När du raderar ett meddelande tar den instansen bort det enligt sina regler för lagring, och ingen annan instans har en kopia som behöver rensas. För fluxer.com står det i avsnitt 7.3 i vår integritetspolicy hur länge raderade meddelanden kan finnas kvar i säkerhetskopior, och för andra instanser står det i deras integritetspolicy.
När du raderar ett meddelande i Matrix skickas en redaction till varje server i rummet. Specifikationen kräver att varje server tar bort innehållet ur sin egen kopia, men ingen annan server kan kontrollera att den har gjort det. Synapse, den mest använda Matrix-servern, behåller originalet i sju dagar som standard efter en redaction. En redaction tar inte heller bort filerna som hör till meddelandet ur mediecacharna hos andra servrar i rummet.
Att meddelanden bara finns på en instans gör också att en instans administratör bara ansvarar för innehåll som hen har valt att ta emot. Om någon lägger upp olagligt innehåll i ett rum i Matrix lagrar varje server med en medlem i rummet en kopia, och var och en av dem lagrar också äldre historik som dess användare skrollar tillbaka till och cachar media som deras appar laddar.
Måste en liten instans lagra stora communities?
Nej. En instans av Fluxer lagrar bara data för sina egna användare och de communities den är värd för. En server som går med i ett stort Matrix-rum laddar ner och lagrar hela dess tillstånd, även en medlemshändelse för alla som någonsin har bjudits in, gått med, lämnat eller blivit bannlysta.
Funktionen faster joins i Matrix låter en server börja använda rummet innan allt har kommit fram, och resten laddas ner i bakgrunden. Det är ändå en tung belastning för en liten server hemma.
Hur kommer behörigheter att fungera mellan instanser?
Instansen som är värd för en community ger varje meddelande ett id som sorteras efter när det skapades, och den kontrollerar behörigheter själv. Det är så Fluxer fungerar i dag, och det låter oss behålla det behörighetssystem som du redan använder i dina communities.
Eftersom ingen server bestämmer måste varje Matrix-server räkna ut samma tillstånd från samma händelser, även när vissa skickar motstridiga eller skadliga händelser. Matrix gör det med en algoritm för tillståndslösning, som gjordes om i rumsversion 2 och reviderades i version 12.
Ett fall som algoritmen hanterar är när en administratör tar bort en moderators behörigheter samtidigt som moderatorn, på en annan server, bannlyser en annan användare. Servrar kan få de två händelserna i olika ordning, och alla måste ändå komma överens om huruvida bannlysningen gäller.
Matrix sätter inte alla händelser i en enda ordning, eftersom varje händelse anger vilka tidigare händelser den följer, och händelser som skickas samtidigt på olika servrar har ingen bestämd ordning.
Kommer jag att kunna flytta mitt konto till en annan instans?
Ja, det är planen. Att flytta sitt konto till en annan instans är en del av polyproto-core, grundspecifikationen som Fluxers federering kommer att byggas på. Precis som i Matrix innehåller din adress din hemservers domän, och den kommer att ändras till den nya instansens domän när du flyttar. polyproto-core definierar också hur din gamla identitet lämnar över till den nya.
Medan din gamla instans är igång kommer ditt gamla konto att kunna hänvisa vidare till det nya, och du kan exportera dina uppgifter där och importera dem på den nya. Meddelanden som du har skrivit på andra instanser ligger kvar där de är, och du kan signera om dem med din nya identitet.
Varje instans behåller originalmeddelandet och lägger till en version med den nya signaturen. Det fungerar även om din gamla hemserver är borta, så länge du fortfarande har dina gamla nycklar, instansen redan känner till ditt gamla certifikat och den inte har bannlyst dig.
I Matrix innehåller ett användar-id som @namn:example.org hemserverns domän, och det skrivs in i varje händelse du skickar och i varje rums uppgifter om medlemmar och behörigheter. Du kan inte flytta till en annan hemserver med din identitet och din meddelandehistorik. Förslag som arbetar mot det är bland annat MSC2787, MSC4014, MSC4243 och MSC4348.
I oktober 2026 var alla fortfarande öppna. Vart och ett ändrar hur händelser eller rumsbehörigheter fungerar, och varje rum skulle behöva flytta till en ny rumsversion.
Kommer Fluxer att behålla sitt eget API med federering?
Ja. Fluxer har ett API, en gateway i realtid och ett behörighetssystem, och eftersom polyproto låter ett projekt definiera sina funktioner som ett p2-tillägg kan vi beskriva Fluxers API som ett sådant och låta det fortsätta fungera. När gemensamma tillägg som polyproto-chat mognar kan vi flytta delar av det till dem. Med Matrix skulle vi behöva bygga om Fluxers funktioner ovanpå rum.
Vad händer med en community när dess instans ligger nere?
Om instansen som är värd för en community går ner går communityn inte att använda förrän den är tillbaka, och communities på andra instanser fortsätter att fungera som vanligt. Ingen annan instans har en kopia av communityn. Ett Matrix-rum finns kvar så länge någon av servrarna i det är igång, och det är baksidan av att ha en enda kopia.
Administratörer för instanser bör säkerhetskopiera sina instanser regelbundet. Om administratören för instansen som är värd för en community stänger ner den finns det ingen annan instans med en kopia som kan hålla den igång.
Kommer Fluxer att federera med Matrix?
Nej. Fluxer kommer inte att federera direkt med Matrix, och en brygga kan koppla ihop de två, som bryggor redan gör för Matrix och många andra chattplattformar som Discord och Slack. Det finns ingen officiell brygga från Fluxer till Matrix eller till något annat nätverk.
När kommer federering?
Enligt färdplanen kommer ett experimentellt utkast under 2026 och en stabil version under första halvåret 2027, och vi har inga exakta datum än. Utkastet blir en pull request i Fluxers programvara med öppen källkod att prova och ge feedback på, och våra patch notes säger när det är klart. Vi diskuterar federering i Fluxer Labs, vår community på Fluxer, och du är välkommen att gå med.
Vad kan jag göra innan federering finns?
Du kan driva en egen Fluxer-instans redan i dag och bjuda in folk att skapa konton på den, och du kan när som helst exportera dina uppgifter från ditt konto.
Kan jag redan använda konton på flera instanser?
Ja, och det fungerar utan federering. Skrivbordsappen håller dina konton på fluxer.com och på egna instanser anslutna samtidigt, och när du växlar mellan dem behöver appen oftast inte ansluta på nytt. Varje konto hör fortfarande till sin egen instans, och nästa steg är att samla alla dina konton från alla instanser i en enda vy i appen.