Původní text: "Social Protocol is roll up!" Co je Farcaster? 》

Autor: ELEN

Farcaster Protocol je dalším předním produktem na SocialFi po Lens Protocol je projekt bývalých manažerů Coinbase Dana Romera a Varuna Srinivasana.

Cílem Farcaster je poskytnout důvěryhodný neutrální protokol pro ekosystém WEB3, který uživatelům umožňuje přímý kontakt se svými publiky a zároveň umožňuje vývojářům volně vytvářet nové klienty.

Viafarcaster V se usadil bůh

Dlouhodobým cílem společnosti Farcaster je stát se důležitou základní infrastrukturou na sociální síti WEB3. To je v souladu se směrem protokolu Lens Protocol. Nicméně architektonický návrh společnosti Farcaster je mnohem propracovanější než protokol Lens a snaží se tuto mezeru překlenout mezi WEB2 a WEB3 Strategie k nalezení optimálního bodu rovnováhy.

ViaBlockTurbo

Dnes se hlouběji podíváme na návrh vrstvy protokolu Farcaster a nápady na ekologické aplikace Pokud chcete studovat do hloubky, můžete se podívat na oficiální github:

https://github.com/farcasterxyz/protocol

Úvod do Farcaster

Sociální sítě byly nejrychleji rostoucím odvětvím za posledních 10 let Mnoho sociálních platforem poskytuje vývojářům rozhraní API, která vývojářům umožňují „sekundární tvorbu“ a vývoj nových ekosystémů, jako jsou různé zábavné plug-iny na Twitteru. Zdá se však, že v posledních letech není vše v pořádku, zdá se, že je stále méně věcí, které mohou vývojáři dělat, a díky různým cenzuře už vývojáři nejsou svobodní, někdy dokonce bez jakéhokoli upozornění zbaven práva na přístup.

Farcaster je zcela decentralizovaný protokol, který vývojářům usnadňuje vytváření decentralizovaných aplikací sociálních sítí. Farcasterova definice decentralizace je jednoduchá: když spolu dva uživatelé chtějí komunikovat, neexistuje způsob, jak tomu zabránit. To znamená, že uživatelé mají plnou kontrolu nad svými identitami, daty a sociálními vazbami. Vývojáři mohou prolomit omezení jakékoli třetí strany nebo dokonce sítě a vybudovat zcela decentralizovanou sociální aplikaci.

Tato vize je také to, čeho chce protokol Lens dosáhnout. Můžeme si myslet, že největší hodnotou základního protokolu SocialFi je poskytnout základní metodu technické implementace zcela decentralizované sociální sítě, takže nebude řízena žádnou třetí stranou. Podobně jako hodnota IPFS na trhu decentralizovaných úložišť.

Viafarcaster.network Farcaster Architecture

Farcaster využívá hybridní architekturu on-chain + off-chain k dokončení konstrukce decentralizovaného protokolu. Identita Farcaster je uložena v řetězci Ethereum a využívá Ethereum k zajištění jeho bezpečnosti, složitelnosti a konzistence. Identity jsou řízeny prostřednictvím Ethereum adres a off-chain zprávy jsou podepisovány přes Ethereum účty.

Data uživatele jsou zašifrována a podepsána prostřednictvím identity a uložena na serverech kontrolovaných uživatelem (Farcaster Hubs). Důvodem, proč nejsou data uložena v řetězci, je příliš vysoká cena vypořádání ve většině sítí L1 a L2 a rychlost. je příliš pomalý.

Tato architektura se liší od návrhu protokolu Farcaster, který více zohledňuje skutečné potřeby vývojářů a je více podobný projevu sociálních médií WEB2, čímž se snižují náklady na učení uživatelů, ale stále je decentralizovaný , data a sociální vztahy jsou založeny na blockchainu.

Účet

Účty Farcaster jsou podobné účtům na pseudonymních sociálních sítích, jako je Twitter nebo Reddit, a jednotlivci mohou provozovat několik účtů současně. Každý účet má přiřazeno jedinečné číslo, které se nazývá Farcaster ID nebo Fid. Farcaster ID lze získat z adresy Ethereum zavoláním do registru Farcaster ID (FIR). Tato adresa se nazývá escrow adresa a může jménem účtu podepisovat informace mimo řetězec a v řetězci. Uživatelé se mohou rozhodnout získat jméno nebo přezdívku Farcaster z registru jmen Farcaster (FNR), který jim vydá jedinečné jméno, například @alice.

Lze pochopit, že Fid je identita na řetězci, zatímco FNR je společensky čitelná identita. Pokud je Fid adresa peněženky, pak FNR je ENS.

Informace o podpisu

Podpisová informace je objekt odolný proti neoprávněné manipulaci a vlastní certifikaci podepsaný společností fid. Podpisové informace představují akce uživatele, jako je zveřejňování příspěvků, sociální zpětná vazba (komentáře/retweeting) nebo úprava informací o účtu, jako je uživatelské jméno.

Podepsané zprávy mají atributy zpráv, které obsahují určité užitečné zatížení. Užitná zátěž je serializována, hashována a podepsána platným párem klíčů (např. costody adresa). Obálka obsahuje hodnotu hash, podpis a veřejný klíč dvojice podpisových klíčů, které může jakýkoli příjemce použít k ověření podpisu fid.

Zprávy musí být serializovány pomocí RFC-8785, hashovány pomocí BLAKE2b a podepsány pomocí podpisového schématu Ed25519. Každá zpráva musí také obsahovat FID pro dotaz na escrow adresu v řetězci a časové razítko pro třídění.

aplikace

Aplikace jsou programy, které lidé používají k interakci se sítí Farcaster. Jednoduchá aplikace se může skládat ze samostatného desktopového nebo mobilního klienta, který komunikuje přímo s Farcaster Hub. Může publikovat nové zprávy a prohlížet zprávy publikované jinými FID. Takové aplikace jsou hostovány samostatně a musí být vytvořeny s hostitelskou adresou nebo platným podpisovým klíčem.

Složitější aplikace mohou přidat server proxy backend k indexování dat centra. Indexování umožňuje serveru implementovat funkce, jako je vyhledávání, podávání algoritmů a detekce spamu, jejichž provádění na Hubu je obtížné nebo nákladné. Taková aplikace může být umístěna samostatně pomocí uložení klíčů na klientovi;

Náboje

Hub je vždy dostupný server, který ověřuje, ukládá a replikuje informace o podpisech. Uživatel vybere Hub a publikuje jeho URL v řetězci pomocí FIR. Jejich sledující mohou tuto adresu URL použít k vyhledání a stažení svých zpráv. Zároveň mohou uživatelé Hub provozovat i sami nebo využívat hostingové služby třetích stran.

Farcasterova identita

Farcasterův systém identity umožňuje, aby identita uživatele měla následující vlastnosti:

Bezpečné a plně decentralizované Snadno identifikovatelné na sociálních sítích Snadné nastavení (rychlé a levné) Obnovitelné (neporušuje podstatu decentralizace)

Tyto funkce je obtížné implementovat do systému identit, protože jsou často v konfliktu. Je například obtížné mít decentralizovaný, důvěryhodný systém jmen (např. zda zaručit jedinečnost systému jmen).

Farcaster vyvažuje tyto vlastnosti prostřednictvím dvou nezávislých systémů. Farcaster ID Registry (FIR) vydává nová ID čísla, nazývaná fids, Farcaster Name Registry (FNR) vydává nová uživatelská jména, nazývaná fnames. Fids jsou bezpečné, decentralizované identifikátory, které jsou přítomné v každé zprávě a jsou koncepčně podobné uuid.

Fnames jsou hlavně pro modifikaci FIR, nahrazují fid při vykreslování a lze je kdykoli změnit. Rozdělení identity do těchto dvou složek nám umožňuje dosáhnout našich cílů, ale za cenu přidání určité složitosti systému. Oba systémy také implementují mechanismus obnovy, který chrání před ztrátou párů klíčů, které řídí názvy, aniž by to ovlivnilo decentralizaci.

Farcaster ID Registr (FIR)

Farcaster ID jsou číselné identifikátory, podobné jako uuid. Když se zobrazí uživateli, bude jim předcházet vykřičník (například: !8098).

FID představuje jedinečnou entitu, jako je osoba nebo organizace. Každý odkaz na tuto entitu musí používat její fid, nikoli její fname. Registrační poplatek pro FID je velmi nízký a je vlastněn doživotně. Smlouvy FID nelze žádným způsobem upgradovat ani upravovat.

FID začíná na 0 a zvýší se o 1 pokaždé, když dojde k nové registraci. FID je uložen v řetězci jako uint256, což zaručuje téměř nekonečnou zásobu, protože může být zvýšena na ~10^77.

Uživatelé mohou pomocí FIR konfigurovat adresy URL, aby našli umístění jejich informací mimo řetězec.

Registr jmen Farcaster (FNR)

Jména Farcaster jsou jedinečná, podobně jako uživatelská jména v jiných sítích. Když se zobrazí uživateli, bude jim předcházet symbol @ (například: @alice).

Fname spolu s tokeny profilu, jména a ověření pomáhá vizuálně identifikovat entitu při procházení webu. Na rozdíl od fids je fname primárně čitelný a nemá nic společného se základními daty vytvořenými uživatelem. Vlastnictví fname není trvalé a uživatelé musí platit nějaké roční poplatky. Obnovení fname lze provést 90 dní před vypršením platnosti fname. Jména s prošlou platností budou dražena v holandské aukci, přičemž dražitelé budou muset zaplatit roční poplatek a prémii začínající na 1 000 ETH. Prémie se snižuje o 10 % každých 8 hodin, dokud nedosáhne 0 ETH.

Fnames jsou NFT vydávané jmenným registrem Farcaster na principu „kdo dřív přijde, je dřív na řadě“. Každý název musí odpovídat regulárnímu výrazu /^[a-z0-9][a-z0-9-]{0,15}$/. Mají specifické vlastnosti, díky kterým jsou užitečnější v sociálních sítích ve srovnání s jinými jmennými prostory, jako je ENS. Je levnější je razit a vlastnit, jsou méně náchylné k homofonním útokům kvůli omezením znakové sady a jsou také obnovitelné. Farcaster nevyžaduje použití fname, uživatelé mohou volně používat jiné jmenné prostory a jejich fid.

Vzdání se používání fname nebude mít velký dopad, protože Farcaster je navržen na základě fid a každá informace a chování ukazuje spíše na fid než na frame. fnames lze kdykoli změnit, aniž by došlo ke ztrátě jakýchkoli předchozích informací o závislosti.

Zásady uživatelského jména

Během období beta lze uživatelská jména zaregistrovat zdarma a podléhají jednoduchým zásadám. Účelem těchto zásad je zabránit tomu, aby si jména přebírali neaktivní uživatelé nebo je zneužívali k vydávání se za jiné. Řešení tohoto problému není snadno automatizované a vyžaduje lidský úsudek. Zásady uživatelských jmen mají dva základní principy:

Vydávání se za jinou osobu – Pokud se zaregistrujete pod uživatelským jménem, ​​které patří známé veřejné osobě nebo subjektu, vaše jméno může být zrušeno. Například @elonmusk, @vitalikbuterin, @google nebo @whitehouse. Neaktivita – Pokud jste aktivně nepoužívali uživatelské jméno po dobu delší než 60 dní, může být vaše jméno na žádost jiného uživatele nebo dle našeho uvážení odregistrováno.

Předpokládáme, že bude často vyžadován manuální zásah, protože může docházet k legitimním konfliktům. Například jste zaregistrovali @vitalik a Vitalik Buterin se zaregistroval po vás a chtěl toto jméno. V tomto případě si položíme tři otázky, které nám pomohou při rozhodování:

Je tento uživatel aktivní a zapojený do služby Farcaster? (Například pokud v posledních několika měsících publikovali vysoce kvalitní příspěvky.) Má tento uživatel oprávněný nárok na jméno? (Pokud se například jmenuje také Vitalik) Má tento uživatel podobné aktivní účty v jiných sítích? (Například pokud mají na twitteru vitalik a vitalik.ens).

Pokud jsou odpovědi na tyto otázky většinou ano, zachovají si nárok na své jméno. V testovací síti bude hlavní tým rozhodovat o tomto konfliktu a doufáme, že formálně zavedeme systém řízení kolem tohoto problému, jakmile se přiblížíme k mainnetu. Pokud je jméno staženo v důsledku arbitráže, nebudou uživatelům vráceny peníze.

Obnovení účtu

Pokud uživatel ztratí klíč k adrese obsahující ID a jméno, lze Farcaster ID a jméno obnovit. Obě smlouvy implementují systém zpožděného obnovení, který umožňuje přenést požadavky na adresu pro obnovení na novou adresu. Pokud adresa pro úschovu nezruší převod do tří dnů, adresa pro obnovení může převod dokončit.

Uživatelé mohou nastavit adresu pro obnovení na jinou adresu ve své vlastní peněžence, multisig sdílené s přáteli nebo službu obnovení třetí strany. Uživatelé mohou také adresu pro obnovení kdykoli změnit. Vlastnictví zůstává decentralizované, protože adresa pro obnovení nemůže provádět převody, se kterými adresa úschovy nesouhlasí.

Převedením aktiv na novou adresu pro úschovu u třetí osoby se zruší nastavení adresy pro obnovení. V opačném případě by si uživatel mohl zakoupit jméno na OpenSea, jen aby si jej předchozí vlastník nárokoval zpět tajně pomocí své obnovovací adresy.

zpracování informací

Zpracování informací je proces, kterým Hub přijímá nové zprávy a určuje stav uživatele. Uživatelé posílají zprávy do centra pro každou svou akci. Pokud se uživateli URL líbí, nelíbí se mu a líbí se mu, vygenerují se tři zprávy. Hub, který přijímá všechny informace, určí aktuální stav oblíbených adres URL uživatele.

Hub může zahodit první dvě informace, aby ušetřil místo. Hub může takové zprávy komprimovat pomocí operace sloučení, která zabrání nekonzistentnosti na straně klienta a šetří místo. Zprávy mohou mít různá pravidla pro operace sloučení. Například dvě lajky od uživatele stejnému uživateli lze zkomprimovat do jednoho, ale dvě odpovědi nikoli.

Hub může ztratit některé informace o uživateli a skončit v chybovém stavu. Může například obdržet pouze první zprávu Líbí se a Nelíbí se, která nastaví aktuální stav na Nelíbí se mi. Operace sloučení by měla státu umožnit posun vpřed a dosáhnout konzistence, protože chybějící zprávy jsou znovu vysílány. Jinými slovy, sloučení by mělo nakonec zajistit silnou konzistenci.

Hub toho dosahuje implementací sady CRDT pro každý typ zprávy, kódováním specifických pravidel ověřování a slučování. Díky této funkci jsou Hubs vysoce dostupné, protože je lze kdykoli přepnout do režimu offline a lze je vždy obnovit, aby se synchronizovaly. Formálně je naše sada CRDT anonymní delta-stav CRDT2 a každá zpráva je připojenou a neredukovatelnou aktualizací sady.

Třídění informací

Kolekce informací může třídit informace o podpisu podle časového razítka a řešit konflikty sloučení pomocí naposledy zapsané zásady. Nemohou však zaručit dokonalé uspořádání, protože časová razítka jsou náchylná ke zkreslení hodin, posunu hodin, falšování ze strany uživatelů se zlými úmysly a mohou kolidovat z mnoha důvodů. Aplikace mohou používat smíšené hodiny k výrobě dokonale uspořádaných časových razítek bez kolizí, ale nemůžeme je vynutit.

Namísto toho definujeme objednávkový systém pro zprávy, který zajišťuje celkové řazení pomocí časových razítek k určení počátečního řazení a hashů k odstranění kolizí. Celková objednávka je zaručena, protože dvě zprávy nemohou mít stejnou hodnotu hash, pokud se nejedná o stejnou zprávu. Pomocí tohoto algoritmu lze porovnat dvě zprávy a a b:

Pokud a.timestamp>b.timestamp, pak a je větší. Jestliže a.timestamp < b.timestamp, pak b je větší. jestliže a.časové razítko == b.časové razítko

- Pokud a.hash>b.hash, pak a je větší.

- Pokud a.hash < b.hash, pak b je větší.

- Pokud a.hash = b.hash, a == b

Časová razítka se porovnávají jako čísla, zatímco hash se porovnávají jako řetězce. Protože se porovnání řetězců mezi implementacemi liší, musíme být v našich porovnávacích algoritmech přesní. Věříme, že dvě hodnoty hash x a y lze porovnat porovnáním každé dvojice znaků:

Pokud jsou všechny dvojice znaků stejné a x a y oba končí, pak x == y Pokud jsou všechny dvojice znaků stejné a x končí jako první, pak y>x Pokud je nalezen jiný pár znaků xC, yC, pak If ASCII( yC)>ASCII(xC), poté y>x

Ověření informací

Kromě ověření specifických pro typ zprávy musí všechny zprávy projít následujícími ověřeními:

message.timestamp není o více než 1 hodinu před systémovým časem. message.fid musí být ve FIR známé číslo fid. signerPubKey by měl být platným spravovaným podepisujícím nebo delegovaným podpisem pro message.fid hashFn(serializeFn(zpráva)) se musí shodovat s obálkou.hash, kde hashFn je funkce Blake2B a serializeFn provádí normalizaci JSON. EdDSA_signature_verify(obálka.hash, obálka.podpisPubKey, obálka.podpis) by mělo projít.

Obsazení

Cast je veřejná informace vytvořená uživateli, která obsahuje text a může být také vložena do médií, aktivit v řetězci nebo jiných Cast. Přenosy se ukládají do dvoufázové kolekce CRDT3, aby se vyřešily konflikty mezi zprávami.

Cast lze přidat prostřednictvím zprávy CastAdd, která je umístěna v sadě doplňků CRDT. Každý Cast je indexován svou hash hodnotou, u které je zaručeno, že je jedinečná, pokud Casty nejsou identické. Kromě toho dvě přidávané zprávy nikdy nebudou v konfliktu, pokud nejsou totožné, v takovém případě lze jednu bezpečně zahodit.

Casty lze odstranit pomocí zprávy CastRemove, která obsahuje odkaz na hash cílového CastAdd. Když je tato zpráva přijata, cíl je odstraněn z add-setu, pokud existuje, a odstraněný je přidán do rem-setu. Konflikty mezi přidáním a odstraněním jsou řešeny pravidlem Remove-Wins, zatímco konflikty mezi mazáním jsou řešeny pravidlem Last-Write-Wins, které se v případě nerozhodného výsledku vrací k lexikografickému uspořádání.

Přidejte informace

Cast Add může obsahovat text Unicode o délce až 320 znaků a dva identifikátory URI o délce až 256 znaků. Klient je zodpovědný za společné dekódování a vykreslování URI a textu.

Obsazení bez rodiče je obsazení nejvyšší úrovně a klient by se měl objevit v profilu uživatele nebo na časové ose. Rodičovský přetyp je odpovědí na jiné přetypování, webovou adresu URL nebo objekt v řetězci a měl by být zobrazen ve vláknu.

Dotazy tvoří řadu stromů, kde každý kořen je dotaz nebo URI a každý podřízený uzel je dotaz odpovědi. Každý strom lze vykreslit jako konverzaci s vlákny. Strom je zaručeně neperiodický, protože nadřazený uzel musí být hašován a podepsán, než na něj může podřízený uzel ukazovat. Jakékoli změny v datech nadřazeného uzlu zničí všechny vztahy s jeho podřízenými uzly.

Informace o castech musí projít následujícími ověřovacími kroky.

Text musí obsahovat <=320 platných znaků Unicode vložit musí obsahovat 0 až 2 položky položky musí být URI o délce až 256 znaků Pokud je přítomen rodič, musí být platný URI, který se nerovná URI této zprávy (např. fid:/cast:).

Smazat informace

Cast Remove jednoduše obsahuje odkaz na hash Cast Add. Umožňuje trvalé smazání Cast a zároveň smazání dat původní Cast.

Zpráva musí projít následujícími kroky ověření:

message.data.body.hash se nesmí rovnat message.envelope.hash. message.timestamp musí být <= systémové hodiny + 10 minut message.data.fid musí být ve FIR známé jako fid

sloučit pravidla

Když je přijata dodatečná zpráva a, pokud r existuje v sadě rem a r.data.body.hash se rovná a.hash, pak je a zahozeno. V opačném případě přidejte a do sady sčítání. Když je přijata zpráva o odstranění r, pokud je v přidané sadě a.hash rovný r.data.body.hash, odstraňte ji. Pokud je v sadě rem r', kde r.data.body.hash se rovná r'.data.body.hash, pokud r'>r, zahoďte r', pokud r';

Akce

Akce je veřejná operace prováděná uživatelem na cíli, kterým může být jiný uživatel nebo aktivita v řetězci. V současné době jsou podporovány dva typy akcí: lajkovat a sledovat. Protokol lze snadno rozšířit o podporu nových akcí. Uživatelé mohou akce vrátit a znovu provést přepnutím atributu aktivity ve zprávě. Koncepčně je každá akce hranou v sociálním grafu.

Akce je řízena pomocí LWW-Element-Set CRDT, která zaručuje případnou konzistenci. Koncepčně existuje jediná kolekce, která ukládá všechny zprávy, a konflikty jsou řešeny pomocí časových razítek a lexikografického pořadí hash. Přidání se provádí vytvořením akční zprávy a s aktivní nastavenou na true, zatímco mazání se provádí nastavením active na false. V obou případech je logika pro slučování zpráv do sad následující:

Pokud je v kolekci akce x, její typ, cílové hodnoty Uri a fid jsou stejné jako u příchozí akce y. Jestliže x>y, zahoďte y, jestliže x

ověřit

Ověření je obousměrný doklad o vlastnictví mezi účtem Farcaster a externím subjektem. Ověření lze použít k prokázání vlastnictví adres Ethereum, konkrétních NFT, jiných účtů sociálních médií a dokonce i názvů domén.

Při ověřování existují tři základní koncepty:

Výpisy, včetně odkazů na účty Farcaster a externí subjekty. Nároky lze hašovat a vytvořit tak pro každý nárok jedinečný identifikátor. Důkaz o směrovosti od externího subjektu, který je oprávněn podat žádost, která ukazuje její záměr připojit se k účtu Farcaster. Důkaz směrovosti z účtu Farcaster pro přijímání žádostí o spojení nároku s účtem Farcaster.

Autorizace signatáře

Autorizace podepisujícího je zpráva autorizující nový pár klíčů ke generování podpisů pro účet Farcaster.

Když je ražen fid, může jeho jménem podepisovat zprávy pouze adresa správce. Uživatelé možná nebudou chtít načíst tento pár klíčů do každého zařízení, protože to zvyšuje riziko kompromitace účtu. Správcovská adresa, známá také jako podepisující správce, může autorizovat páry klíčů jiných známých jako delegovaní podepisující. Na rozdíl od regulačních signatářů mohou delegovaní signatáři publikovat pouze informace mimo řetězec a nemohou provádět žádné operace v řetězci.

Escrow signatáři generují ECDSA signatury na křivce secp256k1 a mohou publikovat pouze informace o autorizaci signatáře. Všechny ostatní typy zpráv musí být podepsány delegovaným podepisujícím, který vytvoří podpis EdDSA na curve255194. Delegované podepisující osoby lze použít k autorizaci nových zařízení nebo dokonce služeb třetích stran k podepisování zpráv pro účet. Pokud dojde ke kompromitaci delegovaného podepisujícího, může jej odvolat on sám, jeho předci v řetězci důvěry nebo jakýkoli delegovaný podepisující. Když je podepisující osoba odvolána, Hubs zahodí všechny své podpisové informace, protože neexistuje způsob, jak odlišit informace uživatele od informací útočníka.

Uživatelé mohou také převést ID na novou escrow adresu z důvodu obnovení klíče nebo změny peněženky. Často je žádoucí zachovat historii, aby se obě adresy u třetí osoby staly platnými podepisujícími u třetí osoby. Sada platných signatářů pro ID tvoří řadu různých stromů. Kořenem každého stromu je historická adresa správy a listy jsou delegovaní signatáři.

Sada signatářů je upravená dvoufázová sada se sémantikou delete-win a last-write-win. Nové informace jsou do sbírky přidány, pokud jsou podepsány platným zmocnitelem nebo opatrovníkem. Odstranění jsou přijímána, pokud je podepíšete vy nebo váš předek. Jakmile je podepisovatel odebrán, nelze jej přidat a všichni jeho potomci a zprávy budou zahozeny.

Pokud dva platní podepisující autorizují stejného delegovaného podepisujícího, dojde ke konfliktu sady, který zničí stromovou datovou strukturu. Pokud k tomu dojde, kolekce bude udržovat zprávu s nejvyšším časovým razítkem a lexikografickým hashem v pořádku.

Sharding

Huby mohou kopírovat pouze data pro konkrétní účty, což je užitečná vlastnost pro škálování sítí. Pokud se Farcaster rozroste natolik, že jediný server nemůže podporovat replikaci celé sítě hubů, pracovní zátěž se může rozložit na více hubů. Provozovatelé hub se také mohou vyhnout synchronizaci dat pro uživatele, kteří se chovají škodolibě nebo nejsou spojeni s operátorem.

Selektivní replikace poskytuje pouze částečný pohled na síť. Pokud Hub synchronizuje Alicina data, bude vědět, že odpověděla na jeden z Bobových příspěvků a že se mu líbí. Nezná však obsah Bobova příspěvku ani skutečnost, že se Bobovi její odpověď líbila a poté v odpovědi pokračoval. Aplikace, jejímž cílem je poskytovat přesný počet lajků a poskytovat všechny informace o odpovědích, by měla replikovat co nejvíce uživatelů.