• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    TOMMastodon 🐘 / Fediverse - decentralizovaná sociální síť
    XCHAOS
    XCHAOS --- ---
    The content is already here: @yurnidiot@mstdn.social
    XCHAOS
    XCHAOS --- ---
    ALMAD:
    ALMAD: ten článek je skvělý:

    The reality that fans of decentralized, independent social media must confront is that we are a tiny audicence right now. Whichever site we are looking at, we are talking about a few million monthly active users at best, in a world where even the pathetic husk of Twitter still has hundreds of millions and Facebook has billions. Interneceine fights are not going to get us anywhere. We need to build bridges and links and connect our networks as densely as possible.
    XCHAOS
    XCHAOS --- ---
    JARDABEREZA: myslím, že design flaw proof-of-work byl jasný velmi brzy (se samotným blockchainem je to složitější, ale spamování celého světa záložními kopiemi úplného celku není to samé, jako decentralizace, kryptoměny jsou v podstatě pokus implementovat Roccova Baziliška, i když v té době si to uvědomoval málokdo, protože ten pojem nebyl všeobecně známý, zatímco decentralizované cacheování vybraných příspěvků, navzdory poměrně zjevným vadám, skutečná decentralizace je. Dokonce blockchain šel hodně intenzivně proti jedné ze základních tezí volného trhu, tedy "všichni nemáme stejné informace", když šlo o pokus, aby všichni měli stejné informace (ovšem samozřejmě šlo jen o tu "šachovnici" a ne o záměry, které s ní kdo má...). Každopádně kryptoměny jako takové byly zajímavý pokus, ve své době, a vlastně dosáhly úspěchu v tom smyslu, že banky začaly online platby brát velice vážně: bylo jasné, že když je budou saobotovat, lidi si najdou náhradu. Co se týče konspirace okolo "centrálních bank", ta je spíš nesouvisející... lidi, kteří měli moc peněz na hraní, jsou spíš ti, kteří kryptoscénu zničili a udělali z ní gambling...

    Spíš jsou varovným příběhem ostatní ranné, před-webové protokoly: E-mail samotný přežil, ale za cenu, že je dnes k nerozeznání od původního ultra-liberálního konceptu. Provoz mailserverů vyžadoval masivní modifikace DNS systému, aby se někde zakotvila informace kdo vůbec čím jménem má právo e-maily rozesílat. Boj se spammery není vůbec u konce a vede nakonec k masivní institucionalizaci všeho. Provoz mailových účtů pro veřejnost se centralizoval u několika ultra-velkých hráčů a každý nově příchozí hrozí obrovskému podezření, že je spammer a čelí obrovské presumpci viny, než se do systému může zapojit.

    Usenet víceméně tiše přestal existovat. Desítky let jsem se nepodíval na žádnou webovou bránu do Usenetu. Formát, postavený na čiré replikaci bez jakéhokoliv ratingu a možná nahodilé moderaci, se ukázal jako nevhodný, problémem byl i poměrně velký overhead a nevhodnost pro šíření mediálního obsahu (ke kterému začal být zneužíván poměrně brzo, v podstatě dřív, než se objevilo HTML a WWW stránky). Nicméně Fediverse oživuje koncept Usenetu v tom bodě, že se člověk připojí k serveru, který je vstupním bodem (konkrétně ke své instanci) a interaguje s decentralizovaným systémem přes ní. Je to vlastně Usenet s modernějšími datovými formáty a uživatelskou interakcí.

    No a pak je tady IRC. IRC bylo předobrazem poměrně rychlé, realitime, chat-like komunikace na webových diskuzních klubech a sociálních sítích, ale tvrdohlavé trvání na tom, že identity nebudou perzistentní, vedlo k asi největší excentricitě celého protokolu oproti hlavnímu proudu a taky ho používal úplně jiný typ lidí. Pozůstatkem syntaxe kanálů jsou hashtagy, které na Twitter nejspíš vnesli lidé, co měli zkušenost s IRC.

    K pochopení Fediverse tedy zkušenost s kryptoměnami pomůže jen málo: blockchain je masivně replikovaný, nikoliv decentralizovaně uložený objekt. Naopak lze vysledovat kořeny ActivityPub hluboko v před-webovém Internetu, tedy u SMTP (a opačným směrem POP3/IMAP), u NNTP a u IRC. Jako na autoritu pak Fedi spoléhá na DNS systém, což je zase další odlišnost oproti kryptu. Vnější podobnost s centralizovanými chaty je sice cílem celého snažení... ale právě, že se to zatím úplně nedaří.

    Co se distribuce autority týče, tak jde o hodně konvenční málo strmou hierarchii, ne o hru na úplnou rovnoprávnost: všechna moc patří adminům instancí, na kterých jsou uloženy např. privátní klíče uživatelů, umožňující podepisování obsahu replikujícího se ve Fediverse (Správný paranoik musí provozovat vlastní instanci a je celkem jedno, jestli ji otevře jiným uživatelům nebo ne: rozhodující je, koho pustí k administraci systému, takže mít one man show, kde instanci administruje někdo jiný, vlastně smysl nedává a není divu, že po tom není moc poptávka...). No a nad kastou sysadminů už stojí jen provozovatelé DNS systému, pro který je pluralita Fedi daleko větší kšeft, než velké komerční aplikace, které se notabene snaží přetáhnout lidi z otevřeného Internetu do prostředí mobilních aplikací, kde potenciálně mají šanci fungovat v prostředí appstorů třeba i bez velké vazby na DNS a další internetové tradice...

    Fediverse je příležitostí, ale i výzvou pro kryptoměny: kde je identita a komunikační kanál, tam je možná i platba. Úplná replikace účetních knih možná vůbec není podmínkou (kdo ví?). Tradiční krypto vedle Fedi najednou vypadá jako Svědkové Jehovovi vedle co já vím - počátkům olympijského hnutí (nerad bych zabředal k dnešní podobě komercionalizovaného sportu...). Najednou vůbec nepotřebujete nějaké divně formátované adresy, identita je čitelná, apod. (Akorát nesmí vaše paranoia zacházet tak daleko, že nevěříte ani na DNS... akorát, že Fediverse lze pochopitelně rozšířit i na privátní domény stojící mimo uznané TLD a pořád bude fungovat a dokonce půjde z privátních domén followovat účty na doménách veřejných, ale ne vice versa...)
    JARDABEREZA
    JARDABEREZA --- ---
    ALMAD: Ta rétorika mi něco připomíná. Vyměň Fedi za Bitcoin a AI za Centrální banky... :-D Překvapilo by mě, kdyby se idelistická vize tvůrců splnila přesně tak, jak si jí představují. Lidi umí být kreativní.
    ALMAD
    ALMAD --- ---
    XCHAOS: Distribuované vyhledávání ve federovaných timelines má potenciál skutečně časem ohrozit monopol Googlu...a ohrozit dominanci AI. Ve hře je hodně. Fedi může být jediný nástroj, který máme v rukou jako protiváhu vůči domanci AI. Tenhle klub je stejně důležitý,jako NYXí klub o umělé inteligenci... Fedi je jediná alternativa k budoucnosti plné chatbotů a AI generated contentu, v podstatě. Ti, kdo nejsou AI, se musí efektivně propojit a vzdorovat.

    Priznam se, ze mechanika tohohle mi unikla. Coze?

    (priznam se ze moc nechapu i ten zbytek, treba moc nevidim kde glyph pise o mastodon.social a tudiz na co reagujes, ale asi sem schopen domyslet co chces rict, ale tady u toho fakt ne)
    XCHAOS
    XCHAOS --- ---
    chybí vám některé features z Twitteru? zkuste @trending@mastodon.bot

    (pochopitelně, bude informovat o jiných trendujících hashtagách, než které trendují na vaší místní instanci, což je zajímavé...)
    XCHAOS
    XCHAOS --- ---
    ALMAD: takhle, Mastodon jako software a mastodon.social jsou dvě různý věci. mastodon.social může implodovat, protože napsali pomalé, neškálovatelné Ruby monstrum. Konkurenceschopná Fedi appka by měla být kompilovaná (už jsem viděl jednu v Rustu a ano, existuje ActivityPub knihovna v Rustu, takže podle mě není co řešit... pro mladší programátory, já to už budu mít složitější). Ale stejně neškálovatelné Ruby je úplně v pohodě, pokud jde o instance do 1000 uživatelů, které budeme provozovat my, tisíce ostatních...

    Debatu si sem nalinkoval zajímavou, já jen dodám, že zatímco desynchronizaci odpovědí už nepozoruju (teď jsem to testoval na reakcích na status, který je notabene bridgeovaný z BlueSky :-), tak migrace mezi instancema je fakt neohrabaná a je to pojaté tak, aby to nezkušenější uživatele odradilo. První věc, kterou by platforma, která vyzve Mastodon coby lídra ve fediverse, měla nabídnout, je daleko jednodušší rozhraní pro základní nastavení uživatele a velmi jednoduchá migrace, bez nějakého ukládání do externích souborů, apod. (to by měla být možnost, volitelná, pro lidi, co třeba chtějí zachovat kontinuitu, ale přečkat nějaké těžké období úplně offline a svoje data z Internetu na čas úplně stáhnout... ale většina by měla mít možnost migrovat odněkud někam na jedno kliknutí... a to včetně médií, všeho)

    Další věci, které by mi dávaly smysl, je sdílení seznamů v timeline (či v biu... oboje dává smysl, sdílení jako akt k nějakému okamžiku i sdílení trvalé), lepší členění timeline (např. vysvětlení, jestli něco vidím proto, že followuju uživatele nebo protože followuju hashtag), import historie nově follownutých účtů, konfigurovatelný algoritmus výběru toho zajímavého z timeline (něco jako Objevit, kde je stejně algoritmus, ale poměrně hloupý a skrytý), rozklikávání timelines dle instancí (vyberu si z federované timeline pouze statusy z nějaké instance)... prostě ta základní idea, co všechno může být timeline a podle všeho si ji sestavit, je klíčová.

    A samozřejmě... distribuované vyhledávání. Distribuované vyhledávání ve federovaných timelines má potenciál skutečně časem ohrozit monopol Googlu...a ohrozit dominanci AI. Ve hře je hodně. Fedi může být jediný nástroj, který máme v rukou jako protiváhu vůči domanci AI. Tenhle klub je stejně důležitý,jako NYXí klub o umělé inteligenci... Fedi je jediná alternativa k budoucnosti plné chatbotů a AI generated contentu, v podstatě. Ti, kdo nejsou AI, se musí efektivně propojit a vzdorovat.
    ALMAD
    ALMAD --- ---
    Deciphering Glyph :: The Federation Deathmatch
    https://blog.glyph.im/2024/11/the-federation-deathmatch.html
    XCHAOS
    XCHAOS --- ---
    Migrace Mastodon účtu – Ivan Stloukal
    https://stloukal.uk/migrace-mastodon-uctu/
    XCHAOS
    XCHAOS --- ---
    ALMAD: no nevím, berou na vědomí, že to problém je. Za mě je to stejné jako s jinýma atributama příspěvku: všiml jsem, si, že moje instance pracuje s cacheovaným stavem ve chvíli, kdy se příspěvek načte, ale další evoluci příspěvku zas tolik neřeší (max. editaci a boost). Třeba počet hvězdiček je prostě cacheovaný a neaktualizuje se. Takže si nakousl spíš obecný problém s tím, jak Mastodon pracuje s cache federované timeline, problém se netýká jen odpovědí. Tím, že s příspěvkem nějak interaguju, se vlastně "subscribuju" a mám zájem sledovat další evoluci příspěvku, včetně nových odpovědí, a instance by to měla zohlednit.

    Samozřejmě, teprve až si ActivityPub protokol nastuduju, tak asi pochopím, co Mastodon dělá špatně a odfláknutě, a proč pokročilí uživatelé preferují Misskey, Akkomu a Pleromu (nejen pokročilí, ale teda také ti mladší, zdá se...)
    ALMAD
    ALMAD --- ---
    XCHAOS: Muzes mi prosim poslat ten konretni koment kde se resi jak to vyresit? Protoze ja ho tam nikde nevidim, ani nevidim ack od vyvojaru ze to je problem co chtej vyresit.

    A znova, ja naprosto respektuju ze AP/Mastodon je OSS a nemam si stezovat a mam prispivat, jenom se snazim vysvetlit proc vidim lidi odchazet a ze mam pocit ze to souvisi i s tim “ty rikas ze je to problem ale ja vidim dva roky otevreny issue takze to vlastne problem neni”.

    Nicmene souhlas s tema jinejma implementacema, rad je vidim a doufam ze bude konkurence, zaroven jsem zvedavej jakej vliv to bude mit na evoluci AP protoze tam jsou veci k vylepseni a cim vic realnejch implementaci, tim tezsi.

    A nejsem si jistej jestli je dobry mit konkurenci na urovni protokolu, AT/AP zatim dobry ale neni mi jasny jak ten bridge skaluje.
    XCHAOS
    XCHAOS --- ---
    JARDABEREZA: transparentnost blokování je ošemetná věc: ve Fediverse se zjistilo, že veřejné blacklisty byly do jisté míry reklamami na blokované instance, takže se začaly používat různé masky s hvězdičkami, apod. Obecně, pokud mi nějaký spammer či troll opravdu naštve, tak asi ani moc nechci, aby věděl, že ho blokuju, protože budu chtít, aby co nejvíc resourců vyplýval na iluzi, že se mnou interaguje... tedy, budu mu chtít podvrhnout klamné cíle, ne ho veřejně informovat, že může svými zdroji plýtvat jinde...
    XCHAOS
    XCHAOS --- ---
    ALMAD: není pravda, že se neřeší.
    When opening a post, show all replies (not just those from servers known to the user's instance). · Issue #22674 · mastodon/mastodon · GitHub
    https://github.com/mastodon/mastodon/issues/22674

    obecně implementace ActivityPub protokolu v Mastodonu nemusí být jediná a nejlepší možná. To, že spousta komunit experimentuje s platformami Misskey, Pleroma, Akkoma, apod. naznačuje, že existuje víc než jeden přístup, jak tu federaci udělat správně.

    Jde o to, že představa, že všechna data všech uživatelů budou navždy na jednom jediném místě indexované v rámci jedné jediné databáze, je prostě zcela určitě chybná: neřeší to zálohování, třeba i na půdu jiných institucí (ale dnešní Fediverse teda zálohování taky moc neřeší - třeba že dvě instance by se rozhodly si data plně vzájemně zálohovat, včetně schopnosti obnovy ze zálohy, apod.) a nakonec se vždy narazí na nějaké hranice škálovatelnosti (ano, to jde řešit, že archivní ročníky poběží fyzicky na starších pomalejších serverech, apod.)

    To, že víme, že něco je špatně (centralizovaný přístup) ale ještě neznamená, že máme jasno v tom, jak to udělat dobře. Agresivnější cacheování aktuálního stavu příspěvků by rozhodně pomohlo více věcem, třeba i zobrazení správného stavu počtu hvězdiček (které na druhou stranu je náchylné k tomu, aby ho začali ovlivňovat spammeři, takže do jisté míry relevantní informace je spíš počet hvězdičkujících instancí, než údajný počet včetně favů na vzdálených instancích... a pouze sofistikovaní spammeři dokáží spamovat s více instancí současně, atd.)

    Obecně zobrazení všech reply na status by mohlo být v silách odpovědí na příspěvek na místní instanci, ale je téměř nemožné to zajistit u náhodných příspěvků, kde diskuzi pod nimi pouze sledujeme (přesto často smysluplné vlákno pod příspěvky vidím).

    Protocol ActivityPub předpokládá, že příspěvek obsahuje seznam všech odpovědí na něj:
    ActivityPub/Primer/Replies - W3C Wiki
    https://www.w3.org/wiki/ActivityPub/Primer/Replies

    Problém se tedy zužuje na četnost cacheování příspěvků, pod kterým se dá očekávat probíhající diskuze. Opakované načtení příspěvku do místní cache samozřejmě zvyšuje šanci, že počet odpovědí z jiných instancí je aktuální.
    XCHAOS
    XCHAOS --- ---
    JARDABEREZA: otázka ke, jestli oddělení identity od hostingu je taková výhra. A ještě nikdo mi nepředvedl, že skutečný hosting dat může být jinde, než centralizovaně na Bluesky (neříkám, že na to ten jejich protokol možná nemyslilí, ale zatím nevím o nikom, kdo by to dělal)

    Ta věc, že ve federované síti nikdy nebudou všechna data najednou cacheována na lokální instanci na druhou stranu neznamená, že relavantní data, např. všechny odpovědi na status, časem cacheovaná být nemohou. Otázkou je jen správné načasování. Jako argument, proč decentralizaci a federaci vzdát a vrátit se k centralizovanému úližišti to neobstojí.

    Ano, UX se bude muset čase zlepšit a Mastodon sám se už asi nikam moc neposune. Bude nutné přejít k jiným Fedi appkám...
    JARDABEREZA
    JARDABEREZA --- ---
    Tady ještě Dan komentuje pár zajímavých otázek:

    @j720.bsky.social on Bluesky
    https://bsky.app/profile/j720.bsky.social/post/3la33g7inqu2p
    (Q) What advantages does @atproto.com have over the fediverse ?

    it decouples hosting and identity from applications. concretely this means that apps feel cohesive (not split into “islands”) with a global view of the entire network (can build features like feeds) but you can change your hosting at any point (with no disruption to user experience).

    @matscloud.com on Bluesky
    https://bsky.app/profile/matscloud.com/post/3la33vmb2nf2r
    (Q) Here's a "weird" one... Can you really run and store your own data? Does that mean I can run a "private instance" of BlueSky for only my own employees?

    in atproto architecture, these are two separate and unrelated questions.
    (1) yes, you can store your own data — even right now if you’d like. for that, you’d run a personal data server. the bluesky backend pulls information from all personal data servers it knows about, so it’ll see your posts
    (2) re: "private instance", it’s not impossible but it would take some work since you’d need to copy the relay (which aggregates data from personal data servers) and the AppView (the actual bluesky backend) and then run them all internally only. it seems like mastodon is a better fit for your case?
    ALMAD
    ALMAD --- ---
    XCHAOS: Nic z toho neni neresitelnej problem, ale neresi se a to je to o cem ty lidi mluvej :)

    (I kdyz teda ten reply problem je to co je pro uzivTele zasadni, a tam si myslim ze by to byl celkem zasadni zasah do toho protokolu)
    JARDABEREZA
    JARDABEREZA --- ---
    XCHAOS: To mi ještě připomělo... BlueSky má otevřený prokol či co... takže i bez účtu si můžeš např. zjistit kdo koho blokuje, kde je v jakých listech anebo i vidět příspěvky někoho kdo tě blokoval. https://clearsky.app/danabra.mov/blocked-by prý kvůli architektuře co si zvolili to musí být volně přístupné. Mělo by to fungovat na ATProtocolu: https://atproto.com/

    https://arxiv.org/pdf/2402.03239
    XCHAOS
    XCHAOS --- ---
    ALMAD: jeho problém způsobovala nějaká starší verze Mastodonu, nejspíš. Ty novější čekaj několik sekund, než vytvořej náhled vloženýho odkazu. Problém by pravděpodobně vyřešilo přidání náhodný prodlevy před pokusem o vygenerování thumbnailu odkazu. Proč v rámci federace nejsou předávány i thumbnaily a každá instance si to fetchuje znova, to je zajímavá otázka. Je to víceméně programátorský problém, který by se dokonce mohl řešit jako volitelné nastavení domovské instance autora (něco jako [ ] share preview thumbnails, ve skutečnosti instance budou mít časem zájem fungovat jako CDN a budou mít zájem nejen downloadovat, ale i uploadovat, podle mě.... ale někdo to bude muset naprogramovat, no)

    ano, pochopil jsem to nejdřív špatně, jemu nejde o to, že by lidi vtrhli na ten blog, ale vtrhne tam každá instance znova a on má hodně followerů z hodně instancí a tím skutečně DDoSuje cokoliv, na co hodí odkaz, jak se všechny instance snaží udělat thumbnail. Hubzilla tohle obchází tím, že sdílí předgenerovanej HTML fragment, ve kterým všechno míří přímo na tu instanci a ten se sdílí i z tvrdýma absolutníma odkazama na domovskou instanci příspěvku. Což taky není ideální.

    Každopádně, nejde o nijak neřešitelnej nebo zásadní problém. V další verzi Mastodonu to může být patchnutý, buď sdílením thumbnailu mezi instancema (tam není definovaný pořadí v jakým to získávají, takže by hrozilo, že se obrátí na tu první, kde se to publikovalo, to je problém), nebo zcela primitivně, vložením náhodné prodlevy před pokusem o fetchnutí odkazu (jeden request za sekundu zvládne každý webserver, popravdě i deset requestů, a vložení alespoň trochu náhodného zpoždění před zpracováním nového statusu v timeline by problém nejspíš řešilo... ostatně ani teď mi nepřijde, že to pollování by se dělo úplně realtime, občas je před aktualizací timeline na jiné instanci docela prodleva...)
    Kliknutím sem můžete změnit nastavení reklam