home.social

#tipy — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #tipy, aggregated by home.social.

fetched live
  1. A bonus na závěr: proč často nevidíme správný počet boostů, a ještě méně často správný počet favů u statusů, přicházejících z jiné instance?

    Stručná odpověď je, že Fediverse nemá ambici tvořit blockchain, na rozdíl od kryptoměn. Neexistuje žádná záruka, že cacheovaná verze statusu obsahuje všechna metadata přesně v takové podobě, v jaké jsou momentálně nastavena na domovské instanci statusu. Konkrétně u počtu boostů a favů mi to vrtalo hlavou dlouho, ale nakonec jsem dospěl k logickému vysvětlení:

    Nový followovaný status se na každé instanci objeví v podstatě naklonovaný tak, jak vypadal v momentě svého vzniku. Dobře, možná u něj bude pár místních interakcí (místních z hlediska domovské instance statusu), protože instance si nepovídají nonstop.

    Lidé se u nově zobrazeného statusu v timeline rozhodují, jestli ho boostnou nebo favnou. Pokud favují, nedozvíte se to. Pokud boostují, jejich boost se přičte - a teprve potom status uvidíte vy. Se zvýšeným počtem boostů, nikoliv favů :-)

    #tipy 6/6

  2. A bonus na závěr: proč často nevidíme správný počet boostů, a ještě méně často správný počet favů u statusů, přicházejících z jiné instance?

    Stručná odpověď je, že Fediverse nemá ambici tvořit blockchain, na rozdíl od kryptoměn. Neexistuje žádná záruka, že cacheovaná verze statusu obsahuje všechna metadata přesně v takové podobě, v jaké jsou momentálně nastavena na domovské instanci statusu. Konkrétně u počtu boostů a favů mi to vrtalo hlavou dlouho, ale nakonec jsem dospěl k logickému vysvětlení:

    Nový followovaný status se na každé instanci objeví v podstatě naklonovaný tak, jak vypadal v momentě svého vzniku. Dobře, možná u něj bude pár místních interakcí (místních z hlediska domovské instance statusu), protože instance si nepovídají nonstop.

    Lidé se u nově zobrazeného statusu v timeline rozhodují, jestli ho boostnou nebo favnou. Pokud favují, nedozvíte se to. Pokud boostují, jejich boost se přičte - a teprve potom status uvidíte vy. Se zvýšeným počtem boostů, nikoliv favů :-)

    #tipy 6/6

  3. Shrnutí:

    Interakce dávají smysl! A to nejen boostování (které jak se ukazuje, spoustu lidí štve a hrozí vám, že si u vás potlačí zobrazování boostovaných statusů...), ale i dříve silně nepochopené favování.

    Pokud favnete nějaký status, není to jen vzkaz autorovi, že se vám to líbí, ale je to především vzkaz softwaru místní instance: nemaž tento status v budoucnu, zaujal mi! Je to příznak, že má zůstat v databázi místní instance už na věčné časy.

    Pokud se vám líbí diskuze pod nějakým statusem, ale odpovědi pocházejí z jiných instancí, tak rozhodně favujte všechny statusy v diskuzním vlákně. Jinak totiž po čase hrozí vymazání z místní cache.

    (Pravda, relativně nedávno se objevilo vylepšení Mastodonu: ten se nově snaží před zobrazením komentářů o aktualizaci statusu, načtení a zobrazení všech odpovědí bez ohledu na instanci. To ale může selhat podobným způsobem, jako načítání médií, které už nejsou cacheované..)

    Podotýkám, že jsem pro jistotu úplně vynechal instituci followování hashtagů a to z poměrně jednoduchého důvodu: nemám to zatím do hloubky nastudované. Minimálně jsou ale hashtagy v Mastodonu implementované jinak (lépe!), než v některých jiných ActivityPub kompatibilních CMS (např. v Hubzille). Každopádně, hashtagy jsou minimálně stejně důležité, jako ALT text, ale všimněte si, že nikdo (zatím!) neprodává trička se sloganem #používámhashtagy :-)

    Hashtagy trochu mění pravidla hry, kdy váš status může vidět na nějaké jiné instanci někdo, kdo vás nefollowuje. Hashtagy tvoří decentralizovaný algoritmus pod společnou kontrolou jak autorů, tak moderátorů: málokdo tuší, že moderační rozhraní Mastodonu umožňuje blokovat trendování konkrétních hashtagů!

    Netuším, jestli životnost statusu, který se do cache dostal skrze followování hashtagu, odpovídá životnosti statusu od followovaného uživatele, nebo životnosti náhodně zatoulaného statusu. Věřím, že nástupce Mastodonu bude metadata tohoto typu v maximální možné míře zpřístupňovat :-)

    #tipy 5/6

  4. Shrnutí:

    Interakce dávají smysl! A to nejen boostování (které jak se ukazuje, spoustu lidí štve a hrozí vám, že si u vás potlačí zobrazování boostovaných statusů...), ale i dříve silně nepochopené favování.

    Pokud favnete nějaký status, není to jen vzkaz autorovi, že se vám to líbí, ale je to především vzkaz softwaru místní instance: nemaž tento status v budoucnu, zaujal mi! Je to příznak, že má zůstat v databázi místní instance už na věčné časy.

    Pokud se vám líbí diskuze pod nějakým statusem, ale odpovědi pocházejí z jiných instancí, tak rozhodně favujte všechny statusy v diskuzním vlákně. Jinak totiž po čase hrozí vymazání z místní cache.

    (Pravda, relativně nedávno se objevilo vylepšení Mastodonu: ten se nově snaží před zobrazením komentářů o aktualizaci statusu, načtení a zobrazení všech odpovědí bez ohledu na instanci. To ale může selhat podobným způsobem, jako načítání médií, které už nejsou cacheované..)

    Podotýkám, že jsem pro jistotu úplně vynechal instituci followování hashtagů a to z poměrně jednoduchého důvodu: nemám to zatím do hloubky nastudované. Minimálně jsou ale hashtagy v Mastodonu implementované jinak (lépe!), než v některých jiných ActivityPub kompatibilních CMS (např. v Hubzille). Každopádně, hashtagy jsou minimálně stejně důležité, jako ALT text, ale všimněte si, že nikdo (zatím!) neprodává trička se sloganem #používámhashtagy :-)

    Hashtagy trochu mění pravidla hry, kdy váš status může vidět na nějaké jiné instanci někdo, kdo vás nefollowuje. Hashtagy tvoří decentralizovaný algoritmus pod společnou kontrolou jak autorů, tak moderátorů: málokdo tuší, že moderační rozhraní Mastodonu umožňuje blokovat trendování konkrétních hashtagů!

    Netuším, jestli životnost statusu, který se do cache dostal skrze followování hashtagu, odpovídá životnosti statusu od followovaného uživatele, nebo životnosti náhodně zatoulaného statusu. Věřím, že nástupce Mastodonu bude metadata tohoto typu v maximální možné míře zpřístupňovat :-)

    #tipy 5/6

  5. Kromě expirace mediální cache, která je vcelku srozumitelná a kromě speciálního případu, kdy vzdálená instance mezitím předstane existovat a nebo je zrovna mimo provoz či přetížená, vlastně nepředstavuje zásadní problém, je tu ale ještě otázka cacheování samotných textových statusů z jiných instancí.

    Zabírají daleko méně místa, než média, ale současně: databáze fungují nejlíp a nejrychleji, pokud se jednotlivé tabulky nebo alespoň jejich indexy vejdou do paměti RAM. Té bývá na většině systémů už tradičně k dispozici daleko méně, než místa na disku, a současná AI bublina rozhodně dostupnost paměti RAM nezlepšila. Proto je součástí Mastodonu i poněkud mlhavě zdokumentovaný backend nástroj pro správu a úklid databáze, který z ní dokáže vystrnadit všechno možné. A to zejména statusy, se kterými nikdo na místní instanci neinteragoval. Místní interakcí se rozumí boost, fav, odpověď nebo bookmarkování (vše jen od místních uživatelů).

    Statusy bez interakcí se dále dělí na dvě hlavní skupiny: ty, které někdo na instanci followuje, a ty, které nikdo nefollowuje (to znamená, že se k nám dostaly buď jako boost, nebo jako odpověď na jiný status, a nebo přímým načtením jejich URL přes okénko vyhledávání). Na naší instanci je životnost první skupiny bez interakcí omezena na 365 dnů, druhé skupiny na 90 dnů. Ale protože databáze neustále roste (místní statusy musíme archivovat všechny a trvale!), tak je možné, že tyto lhůty bude nutné časem zkrátit.

    Tím se dostáváme do finále:

    * Kdy uživatelé na jiných instancích mohou vidět můj obsah?

    Volejte vašemu věštci! Ptejte se tarotových karet a špionážních služeb!

    Podstatné parametry, které jsem zde zmínil, tedy životnost mediální cache, a životnost dvou druhů statusů bez interakcí, instance Mastodonu nezveřejňují přes API.

    Pokud mezi instancemi není vyhlášen ani z jedné strany ban na úrovni celých domén, měl by vaše statusy, zveřejněné od momentu follownutí, po nějakou dobu vidět kdokoliv, kdo vás followuje.

    #tipy 4/6

  6. Kromě expirace mediální cache, která je vcelku srozumitelná a kromě speciálního případu, kdy vzdálená instance mezitím předstane existovat a nebo je zrovna mimo provoz či přetížená, vlastně nepředstavuje zásadní problém, je tu ale ještě otázka cacheování samotných textových statusů z jiných instancí.

    Zabírají daleko méně místa, než média, ale současně: databáze fungují nejlíp a nejrychleji, pokud se jednotlivé tabulky nebo alespoň jejich indexy vejdou do paměti RAM. Té bývá na většině systémů už tradičně k dispozici daleko méně, než místa na disku, a současná AI bublina rozhodně dostupnost paměti RAM nezlepšila. Proto je součástí Mastodonu i poněkud mlhavě zdokumentovaný backend nástroj pro správu a úklid databáze, který z ní dokáže vystrnadit všechno možné. A to zejména statusy, se kterými nikdo na místní instanci neinteragoval. Místní interakcí se rozumí boost, fav, odpověď nebo bookmarkování (vše jen od místních uživatelů).

    Statusy bez interakcí se dále dělí na dvě hlavní skupiny: ty, které někdo na instanci followuje, a ty, které nikdo nefollowuje (to znamená, že se k nám dostaly buď jako boost, nebo jako odpověď na jiný status, a nebo přímým načtením jejich URL přes okénko vyhledávání). Na naší instanci je životnost první skupiny bez interakcí omezena na 365 dnů, druhé skupiny na 90 dnů. Ale protože databáze neustále roste (místní statusy musíme archivovat všechny a trvale!), tak je možné, že tyto lhůty bude nutné časem zkrátit.

    Tím se dostáváme do finále:

    * Kdy uživatelé na jiných instancích mohou vidět můj obsah?

    Volejte vašemu věštci! Ptejte se tarotových karet a špionážních služeb!

    Podstatné parametry, které jsem zde zmínil, tedy životnost mediální cache, a životnost dvou druhů statusů bez interakcí, instance Mastodonu nezveřejňují přes API.

    Pokud mezi instancemi není vyhlášen ani z jedné strany ban na úrovni celých domén, měl by vaše statusy, zveřejněné od momentu follownutí, po nějakou dobu vidět kdokoliv, kdo vás followuje.

    #tipy 4/6

  7. .... a zde se dostáváme k zásadní nevýhodě tzv. vláken, tedy že na začítku nevíte, kolik toho napíšete, situace je tedy podobná, jako u příslovečné třetí poloviny.

    #tipy 5/4

    Shrnutí:

    Interakce dávají smysl! A to nejen boostování (které jak se ukazuje, spoustu lidí štve a hrozí vám, že si u vás potlačí zobrazování boostovaných statusů...), ale i dříve silně nepochopené favování.

    Pokud favnete nějaký status, není to jen vzkaz autorovi, že se vám to líbí, ale je to především vzkaz softwaru místní instance: nemaž tento status v budoucnu, zaujal mi! Je to příznak, že má zůstat v databázi místní instance už na věčné časy.

    Pokud se vám líbí diskuze pod nějakým statusem, ale odpovědi pocházejí z jiných instancí, tak rozhodně favujte všechny statusy v diskuzním vlákně. Jinak totiž po čase hrozí vymazání z místní cache.

    (Pravda, relativně nedávno se objevilo vylepšení Mastodonu: ten se nově snaží před zobrazením komentářů o aktualizaci statusu, načtení a zobrazení všech odpovědí bez ohledu na instanci. To ale může selhat podobným způsobem, jako načítání médií, které už nejsou cacheované..)

    A bonus na závěr: proč často nevidíme správný počet boostů, a ještě méně často správný počet favů u statusů, přicházejících z jiné instance?

  8. .... a zde se dostáváme k zásadní nevýhodě tzv. vláken, tedy že na začítku nevíte, kolik toho napíšete, situace je tedy podobná, jako u příslovečné třetí poloviny.

    #tipy 5/4

    Shrnutí:

    Interakce dávají smysl! A to nejen boostování (které jak se ukazuje, spoustu lidí štve a hrozí vám, že si u vás potlačí zobrazování boostovaných statusů...), ale i dříve silně nepochopené favování.

    Pokud favnete nějaký status, není to jen vzkaz autorovi, že se vám to líbí, ale je to především vzkaz softwaru místní instance: nemaž tento status v budoucnu, zaujal mi! Je to příznak, že má zůstat v databázi místní instance už na věčné časy.

    Pokud se vám líbí diskuze pod nějakým statusem, ale odpovědi pocházejí z jiných instancí, tak rozhodně favujte všechny statusy v diskuzním vlákně. Jinak totiž po čase hrozí vymazání z místní cache.

    (Pravda, relativně nedávno se objevilo vylepšení Mastodonu: ten se nově snaží před zobrazením komentářů o aktualizaci statusu, načtení a zobrazení všech odpovědí bez ohledu na instanci. To ale může selhat podobným způsobem, jako načítání médií, které už nejsou cacheované..)

    A bonus na závěr: proč často nevidíme správný počet boostů, a ještě méně často správný počet favů u statusů, přicházejících z jiné instance?

  9. Kromě expirace mediální cache, která je vcelku srozumitelná a kromě speciálního případu, kdy vzdálená instance mezitím předstane existovat a nebo je zrovna mimo provoz či přetížená, vlastně nepředstavuje zásadní problém, je tu ale ještě otázka cacheování samotných textových statusů z jiných instancí.

    Zabírají daleko méně místa, než média, ale současně: databáze fungují nejlíp a nejrychleji, pokud se jednotlivé tabulky nebo alespoň jejich indexy vejdou do paměti RAM. Té bývá na většině systémů už tradičně k dispozici daleko méně, než místa na disku, a současná AI bublina rozhodně dostupnost paměti RAM nezlepšila. Proto je součástí Mastodonu i poněkud mlhavě zdokumentovaný nástroj backend nástroj pro správu a úklid databáze, který z ní dokáže vystrnadit všechno možné. A to zejména statusy, se kterými nikdo na místní instanci neinteragoval. Místní interakcí se rozumí boost, fav, odpověď nebo bookmarkování (vše jen od místních uživatelů).

    Statusy bez interakcí se dále dělí na dvě hlavní skupiny: ty, které někdo na instanci followuje, a ty, které nikdo nefollowuje (to znamená, že se k nám dostaly buď jako boost, nebo jako odpověď na jiný status, a nebo přímým načtením jejich URL přes okénko vyhledávání). Na naší instanci je životnost první skupiny bez interakcí omezena na 365 dnů, druhé skupiny na 90 dnů. Ale protože databáze neustále roste (místní statusy musíme archivovat všechny a trvale!), tak je možné, že tyto lhůty bude nutné časem zkrátit.

    Tím se dostáváme do finále:

    * Kdy uživatelé na jiných instancích mohou vidět můj obsah?

    Volejte vašemu věštci! Ptejte se tarotových karet a špionážních služeb!

    Podstatné parametry, které jsem zde zmínil, tedy životnost mediální cache, a životnost dvou druhů statusů bez interakcí, instance Mastodonu nezveřejňují přes API.

    Pokud mezi instancemi není vyhlášen ani z jedné strany ban na úrovni celých domén, měl by vaše statusy, zveřejněné od momentu follownutí, po nějakou dobu vidět kdokoliv, kdo vás followuje.

    #tipy 4/4

  10. Kromě expirace mediální cache, která je vcelku srozumitelná a kromě speciálního případu, kdy vzdálená instance mezitím předstane existovat a nebo je zrovna mimo provoz či přetížená, vlastně nepředstavuje zásadní problém, je tu ale ještě otázka cacheování samotných textových statusů z jiných instancí.

    Zabírají daleko méně místa, než média, ale současně: databáze fungují nejlíp a nejrychleji, pokud se jednotlivé tabulky nebo alespoň jejich indexy vejdou do paměti RAM. Té bývá na většině systémů už tradičně k dispozici daleko méně, než místa na disku, a současná AI bublina rozhodně dostupnost paměti RAM nezlepšila. Proto je součástí Mastodonu i poněkud mlhavě zdokumentovaný nástroj backend nástroj pro správu a úklid databáze, který z ní dokáže vystrnadit všechno možné. A to zejména statusy, se kterými nikdo na místní instanci neinteragoval. Místní interakcí se rozumí boost, fav, odpověď nebo bookmarkování (vše jen od místních uživatelů).

    Statusy bez interakcí se dále dělí na dvě hlavní skupiny: ty, které někdo na instanci followuje, a ty, které nikdo nefollowuje (to znamená, že se k nám dostaly buď jako boost, nebo jako odpověď na jiný status, a nebo přímým načtením jejich URL přes okénko vyhledávání). Na naší instanci je životnost první skupiny bez interakcí omezena na 365 dnů, druhé skupiny na 90 dnů. Ale protože databáze neustále roste (místní statusy musíme archivovat všechny a trvale!), tak je možné, že tyto lhůty bude nutné časem zkrátit.

    Tím se dostáváme do finále:

    * Kdy uživatelé na jiných instancích mohou vidět můj obsah?

    Volejte vašemu věštci! Ptejte se tarotových karet a špionážních služeb!

    Podstatné parametry, které jsem zde zmínil, tedy životnost mediální cache, a životnost dvou druhů statusů bez interakcí, instance Mastodonu nezveřejňují přes API.

    Pokud mezi instancemi není vyhlášen ani z jedné strany ban na úrovni celých domén, měl by vaše statusy, zveřejněné od momentu follownutí, po nějakou dobu vidět kdokoliv, kdo vás followuje.

    #tipy 4/4

  11. Nyní se postupně od jednoduché otázky existence a dostupnosti obsahu na jedné instance pro všechny uživatele dané instance, která se principiálně neliší od jakéhokoliv webového diskuzního fóra, jakých se za posledních zhruba 30 let existence webu vyrojily po světě miliony, dostáváme k těm situacím, které i celkem pokročilé uživatele často matou.

    * Kdy já můžu vidět obsah od uživatele z jiné instance?

    Především: v řadě triviálních případů. Třeba pokud je v daném statusu (zprávě) zmíněno moje Fediverse uživatelské jméno, a to bez ohledu na úroveň soukromí (veřejná odpověď nebo soukromá zpráva).

    Samozřejmě, jakýkoliv status odkudkoliv uvidím, pokud uživatele followuju. A to zejména, pokud jsem ho follownul PŘEDTÍM, než zprávu zveřejnil. Pokud chci vidět přímo ze své instance, ke které jsem přihlášený, jeho starší zprávy, tak je situace složitější.

    Naprostou jistotu mám, pokud znám identifikátor zprávy na původní instanci (URL): nakopírováním URL do vyhledávacího okénka zprávu natáhnu do místní cache.

    Pokud si prohlížím profil uživatele, kterého na instanci zatím nikdo nefollowuje, tak je to, jaké statusy uvidím, poměrně nedefinované. Samozřejmě, nejdřív bych měl vidět připnuté statusy. Novější verze Mastodonu se tuším u nově objevených profilů snaží vždy o nějaké stažení aktuálních statusů. Historicky se ale profily dosud neznámých uživatelů ukazovaly prázdné, což v éře Mastodon migrace odradilo spoustu začátečníků, protože se to nepodobalo chování centralizovaných služeb, na které byli zvyklí.

    Máme tedy status z jiné instance nějakým způsobem natažený do cache naší instance. I s médii. Je to záruka, že ho na instanci uvidíme i kdykoliv v budoucnu? Bohužel ne!

    Především, životnost mediální cache, kde se uchovávají média z jiných instancí, je omezená. U nás jsou to cca 3 týdny, a i tak to představuje většinu zabraného místa na disku - stovky GB. Pokud si status otevřete později, pokusí se instance média načíst znovu, ale nemusí se jít to povést.

    #tipy 3/6

  12. Nyní se postupně od jednoduché otázky existence a dostupnosti obsahu na jedné instance pro všechny uživatele dané instance, která se principiálně neliší od jakéhokoliv webového diskuzního fóra, jakých se za posledních zhruba 30 let existence webu vyrojily po světě miliony, dostáváme k těm situacím, které i celkem pokročilé uživatele často matou.

    * Kdy já můžu vidět obsah od uživatele z jiné instance?

    Především: v řadě triviálních případů. Třeba pokud je v daném statusu (zprávě) zmíněno moje Fediverse uživatelské jméno, a to bez ohledu na úroveň soukromí (veřejná odpověď nebo soukromá zpráva).

    Samozřejmě, jakýkoliv status odkudkoliv uvidím, pokud uživatele followuju. A to zejména, pokud jsem ho follownul PŘEDTÍM, než zprávu zveřejnil. Pokud chci vidět přímo ze své instance, ke které jsem přihlášený, jeho starší zprávy, tak je situace složitější.

    Naprostou jistotu mám, pokud znám identifikátor zprávy na původní instanci (URL): nakopírováním URL do vyhledávacího okénka zprávu natáhnu do místní cache.

    Pokud si prohlížím profil uživatele, kterého na instanci zatím nikdo nefollowuje, tak je to, jaké statusy uvidím, poměrně nedefinované. Samozřejmě, nejdřív bych měl vidět připnuté statusy. Novější verze Mastodonu se tuším u nově objevených profilů snaží vždy o nějaké stažení aktuálních statusů. Historicky se ale profily dosud neznámých uživatelů ukazovaly prázdné, což v éře Mastodon migrace odradilo spoustu začátečníků, protože se to nepodobalo chování centralizovaných služeb, na které byli zvyklí.

    Máme tedy status z jiné instance nějakým způsobem natažený do cache naší instance. I s médii. Je to záruka, že ho na instanci uvidíme i kdykoliv v budoucnu? Bohužel ne!

    Především, životnost mediální cache, kde se uchovávají média z jiných instancí, je omezená. U nás jsou to cca 3 týdny, a i tak to představuje většinu zabraného místa na disku - stovky GB. Pokud si status otevřete později, pokusí se instance média načíst znovu, ale nemusí se jít to povést.

    #tipy 3/6

  13. Řekněme si hned na začátek, že protokol ActivityPub, na kterém je Fediverse postavena, má svojí filosofií blíže k těm historickým koncepcím, jako byl Usenet na bázi protokolu NNTP nebo amatérská síť Fidonet, se svým členěním na nody a pointy a absencí šifrování.

    Šifrování se v případě Fediverse omezuje na připojení vašeho browseru nebo klientské aplikace k serveru, což dnes představuje samozřejmý standard a chrání vás to např. před odposlednutím hesla např. ze strany uživatelů stejné Wi-Fi sítě, správce sítě nebo ze strany poskytovatele Internetu - ale tím to končí.

    Na serverech se obsah nachází v nešifrované podobě - ovšem, na rozdíl od těch 90tých let, kdy bylo v podstatě velmi snadné vydávat se za kohokoliv jiného, jsou zprávy ve Fediverse digitálně podepsané. Privátní klíče jsou uložené na instancích, tedy serverech, a z toho začíná být zřejmý zásadní význam vztahu mezi uživatelem a provozovatelem instance. Opravdu nároční uživatelé, kteří neradi důvěrují službám poskytovaným třetí stranou, nakonec skončí u self-hostingu vlastní instance na vlastní doméně.

    Takže když už jsme si řekli, že administrátoři instanci vidí tak nějak automaticky všechno, což u sítě, navržené v první řadě za účelem publikace, není velká katastrofa a (čistě technicky) se mohou vydávat v podstatě za kteréhokoliv uživatele instance, což je už trochu horší, tak se vraťme k původnímu tématu: jaký obsah může kdo, kde a kdy vidět - a nejen vidět, ale vůbec alespoň teoreticky dohledat?

    Nejjednodušší situace nastává u uživatelů na stejné instanci. Pokud nedojde k omezení životnosti vlastních statusů (to je volitelné, ale naštěstí ne výchozí nastavení), pokud někdo status lokálně nesmaže a pokud není nastavená některá ze zvýšených úrovní soukromí, tak na místní instanci vidí všichni text statusů i připojená média neomezeně dlouho. Z toho vyplývá, že výše případného příspěvku na provoz instance se může odvíjet od místa zabraného mediálními přílohami. Třeba u mě je to 3.1 GB...

    #tipy 2/6

  14. Řekněme si hned na začátek, že protokol ActivityPub, na kterém je Fediverse postavena, má svojí filosofií blíže k těm historickým koncepcím, jako byl Usenet na bázi protokolu NNTP nebo amatérská síť Fidonet, se svým členěním na nody a pointy a absencí šifrování.

    Šifrování se v případě Fediverse omezuje na připojení vašeho browseru nebo klientské aplikace k serveru, což dnes představuje samozřejmý standard a chrání vás to např. před odposlednutím hesla např. ze strany uživatelů stejné Wi-Fi sítě, správce sítě nebo ze strany poskytovatele Internetu - ale tím to končí.

    Na serverech se obsah nachází v nešifrované podobě - ovšem, na rozdíl od těch 90tých let, kdy bylo v podstatě velmi snadné vydávat se za kohokoliv jiného, jsou zprávy ve Fediverse digitálně podepsané. Privátní klíče jsou uložené na instancích, tedy serverech, a z toho začíná být zřejmý zásadní význam vztahu mezi uživatelem a provozovatelem instance. Opravdu nároční uživatelé, kteří neradi důvěrují službám poskytovaným třetí stranou, nakonec skončí u self-hostingu vlastní instance na vlastní doméně.

    Takže když už jsme si řekli, že administrátoři instanci vidí tak nějak automaticky všechno, což u sítě, navržené v první řadě za účelem publikace, není velká katastrofa a (čistě technicky) se mohou vydávat v podstatě za kteréhokoliv uživatele instance, což je už trochu horší, tak se vraťme k původnímu tématu: jaký obsah může kdo, kde a kdy vidět - a nejen vidět, ale vůbec alespoň teoreticky dohledat?

    Nejjednodušší situace nastává u uživatelů na stejné instanci. Pokud nedojde k omezení životnosti vlastních statusů (to je volitelné, ale naštěstí ne výchozí nastavení), pokud někdo status lokálně nesmaže a pokud není nastavená některá ze zvýšených úrovní soukromí, tak na místní instanci vidí všichni text statusů i připojená média neomezeně dlouho. Z toho vyplývá, že výše případného příspěvku na provoz instance se může odvíjet od místa zabraného mediálními přílohami. Třeba u mě je to 3.1 GB...

    #tipy 2/6

  15. Včerejší vlákno o "syndromu prázdné timeline", který postihuje totální nezkušené začátečníky, navyklé na algoritmické krmení obsahem, mělo vcelku odezvu.

    V dalším pokračování se zaměřím na středně pokročilé uživatele informačních technologií, kteří sice základní nástrahy překonali, ale pořád jim není vzhledem k decentralizované povaze Fediverse úplně jasné kdo, kde a kdy může vidět jaký obsah. A trápí je otázky trvanlivosti či bezpečnosti.

    Pro začátek si řekněme, že Fediverse je jen dalším pokračováním dlouhé řady projektů decentralizovaného sdílení obsahu na Internetu. Jde o síť typu peer2peer, ovšem na úrovni celých instancí - nikoliv na úrovni koncových uživatelů.

    Pokud jde o starší peer2peer sítě, většina z vás se setkala buď s bittorrentem nebo s kryptoměnami a i pokud ne, tak možná tušíte, o co jde. V principu každý, kdo z těchto sítí čerpá obsah, ho současně může šířit dál. V případě bittorrentu je cílem získat mnoha různými cestami po malých částech přesně identickou kopii existujícího obsahu, např. nasdíleného filmu, a to přesto, že šířka pásma by v případě přímého stahování rozhodně nestačila pro všechny zájemce. V případě kryptoměn je základní princip podobný, ale sdíleným souborem je distribuovaná databáze typu blockchain, kde se kombinuje důraz na to, aby všichni uživatelé disponovali identickou kopií s velmi přísnými pravidly pro přidávání dalších záznamů.

    Tyto dvě technologie, které se objevily po roce 2000, představovaly výrazný odklon od předchozích trendů v decentralizaci.

    Základem raného Internetu byly dodnes existující e-mail a zapomenutý Usenet. Amatérskou paralelou akademického Internetu byla na vytáčeném připojení a modemech postavená síť Fidonet, která nabízela obdobné služby Netmail a Echomail.

    Jak raný Internet, tak Fidonet předpokládaly nepříliš strmou hierarchii, kdy peer2peer povahu měla síť serverů (nodů), ale architektura připojení koncových uživatelů měla spíše charakter klient-server.

    #tipy 1/6

  16. Včerejší vlákno o "syndromu prázdné timeline", který postihuje totální nezkušené začátečníky, navyklé na algoritmické krmení obsahem, mělo vcelku odezvu.

    V dalším pokračování se zaměřím na středně pokročilé uživatele informačních technologií, kteří sice základní nástrahy překonali, ale pořád jim není vzhledem k decentralizované povaze Fediverse úplně jasné kdo, kde a kdy může vidět jaký obsah. A trápí je otázky trvanlivosti či bezpečnosti.

    Pro začátek si řekněme, že Fediverse je jen dalším pokračováním dlouhé řady projektů decentralizovaného sdílení obsahu na Internetu. Jde o síť typu peer2peer, ovšem na úrovni celých instancí - nikoliv na úrovni koncových uživatelů.

    Pokud jde o starší peer2peer sítě, většina z vás se setkala buď s bittorrentem nebo s kryptoměnami a i pokud ne, tak možná tušíte, o co jde. V principu každý, kdo z těchto sítí čerpá obsah, ho současně může šířit dál. V případě bittorrentu je cílem získat mnoha různými cestami po malých částech přesně identickou kopii existujícího obsahu, např. nasdíleného filmu, a to přesto, že šířka pásma by v případě přímého stahování rozhodně nestačila pro všechny zájemce. V případě kryptoměn je základní princip podobný, ale sdíleným souborem je distribuovaná databáze typu blockchain, kde se kombinuje důraz na to, aby všichni uživatelé disponovali identickou kopií s velmi přísnými pravidly pro přidávání dalších záznamů.

    Tyto dvě technologie, které se objevily po roce 2000, představovaly výrazný odklon od předchozích trendů v decentralizaci.

    Základem raného Internetu byly dodnes existující e-mail a zapomenutý Usenet. Amatérskou paralelou akademického Internetu byla na vytáčeném připojení a modemech postavená síť Fidonet, která nabízela obdobné služby Netmail a Echomail.

    Jak raný Internet, tak Fidonet předpokládaly nepříliš strmou hierarchii, kdy peer2peer povahu měla síť serverů (nodů), ale architektura připojení koncových uživatelů měla spíše charakter klient-server.

    #tipy 1/6

  17. Pro všechny, kdo jsou ve Fediverse obecně a na Mastodonu zvláště noví, nebo kteří to tady zatím neprokoukli:

    Jak řešit "syndrom prázdné timeline"? Tedy to, že nevíte, koho máte followovat, takže se tu zdánlivě "nic neděje"?

    Jistě, můžete se snažit aktivně hledat obsah, který by vás zabavil: ten ale často bude pocházet pouze od různých botů, kteří jen kopírují obsah z jiných sítí nebo přehazují lopatou upoutávky na články v médiích. Můžete také samozřejmě follownout účty, které už mají hodně followerů - to ale není žádná záruka, že budou ty účty pravidelně aktivní, nebo že budou mít zájem s vámi interagovat.

    Lepší mi přijde jít na to z druhé strany.

    Zkuste nejdřív ze všeho nějaký obsah nabídnout sami. Zkuste vkládat jakýkoliv zajímavý obsah, fotky a videa - ať už vlastní, nebo převzaté odjinud. A zkuste obsah opatřit vhodnými hashtagy - ty na Mastodonu hrají opravdu velkou roli.

    A uvidíte, že si vás časem najdou první followeři a vy jim budete moci případně jejich zájem opětovat a followovat je taky. A timeline se vám začne zaplňovat...

    Jděte na to zkrátka z druhé strany: místo abyste se ptali, jak může Mastodon pobavit vás, zkuste se nejdřív zamyslet, čím můžete vy zabavit Mastodon. Je to výměnný obchod - ne jenom pasivní spotřeba obsahu, za který akorát nemusíte platit a nemusíte u toho sledovat hloupé reklamy.

    První týdny to nejspíš bude spíš takový váš soukromý blog - ale v podstatě čím méně budete přemýšlet o tom, jak se přizpůsobit vkusu ostatních, tím spíše si vás najdou právě takoví followeři, kterým se ani nebudete muset přizůsobovat.

    Mastodon není příliš vhodný pro pasivní konzumenty. Jistě, dají se najít způsoby, jak ho použít jako svého druhu RSS čtečku. Ale to není jeho hlavní smysl.

    #tipy

  18. Pro všechny, kdo jsou ve Fediverse obecně a na Mastodonu zvláště noví, nebo kteří to tady zatím neprokoukli:

    Jak řešit "syndrom prázdné timeline"? Tedy to, že nevíte, koho máte followovat, takže se tu zdánlivě "nic neděje"?

    Jistě, můžete se snažit aktivně hledat obsah, který by vás zabavil: ten ale často bude pocházet pouze od různých botů, kteří jen kopírují obsah z jiných sítí nebo přehazují lopatou upoutávky na články v médiích. Můžete také samozřejmě follownout účty, které už mají hodně followerů - to ale není žádná záruka, že budou ty účty pravidelně aktivní, nebo že budou mít zájem s vámi interagovat.

    Lepší mi přijde jít na to z druhé strany.

    Zkuste nejdřív ze všeho nějaký obsah nabídnout sami. Zkuste vkládat jakýkoliv zajímavý obsah, fotky a videa - ať už vlastní, nebo převzaté odjinud. A zkuste obsah opatřit vhodnými hashtagy - ty na Mastodonu hrají opravdu velkou roli.

    A uvidíte, že si vás časem najdou první followeři a vy jim budete moci případně jejich zájem opětovat a followovat je taky. A timeline se vám začne zaplňovat...

    Jděte na to zkrátka z druhé strany: místo abyste se ptali, jak může Mastodon pobavit vás, zkuste se nejdřív zamyslet, čím můžete vy zabavit Mastodon. Je to výměnný obchod - ne jenom pasivní spotřeba obsahu, za který akorát nemusíte platit a nemusíte u toho sledovat hloupé reklamy.

    První týdny to nejspíš bude spíš takový váš soukromý blog - ale v podstatě čím méně budete přemýšlet o tom, jak se přizpůsobit vkusu ostatních, tím spíše si vás najdou právě takoví followeři, kterým se ani nebudete muset přizůsobovat.

    Mastodon není příliš vhodný pro pasivní konzumenty. Jistě, dají se najít způsoby, jak ho použít jako svého druhu RSS čtečku. Ale to není jeho hlavní smysl.

    #tipy

  19. Moderační tip pro provozovatele instancí s otevřenými registracemi: přidat name.ng na seznam blokovaných mailových domén se rozhodně vyplatí...

    #tipy

  20. Moderační tip pro provozovatele instancí s otevřenými registracemi: přidat name.ng na seznam blokovaných mailových domén se rozhodně vyplatí...

    #tipy

  21. ⚠️ Na egyptskom letisku vás môže osloviť „pomocník", ktorý ponúkne vízum za 35 dolárov. Oficiálna prepážka ho vydá za 25 dolárov a za 2 minúty. Ďalší diel z toho, čo väčšina Slovákov zistí až priamo na mieste. hoplo.sk/na-co-si-dat-pozor-v- #egypt #tipy

  22. 🛵 Chcete na Srí Lanke legálne jazdiť na skútri? Nestačí preukaz skupiny B ani AM. Srí Lanka vyžaduje kategóriu A, inak je každá jazda technicky nelegálna. Od augusta 2025 si vodičák overíte aj priamo na letisku. hoplo.sk/pozicanie-skutra-na-s #srilanka #tipy

  23. Někdy se ten největší objev skrývá v té nejmenší a nejméně nápadné stopě. Může to být chybějící příjmení v matrice nebo adresa v zapomenutém sčítacím operátu.
    Nebojte se dnešní hledání začít právě odtud – od zdánlivého detailu. Často vedou k těm nejpřekvapivějším příběhům.
    Přeji úspěšný den všem, kdo píšete nebo objevujete svou rodinnou knihu!

    #Genealogie #Detektivka #Rodokmen #Historie #Pátrání #Tipy #DobréRáno

  24. @Unreed @banterCZ @danielsnor @archos

    Každá instance to má nastavené jinak. Standardně se dá jen zapnout uchování všeho nebo naopak načasované mazání všeho, ale to je nežádoucí a v administraci je to dobré nezapínat!

    Command line utilita tootctl ale umí zajímavější věci, než může admin konfigurovat přes GUI. Jednak maže po určité době statusy účtů, které nikdo nefollowuje a oclitly se v timeline nějakým omylem - přímá zpráva, boost, odpověď, pod. A jednak umí jako nezdokumentovanou funkci to nejzajímavější, tedy mazat i statusy účtů, které někdo followuje, po nějaké časové lhůtě - pokud nedošlo k interakci (boost, fav nebo bookmark).

    Každá instance má asi jinou politiku, některé možná tootctl zatím neznají a nepoužívají. Každopádně u nás na #fcz je tootctl využité tak, že běžné nefollowované statusy bez interakcí se mažou po 90 dnech a folllowované statusy bez interakcí po 400 dnech. Přijde mi důležitější velký výběr od spousty účtů z aktuálního období posledního roku, než nekonečně dlouho uchovávaný obsah od omezeného množství účtů...

    #tipy

  25. @Unreed @banterCZ @danielsnor @archos

    Každá instance to má nastavené jinak. Standardně se dá jen zapnout uchování všeho nebo naopak načasované mazání všeho, ale to je nežádoucí a v administraci je to dobré nezapínat!

    Command line utilita tootctl ale umí zajímavější věci, než může admin konfigurovat přes GUI. Jednak maže po určité době statusy účtů, které nikdo nefollowuje a oclitly se v timeline nějakým omylem - přímá zpráva, boost, odpověď, pod. A jednak umí jako nezdokumentovanou funkci to nejzajímavější, tedy mazat i statusy účtů, které někdo followuje, po nějaké časové lhůtě - pokud nedošlo k interakci (boost, fav nebo bookmark).

    Každá instance má asi jinou politiku, některé možná tootctl zatím neznají a nepoužívají. Každopádně u nás na #fcz je tootctl využité tak, že běžné nefollowované statusy bez interakcí se mažou po 90 dnech a folllowované statusy bez interakcí po 400 dnech. Přijde mi důležitější velký výběr od spousty účtů z aktuálního období posledního roku, než nekonečně dlouho uchovávaný obsah od omezeného množství účtů...

    #tipy

  26. Výsledky budou v sobotu večer, spíš později. V neděli ráno bude už jasno a bude známo všech 200 nových poslanců.

    Kdybyste ještě cokoli potřebovali, třeba podívat se, jak vyplnit hlasovací lístek nebo jak funguje kroužkování, najdete to na Programech. A chybu neuděláte, když web doporučíte kamarádům, kolegům nebo v rodině.

    programydovoleb.cz/

    #volby #volby2025 #politika #spolecnost #tipy

  27. Výsledky budou v sobotu večer, spíš později. V neděli ráno bude už jasno a bude známo všech 200 nových poslanců.

    Kdybyste ještě cokoli potřebovali, třeba podívat se, jak vyplnit hlasovací lístek nebo jak funguje kroužkování, najdete to na Programech. A chybu neuděláte, když web doporučíte kamarádům, kolegům nebo v rodině.

    programydovoleb.cz/

    #volby #volby2025 #politika #spolecnost #tipy

  28. V začátcích českého Mastodonu (ještě než se celý Twitter exodus přesměroval na Bluesky, kde ale ani dnes počet českých uživatelů podle mě nepřekračuje počet uživatelů české Fedi) se šířila fáma, že hvězdičky (favy) tu nemají žádný význam (kromě "vzkazu autorovi") a že smysl má jen "boost nebo nic". To vycházelo z poměrně chybné úvahy, že jediným smyslem interakce s obsahem je zvýšení dosahu a že když "algoritmus" hvězdičky nezohledňuje (ve skutečnosti zohledňuje, ale ví jen o těch lokálních), tak je zbytečné je rozdávat.

    Minimálně u nás na instanci #fcz, ale podle mě brzy i na všech instancích s jakkoliv trochu vyšším provozem, bude ale brzy platit, že pokud chcete, aby byl nějaký obsah na instanci cacheován "na věčné časy", tak byste měli interagovat alespoň favem.

    Je to z toho důvodu, že žádná instance si časem nebude moci dovolit archivovat cache federované timeline navěky. A utilita tootctl, která je součástí backendu Mastodonu, nakonec u starších statusů zohledňuje i to, jestli s nimi někdo lokální interagoval. A přesně tady dává favování (rozdávání hvězdiček) najednou smysl.

    Takže: pokud se vám líbí něco, s čím třeba nepotřebujete přímo obšťasťnovat svoje followery, ale chcete, aby to na instanci šlo najít i v budoucnu, tak nezapomínejte favovat! A to i v případě, že jde o strojový feed, jehož "autor" hvězdičky nikdy řešit nebude. Favovaný obsah prostě evolučně ve Fediverse přežije - ignorovaný obsah časem zmizí z místní cache vaší instance (a pokud to admin nezařídí, tak časem hrozí zánik celé instance vlastní vahou...)

    #tipy

  29. V začátcích českého Mastodonu (ještě než se celý Twitter exodus přesměroval na Bluesky, kde ale ani dnes počet českých uživatelů podle mě nepřekračuje počet uživatelů české Fedi) se šířila fáma, že hvězdičky (favy) tu nemají žádný význam (kromě "vzkazu autorovi") a že smysl má jen "boost nebo nic". To vycházelo z poměrně chybné úvahy, že jediným smyslem interakce s obsahem je zvýšení dosahu a že když "algoritmus" hvězdičky nezohledňuje (ve skutečnosti zohledňuje, ale ví jen o těch lokálních), tak je zbytečné je rozdávat.

    Minimálně u nás na instanci #fcz, ale podle mě brzy i na všech instancích s jakkoliv trochu vyšším provozem, bude ale brzy platit, že pokud chcete, aby byl nějaký obsah na instanci cacheován "na věčné časy", tak byste měli interagovat alespoň favem.

    Je to z toho důvodu, že žádná instance si časem nebude moci dovolit archivovat cache federované timeline navěky. A utilita tootctl, která je součástí backendu Mastodonu, nakonec u starších statusů zohledňuje i to, jestli s nimi někdo lokální interagoval. A přesně tady dává favování (rozdávání hvězdiček) najednou smysl.

    Takže: pokud se vám líbí něco, s čím třeba nepotřebujete přímo obšťasťnovat svoje followery, ale chcete, aby to na instanci šlo najít i v budoucnu, tak nezapomínejte favovat! A to i v případě, že jde o strojový feed, jehož "autor" hvězdičky nikdy řešit nebude. Favovaný obsah prostě evolučně ve Fediverse přežije - ignorovaný obsah časem zmizí z místní cache vaší instance (a pokud to admin nezařídí, tak časem hrozí zánik celé instance vlastní vahou...)

    #tipy

  30. Objevil jsem, že požadované vymazání starých cacheovaných nelokálních statusů i v případě, že daný účet někdo followuje, ale nikdo lokální ho nefavoval ani neboostoval, by mohla zvládnout CLI utilita tootctl s parametrem "statuses remove --clean_followed". Ještě se poradím s uživateli instance, ale pravděpodobně se do toho pustím.

    Databáze není nafukovací a i když by šlo o něco zvětšit místo na disku i RAM, tak stejně ten nekontrolovatelný nárůst velikosti někdy v budoucnu narazí na nějaký strop. A přesně tohle je chování, které jsem požadoval, ale nevěděl, jak ho dosáhnout.

    Mám pocit, že problémy s velikostí databáze, do kterých se údajně dostal astrodon.social, by bývalo šlo řešit přesně takhle (mohlo by zajímat @[email protected] @[email protected] ... možná by ten tip mohl dát adminovi astrodonu...)

    #mastodon #tipy

  31. Objevil jsem, že požadované vymazání starých cacheovaných nelokálních statusů i v případě, že daný účet někdo followuje, ale nikdo lokální ho nefavoval ani neboostoval, by mohla zvládnout CLI utilita tootctl s parametrem "statuses remove --clean_followed". Ještě se poradím s uživateli instance, ale pravděpodobně se do toho pustím.

    Databáze není nafukovací a i když by šlo o něco zvětšit místo na disku i RAM, tak stejně ten nekontrolovatelný nárůst velikosti někdy v budoucnu narazí na nějaký strop. A přesně tohle je chování, které jsem požadoval, ale nevěděl, jak ho dosáhnout.

    Mám pocit, že problémy s velikostí databáze, do kterých se údajně dostal astrodon.social, by bývalo šlo řešit přesně takhle (mohlo by zajímat @[email protected] @[email protected] ... možná by ten tip mohl dát adminovi astrodonu...)

    #mastodon #tipy

  32. Provedl jsem na naší instance #fcz drakonickou čistku federované cache pokud jde o statusy starší 90 dnů, pocházející od účtů, které u nás nikdo nefollowuje a se kterými u nás nikdo neinteragoval. Překvapilo mi, jak obrovské množství dat to zasáhlo, ale pravděpodobně u nás něco pořád strašilo z časů těch úplných začátků (občas jsem se divil, co všechno u nás lze najít..). Pokud by vám tu něco zásadního chybělo, rozhodně mi to nahlašte, ať příště chybu neopakujeme!

    Na druhou stranu, životnost statusů od účtů, které fakt followujete, by nyní měla být 2 roky (a pokud to půjde dobře, ještě tohle číslo zvednu nebo limit zruším) a životnost mediální cache jsem zvýšil ze dvou týdnů na čtyři.

    Velikost zálohy databáze narostla za posledních 14 dnů o 2 GB (ovšem to znamená ze 12 GB na 14 GB), což mi přišlo nepřiměřené... tak uvidíme, co se stane teď. Každopádně původní statusy jsou pořád dohledatelné na svých původních instancích, ale naše instance musí především operativně fungovat hlavně pro stávající followované účty stávajících aktivních uživatelů.

    Co se týče vašich místních statusů, zkontrolujte položku menu ⚙️Předvolby a ujistěte se, že máte vypnuté mazání svých vlastních starých příspěvků! (ano, mluvím hlavně o fotografech, jako jsou @cobic, @Cyclingnomads, @plactagonic, @janasisu, @mahajana a další!)

    Ano, není to tady zas až tak úplně jednoduché na používání... ale věřím, že ten pocit, že váš obsah nevlastní nikdo velký a mocný, vám bude stát za to.

    #tipy

  33. Místní uživatel @tom sepsal na #nyxcz do našeho Mastodon/Fediverse klubu výborné #tipy pro začátečníky. Doufám pobaví 🙂

    nyx.cz/discussion/279037/id/57

  34. Místní uživatel @tom sepsal na #nyxcz do našeho Mastodon/Fediverse klubu výborné #tipy pro začátečníky. Doufám pobaví 🙂

    nyx.cz/discussion/279037/id/57

  35. Tak jsem konečně byl nasměrován, kde jde najít seznam hashtagů, který followujete. Musíte na svůj vlastní profil (ne Domů, ale vaše ikonka vlevo ve webovém UI) a tam rozkliknout to menu pod třema tečkama. Intuitivní UX to teda není vůbec (je to jediná položka toho menu, která není zrcadlená v tom top level menu napravo od zobrazené timeline)... ale implementované to přeci jenom je...

    #tipy

  36. Doba uchovávání vzdáleného obsahu #tipy #fcz

    Cituji "Všechny příspěvky z jiných serverů (včetně boostů a odpovědí) budou po uplynutí stanoveného počtu dní smazány bez ohledu na interakci místního uživatele s těmito příspěvky. To se týká i příspěvků, které místní uživatel přidal do záložek nebo oblíbených. Soukromé zmínky mezi uživateli z různých instancí budou rovněž ztraceny a nebude možné je obnovit. Použití tohoto nastavení je určeno pro instance pro speciální účely a při implementaci pro obecné použití porušuje mnohá očekávání uživatelů."

    Zvýšil jsem hodnotu z půl roku na 730 dnů a uvidíme. Velikost (nekomprimované) zálohy databáze zatím i tak narůstala asi o 1 GB za měsíc. Teď očekávám zčtyřnásobení. Osobně bych preferoval kratší uchování obsahu, ale garanci uložení toho, co někdo z instance favnul, boostnul, nebo zabookmarkoval (dává to dobrý smysl, byl by to jen zlomek federované timeine)

    Lhůta cacheování mediálních příloh z jiných instancí zůstává nastavena na 14 dnů - tam není problém opakované načtení z původní instance.

  37. Doba uchovávání vzdáleného obsahu #tipy #fcz

    Cituji "Všechny příspěvky z jiných serverů (včetně boostů a odpovědí) budou po uplynutí stanoveného počtu dní smazány bez ohledu na interakci místního uživatele s těmito příspěvky. To se týká i příspěvků, které místní uživatel přidal do záložek nebo oblíbených. Soukromé zmínky mezi uživateli z různých instancí budou rovněž ztraceny a nebude možné je obnovit. Použití tohoto nastavení je určeno pro instance pro speciální účely a při implementaci pro obecné použití porušuje mnohá očekávání uživatelů."

    Zvýšil jsem hodnotu z půl roku na 730 dnů a uvidíme. Velikost (nekomprimované) zálohy databáze zatím i tak narůstala asi o 1 GB za měsíc. Teď očekávám zčtyřnásobení. Osobně bych preferoval kratší uchování obsahu, ale garanci uložení toho, co někdo z instance favnul, boostnul, nebo zabookmarkoval (dává to dobrý smysl, byl by to jen zlomek federované timeine)

    Lhůta cacheování mediálních příloh z jiných instancí zůstává nastavena na 14 dnů - tam není problém opakované načtení z původní instance.

  38. @wvi já používám spíš #tipy
    @danielsnor

    Ale není to úplně pravda, algoritmus Objevit máme, ale dost hloupý. A taky máme bota @trending kterého doporučuju follownout...

  39. Když se vám tady něco líbí zkuste ne jen lajkovat, ale i boostovat. Tady nemáme algoritmus, tady to stojí na levné lidské práci ;)
    #tip_mastodon #tipy

  40. Chcete vidět pouze příspěvky bez boostů, ať už svoje nebo někoho jiného? Napište do okna vyhledávače např.:

    "from:@xChaos"

    a přepněte se ve výsledcích na záložku "Příspěvky".

    (to, aby se to chovalo přesně jak popisuju, vyžaduje aktivaci Elastic search, jako to máme např. na instanci #fcz - bohužel, zatím nejde přes API zjistit, které instance to mají aktivní, na rozdíl od třeba DeepL překladů)

    #tipy

  41. Pro nově příchozí je dobré čas od času zopakovat některé #tipy, jak chápat svoji přítomnost na Mastodonu:

    - není tu žádný algoritmus, vůbec žádný. Vaše příšpěvky ručně přepisují na psacích strojích sektretářky najaté provozovateli instancí. Občas se používá i OCR a AI na přepis mluveného slova.

    - Mastodon nepatří miliardářům, ale bezdomovcům. Normálně se instance zakládá tak, že vyšlete bezdomovce na sběrný dvůr nasbírat nějaký vyřazený hardware. Současně prohlásíte, že jim ten hardware patří, kvůli ochraně před GDPR. Mastodon je tak složitá aplikace na administrování, že ji zásadně necháte spravovat někoho jiného. Zodpovědní admini toto bezpečnostní dilema řeší tak, že instance neaktualizují vůbec.

    - používat Mastodon je nesrozumitelně složité. Především musíte mít chytrý telefon a na něj nainstalovat hloupou aplikaci, která se jmenuje jinak, než Mastodon. Dále musíte mít účet, který si vytvoříte ve webovém prohlížeči, což se naposledy používalo v éře vlaků, tažených parními lokomotivami. Nakonec musíte do appky napsat náhodné bláboly a zmáčknout "Tootnout", což je zase nepřekonatelná překážka pro introverty.

    - Mastodon vůbec nefunguje! Pokud vidíte odpovědi na svoje statusy, tak se vám to jen zdá. Nikdy nevidíte všechny odpovědi - počet odpovědí o kterých nevíte, tedy narůstá exponenciálně. S čím větší přesností znáte počet odpovědí na svůj status, tím méně vám zbývá času na to, si ty odpovědi přečíst. Navíc v řadě statusů se ukrývají fotky koček (i když jejich počet v čase klesá...)

    - Mastodon nemá žádné uživatele. Pokud někdo váš status boostuje nebo favuje, tak jen předstírá, že je uživatel. Divní autisté na Mastodonu pouze předstírají, že jsou uživatelé, ve snaze vytvořit honeypot na lov trollů (trollové se loví do kbelíčků, jejichž vnitřní stěny jsou namazané sádlem, což je mimochodem přiléhavá metafora pro celý ekosystém Fediverse).

  42. Pro nově příchozí je dobré čas od času zopakovat některé #tipy, jak chápat svoji přítomnost na Mastodonu:

    - není tu žádný algoritmus, vůbec žádný. Vaše příšpěvky ručně přepisují na psacích strojích sektretářky najaté provozovateli instancí. Občas se používá i OCR a AI na přepis mluveného slova.

    - Mastodon nepatří miliardářům, ale bezdomovcům. Normálně se instance zakládá tak, že vyšlete bezdomovce na sběrný dvůr nasbírat nějaký vyřazený hardware. Současně prohlásíte, že jim ten hardware patří, kvůli ochraně před GDPR. Mastodon je tak složitá aplikace na administrování, že ji zásadně necháte spravovat někoho jiného. Zodpovědní admini toto bezpečnostní dilema řeší tak, že instance neaktualizují vůbec.

    - používat Mastodon je nesrozumitelně složité. Především musíte mít chytrý telefon a na něj nainstalovat hloupou aplikaci, která se jmenuje jinak, než Mastodon. Dále musíte mít účet, který si vytvoříte ve webovém prohlížeči, což se naposledy používalo v éře vlaků, tažených parními lokomotivami. Nakonec musíte do appky napsat náhodné bláboly a zmáčknout "Tootnout", což je zase nepřekonatelná překážka pro introverty.

    - Mastodon vůbec nefunguje! Pokud vidíte odpovědi na svoje statusy, tak se vám to jen zdá. Nikdy nevidíte všechny odpovědi - počet odpovědí o kterých nevíte, tedy narůstá exponenciálně. S čím větší přesností znáte počet odpovědí na svůj status, tím méně vám zbývá času na to, si ty odpovědi přečíst. Navíc v řadě statusů se ukrývají fotky koček (i když jejich počet v čase klesá...)

    - Mastodon nemá žádné uživatele. Pokud někdo váš status boostuje nebo favuje, tak jen předstírá, že je uživatel. Divní autisté na Mastodonu pouze předstírají, že jsou uživatelé, ve snaze vytvořit honeypot na lov trollů (trollové se loví do kbelíčků, jejichž vnitřní stěny jsou namazané sádlem, což je mimochodem přiléhavá metafora pro celý ekosystém Fediverse).

  43. Mimochodem, dost se mi zatím osvědčil účet @trending (resp. dát si na něj "zvoneček"). Občas odchytí i hashtagy, kterých si nestihnu všimnout v záložce Objevit...

    #hashtags #trending #mastodon #tipy

  44. Mimochodem, dost se mi zatím osvědčil účet @trending (resp. dát si na něj "zvoneček"). Občas odchytí i hashtagy, kterých si nestihnu všimnout v záložce Objevit...

    #hashtags #trending #mastodon #tipy

  45. Przypisywanie funkcji Centrum sterowania do przycisku akcji w iPhonie jest obecnie niemożliwe, ale zmieni się to wraz z premierą iOS 18.1, pod koniec tego miesiąca.
    Wprowadzony w modelach iPhone 15 Pro i obecne we wszystkich iPhone’ach 16, przycisk akcji daje możliwość dostosowania jego funkcji. W iOS 18 Apple dodało opcję przypisywania funkcji z Centrum sterowania, co może zwiększyć jego użyteczność i na co czekałem od samego początku!

    Choć użytkowanie przycisku było dotychczas mieszane, nowe funkcje mogą poprawić jego odbiór. Teraz można szybko uzyskać dostęp do takich opcji jak Tryb ciemny, Tryb samolotowy, Dane komórkowe czy Notatka.

    Jak przypisać akcję z Centrum sterowania pod przycisk akcji?

    Aby przypisać wybraną kontrolkę z nowego Centrum sterowania pod przycisk akcji, wybieramy w Ustawieniach > Przycisk czynności > a następnie Narzędzia.


    Jak przypisać wywołanie Centrum sterowania pod przycisk akcji?

    Aby natomiast przypisać wywołanie całego Centrum sterowania pod przycisk akcji, najpierw musimy udać się do > Skrótów.

    Tam utworzyć nowy skrót > dalej w wyszukiwarce czynności wpisać „Centrum sterowania” i wybrać „Pokaż centrum sterowania”.


    Aby przypisać ten nowy skrót pod przycisk akcji, wybieramy w Ustawieniach > Przycisk czynności > a następnie Skrót > i wskazujemy go w tym miejscu.

    Gotowe!

    https://imagazine.pl/2024/10/07/ios-18-1-umozliwi-przypisywanie-funkcji-centrum-sterowania-do-przycisku-akcji/

    #CentrumSterowania #iOS181 #przyciskAkcji #przyciskCzynności #skróty #tipsAndTricks #tipy

  46. Návod, jak followovat uživatele Fediverse, pokud máte účet na #Bluesky (a současně umožnit být followováni z fediverse/Activity pub):

    1) followněte svým Bluesky účtem účet @ap.brid.gy ("ap" jako ActivityPub)
    2) followněte Fediverse adresu ve tvaru @username.domena.ap.brid.gy (např. já jsem zpřístupněný jako @xchaos.f.cz.ap.brid.gy)

    Pozor, Bluesky ovšem zobrazí pouze prvních 300 znaků příspěvku! Hodí se to tedy spíš na fotky...

    Návod, jak to udělat v obráceném gardu:

    1) followněte svým Fediverse (ActivityPub, nečastěji samozřejmě Mastodon) účtem účet @bsky.brid.gy
    2) followněte Bluesky účet ve tvaru @[email protected]

    Pozor, jak followovaný, tak followující musí nejprve follownout ten bridge účet (ten follow okamžitě oplatí a díky tomu to celé funguje)

    #tipy

  47. Návod, jak followovat uživatele Fediverse, pokud máte účet na #Bluesky (a současně umožnit být followováni z fediverse/Activity pub):

    1) followněte svým Bluesky účtem účet @ap.brid.gy ("ap" jako ActivityPub)
    2) followněte Fediverse adresu ve tvaru @username.domena.ap.brid.gy (např. já jsem zpřístupněný jako @xchaos.f.cz.ap.brid.gy)

    Pozor, Bluesky ovšem zobrazí pouze prvních 300 znaků příspěvku! Hodí se to tedy spíš na fotky...

    Návod, jak to udělat v obráceném gardu:

    1) followněte svým Fediverse (ActivityPub, nečastěji samozřejmě Mastodon) účtem účet @bsky.brid.gy
    2) followněte Bluesky účet ve tvaru @[email protected]

    Pozor, jak followovaný, tak followující musí nejprve follownout ten bridge účet (ten follow okamžitě oplatí a díky tomu to celé funguje)

    #tipy

  48. Boostování příspěvků z vaší mini-instance paralelním účtem na mastodon.social? Takhle spamujeme my slušňáci :-) :masto_wink: :mastoinnocent:

    #tipy

  49. Díky @ptesarik můžeme krásně deštivý pondělní home office zahájit opravou včerejšího chybného návodu. (Bavíme se o české klávesnici pod Linuxem, ostatní platformy na vlastí nebezpečí):

    "Číselný dolní index se dá udělat prostě jako ˇ (mrtvá klávesa háček) a číslovka"

    CO₂

    "Číselný horní index se dá udělat jako ^ (mrtvá klávesa circumflex) a číslovka, ale circumflex na české klávesnici se děla trochu krkolomně: pravý Alt + Shift + 3"

    i² = -1

    U obou operací samozřejmě držíme shift celou dobu (na české klávesnici jsou čísla se shiftem).

    Děkuji všem, kdo se do včerejší debaty zapojili se svými vlastními originálními návody, jak se podrbat levou nohou za pravým uchem! Bohužel všem "normálním" :masto_wink: spolusloníkům jsme tím dokázali, že jsme beznadějné hnízdo nerdů, ale co naděláme...

    #tipy #x11 #linux #czech #unicode

  50. Nebaví vás googlit unicode znaky pro subscript a superscript? Mě už taky ne :-)

    Akordy pro psaní horního a dolního indexu (ve smyslu Unicode) na klávesnici Windows se dají snadno vygooglit. Pod Linuxem je to ovšem trochu věda:

    1) nejdřív Pravý alt + pravý shift + backspace + 2 (ano, čtyřhmat)
    2) potom znak, který má být dolní index, třeba číslovka (což ovšem na české klávesnici, na kterou jste přepnutí, taky s shiftem, takže dvouhmat).

    H₂O

    Pro horní index ve stejném čtyřhmatu akorát nahradíte tu dvojku trojkou:

    a² + b² = c²

    Slušné akordy, ne? problém je, že pokud čtyřhmat nedomáčknete přesně (?) tak ten Backspace má tendenci fungovat jako backspace, takže umaže jeden znak... no zkrátka, dělám to pokaždé na několikátý pokus, zatím :-)

    Vůbec jsem nepochopil návod
    abclinuxu.cz/blog/kenyho_stesk
    ... asi proto, že nevím, která PC klávesa je "compose key", ale v komentářích čtenářů jsem si všiml návodu pro slovenskou klávesnici a funguje mi i pro český layout a tak to předávám dál.

    #tipy #x11 #linux #czech #unicode

  51. Feel free to join my "Let's follow at least one account from every tiny irrelevant instance around here" movement ;-)

    Together, we are strong. When you prefere to create your account on of big instances with huge number of users, your voice is likely to get lost in the noise.

    #fediverse #tipy

  52. If you are seeing more Czech language post from me recently, it may be related to the fact, that I have now more confidence in integration of #DeepL translator into #Mastodon. Yes, it has #shareware business model, but at least it is not Google...

    For admins, it is just very straightforward to install it. For users, it mostly works. Unfortunately, in multi-language conversations, people often forget to change the language, because the language of each message is inherited from the previous post in the thread, not auto-detected, which may be solved in the future versions of some client apps.

    The initial 500 000 characters limit is free and this allows for funny workarounds. As your instance usually has more than one active user, with more than one credit card, the "business model" for asking your users to support your instance is pretty obvious - they can contribute more free API tokens 😃 (The crypto people are not the only crowd capable of designing Ponzi schemes, obviously :mastoinnocent: )

    #tipy