Poslední veřejný instance Nitter přestala fungovat. Projekt Nitter vyvíjel svobodný front-end pro přístup k X.com/Twitter bez vnucování JavaScriptu, analytiky, trackerů a třetích stran. 31. ledna byla zastavena distribuce tokenů používaných v Nitter pro organizaci přístupu k obsahu na X.com. 26. února vypršela doba platnosti posledních dříve vydaných tokenů, což vedlo k úplnému zastavení chodu Nitter.
Po koupi Elonem Muskem začal Twitter (nyní přejmenovaný na X) zavádět komplex technických a organizačních opatření zaměřených na agresivní monetizaci platformy, která byla dříve považována za ztrátovou. Mezi změnami byla realizována tariface informací získaných každým účtem (byly zavedeny limity pro různé typy účtů — 10 000 pro držitele placené "modré značky", 1 000 pro běžné a 500 pro nové běžné); účty "vývojářů" byly převedeny na placené s limity vhodnými pro masové získávání dat (scraping); byla zastavena distribuce informací uživatelům bez účtů.
Jako omluva bylo veřejně tvrzeno (2023-07-01), že se jedná o "dočasná nouzová opatření", související s tím, že automatizované načítání dat boty zhoršuje službu pro běžné uživatele. Předtím (2023-04-19) byly insinuace vůči Microsoftu, že tato společnost nelegálně využívá data Twitteru k trénování AI. Později (2023-11-17) bylo zavedení limitů odůvodněno slibovaným Muskovým bojem proti botům.
Nitter byl projektem na vývoj softwaru pro ochranu uživatelů Twitteru před sledováním, kteří neposílají zprávy, ale pouze čtou materiály, tím, že jim poskytuje alternativní web pro prohlížení Twitteru, který nevyžaduje ani účet, ani zapnutý JavaScript. Takový software je vlastně scraper a prostředník, který místo ukládání dat do databáze je zasílá koncovému uživateli (nicméně některá provozní data jsou cachována v Redis).
Takže software Nitter:
V důsledku analýzy alternativních cest pro pokračování v činnosti v nových podmínkách byly objeveny RSS a některé vstupní body na syndication.twitter.com, které poskytovaly informace nezaregistrovaným uživatelům ve formátu JSON a byly použity pro integraci s jinými sociálními sítěmi. Po určitou dobu Nitter získával informace prostřednictvím těchto rozhraní, ale ty byly nakonec uzavřeny. Poté byl nalezen způsob využití 'hostitelských účtů', které měly privilegium čtení. Jeden typ těchto 'hostitelských účtů' byl určen pro použití na zařízeních internetu věcí s omezenými prohlížeči.
Ale Nitter používal jiný typ 'hostitelských účtů', které používaly OAuth místo Cookies, registrovaly se prostřednictvím API a zjevně je používala aplikace pro Android. Tento typ účtů má limity 500 požadavků na API během 15 minut a jejich 'registrace' je vázána na IP adresu (z jedné IP adresy je možné zaregistrovat jeden 'hostitelský účet' za den, ale již registrovaný 'účet' lze používat z jiných IP adres).
Takové 'účty' (přístupové tokeny) byly funkční po dobu 30 dnů. V daném okamžiku by adekvátním řešením problému masové registrace dočasných účtů mohlo být crowdsourcingové registrování uživateli, pomocí něčeho podobného jako Bibliogram (uživatelský skript, který bere hostitelský token od uživatele a předává ho veřejné instanci).
Na konci ledna X přestal vydávat takové tokeny. Odstranění posledního způsobu přístupu znamenalo konec Nitter jako veřejné bezplatné multiplatformní služby, přičemž autor prohlásil Nitter za mrtvého.
Některé instance se po této změně okamžitě uzavřely, jiné upravily kód pro drastické šetření stávajícími tokeny, zejména s důrazem na jejich využívání pro získávání seznamů tweetů z účtů, přičemž pro vše ostatní se objevovaly chybová hlášení. Dne 26. února vypršela životnost posledních hostujících tokenů, což vedlo k tomu, že všechny veřejné instance přestaly fungovat. Nicméně se na chybovém trackeru diskutují způsoby, jakým způsobem by se dalo nějakým způsobem zacházet s hostujícími účty.
Jedním z radikálních řešení problému by mohlo být nahradit Twitter vytvořením alternativního decentralizovaného servisu na bázi ActivityPub a IPFS, kde hlavním identifikátorem každé zprávy je její IPFS CID. Lze si představit následující víceúrovňovou konstrukci:
Data z bodu 3 však neřeší problém neúčasti uživatelů Twitteru v programu nahrazování Twitteru.
Pro každý identifikátor příspěvku na každé centralizované platformě by mohlo být smysluplné udržovat zobrazení jeho IPFS CID, které funguje jako mezipaměť, umožňující bez znalosti samotného textu příspěvku, ale při znalosti jeho centralizovaného identifikátoru, zjistit jeho decentralizovaný identifikátor. Při generaci URI v IPFS (což může být provedeno bez skutečného nahrávání) text příspěvku podléhá kanonizaci, která zahrnuje umístění dat do kontejneru na základě HTML s strojově čitelnými metadaty, normalizaci unicode, konverzi do UTF-8, nahrazení bílých znaků jednoduchými jednotlivými mezerami a nahrazení všech odkazů na příspěvky v této a jiných platformách, podléhající podobné proceduře, na URI v IPFS.
Každá platforma má strojově čitelný dokument, který popisuje pravidla kanonikalizace příspěvků, včetně mnoha služeb, jejichž odkazy jsou nahrazeny URI IPFS v příspěvcích této sítě. Každý příspěvek v každé síti je kanonikalizován podle pravidel kanonikalizace příspěvků, které platí v době, kdy je příspěvek datován. Při kanonikalizaci, pokud příspěvek obsahuje odkaz na příspěvek v jedné z nahrazovaných platforem, implementace extrahuje z odkazu centralizovaný identifikátor a kontroluje jeho přítomnost v důvěryhodných indexech.
Pokud je v indexu, implementace používá decentralizovaný identifikátor z indexů. V případě jeho nepřítomnosti implementace požaduje příspěvek podle odkazu, kanonikalizuje ho a vytváří identifikátor, který může umístit do indexů. Implementace není povinna umístit požadovaný příspěvek do decentralizované sítě. Implementace může ověřit správnost identifikátoru v indexu lokálním reprodukováním procesu. Implementace indexu je povinna zkontrolovat správnost generování identifikátorů lokálním reprodukováním procesu.
Takový deterministický proces umožní generovat neměnné odkazy na obsah i pro tweety, jejichž příspěvky zatím nejsou součástí programu tweetrování. Když část z nich začne nahrávat své tweety do IPFS, algoritmus pro ně vygeneruje identifikátory, identické těm, které jsou již použity v odkazech na ně, za podmínky, že index obsahuje správné zobrazení a samotný obsah se nezměnil.
Zdroj: opennet.ru
