A Nitter nyilvános példányai közül az utolsó tönkrement. A Nitter projekt egy nyílt forráskódú frontendet fejlesztett az X.com/Twitter elérésére, anélkül, hogy JavaScriptet, elemzőeszközöket, nyomkövetőket és külső szolgáltatásokat használt volna. Január 31-én leállították a tokenek kiadását, amelyeket a Nitter használt a tartalomhoz való hozzáférés megszervezéséhez az X.com-on. Február 26-án lejárt az utolsó kiadott tokenek élettartama, ami a Nitter működésének teljes leállításához vezetett.
Elon Musk vásárlása után a Twitter (most X néven) technikai és szervezeti intézkedések komplex sorozataként kezdte el a platform agresszív monetizálását, amely korábban veszteségesnek számított. A változások között szerepelt az információdíjazás megvalósítása, ahol különböző típusú fiókok számára korlátok lettek bevezetve (10000 a fizetős "kék pipa" tulajdonosok számára, 1000 a normál fiókoknak, 500 az új normál fiókoknak); a "fejlesztői" fiókokat fizetős kategóriába sorolták át, korlátokkal, amelyek megfelelőek az adatok tömeges kiaknázásához (scraping); a fiókkal nem rendelkező felhasználóknak szánt információk szolgáltatását leállították.
A nyilvános indoklásban (2023-07-01) azt állították, hogy ez "ideiglenes sürgősségi intézkedések", amelyek kapcsolódnak ahhoz, hogy az automatizált adatrögzítés botokkal rontja a szolgáltatást a normál felhasználók számára. Ezt megelőzően (2023-04-19) insinuációk merültek fel a Microsoft ellen, miszerint a cég illegálisan használja a Twitter adatait az AI képzésére. Később (2023-11-17) a limit bevezetését Musk által ígért botokkal folytatott harccal indokolták.
A Nitter egy olyan szoftverfejlesztési projekt volt, amely a Twitter felhasználók adatainak megfigyelésétől való megóvására szolgált, akik nem küldenek üzeneteket, hanem csak olvasnak információkat, egy alternatív oldal biztosításával a Twitter megtekintéséhez, amelyhez sem fiók, sem JavaScript bekapcsolása nem szükséges. Ez a szoftver gyakorlatilag scraper és közvetítő, amely ahelyett, hogy az adatokat adatbázisba mentené, a végfelhasználónak továbbítja azokat (azonban néhány ügynökségi adat a Redisben tárolásra kerül).
Így a Nitter szoftver:
A kiskapuk elemzése nyomán, amelyek lehetővé tették a működés folytatását új környezetben, RSS és néhány belépési pont került felfedezésre a syndication.twitter.com-on, amelyek JSON formátumban visszajeleztek információkat nem regisztrált felhasználóknak, és más közösségi médiákkal való integrációra használták. Néhány ideig a Nitter ezeken az interfészeken keresztül szerzett információt, de később ezeket is leállították. Ezt követően felfedezésre került a 'vendégfiókok' használatának módja, amelyek olvasási jogosultságokkal rendelkeztek. A 'vendégfiókok' egyik fajtája az internetes eszközökön használt, korlátozott böngészővel rendelkező eszközök számára készült.
De a Nitter egy másik típusú 'vendégfiókot' használt, amely OAuth-ot alkalmazott sütik helyett, API-n keresztül regisztrált, és láthatóan az Android alkalmazás használta. Ennek a fióktípusnak 500 API kérésre van korlátja 15 perc alatt, és a 'regisztrációja' kapcsolódik IP-cím alapján határozza meg a helyet (egy IP címről egy 'vendégfiókot' lehet regisztrálni 24 órán belül, de a már regisztrált 'fiók' más IP címekből is használható).
Az ilyen 'fiókok' (hozzáférési tokenek) 30 napig működtek. Abban az időben megfelelő megoldás lehetett a tömeges ideiglenes fiókok regisztrálásának problémájára, ha a felhasználók közösségi finanszírozással regisztrálták volna őket, valami hasonlóval, mint a Bibliogram (felhasználói script, amely megkapja a vendég tokent a felhasználótól és továbbítja egy nyilvános példányhoz).
Január végén az X leállította az ilyen tokenek kiadását. Az utolsó hozzáférési mód megszüntetése véget vetett a Nitter nyilvános, ingyenes, többfelhasználós szolgáltatásának, aminek következtében a szerző bejelentette, hogy a Nitter halott.
Néhány példány azonnal leállt, mások a meglévő tokenek felhasználásának szigorú takarékossága érdekében módosították a kódot, különös figyelmet fordítva a tweetlisták megszerzésére, míg minden egyéb esetben hibás üzeneteket adtak ki. Február 26-án az utolsó vendégtokenek élettartama lejárt, aminek következtében minden nyilvános példány működése leállt. Ennek ellenére a hibakövető rendszerben a vendégfiókokkal kapcsolatos megoldásokat vitatják.
A problémának egy radikális megoldása lehetne a Twitter alternatív decentralizált szolgáltatásának létrehozása ActivityPub és IPFS alapjain, ahol minden üzenet fő azonosítója az IPFS CID-je. Képzeljünk el egy többrétegű struktúrát:
A 3. pont adatai azonban nem oldják meg a Twitter felhasználók részvételének hiányát a Twitter alternatívájának programjában.
Minden központosított platformon lévő poszt azonosítója esetében célszerű lehet az IPFS CID-jük megjelenítésének támogatása, amely gyorsítótárként működik, lehetővé téve, hogy a poszt szövegének ismerete nélkül, de az azonosított központosított azonosító ismeretében megtudható legyen a decentralizált azonosítója. Az IPFS URI generálásakor (ami tényleges feltöltés nélkül is elvégezhető) a poszt szövege kanonizáción megy keresztül, ez az adatok HTML-alapú konténerbe való elhelyezésével történik gépileg olvasható metaadatokkal, Unicode normalizálásával, UTF-8-ba konvertálásával, a szóközök egyszerű egyes szóközökre cserélésével, és minden hivatkozás a posztokra, ezen és más platformokon, amelyek hasonló eljárásnak vannak alávetve, URI-kra az IPFS-en.
Minden platform rendelkezik géppel olvasható dokumentummal, amely leírja a posztok kanonizálási szabályait, beleértve számos szolgáltatást, amelyek linkjei IPFS URI-ra cserélődnek a hálózat posztjaiban. Minden poszt minden hálózatban a saját kanonizálási szabályai szerint kanonizálódik, amely a poszt időpontjával érvényes. A kanonizálás során, ha a posztban van hivatkozás egy helyettesítő platform posztjára, a megvalósítás kiemeli a központosított azonosítót a linkből és ellenőrzi annak jelenlétét a megbízható indexekben.
Index létezése esetén a megvalósítás az indexekből származó decentralizált azonosítót használja. Ha hiányzik, a megvalósítás kéri a posztot a linken, kanonizálja azt, és létrehoz egy azonosítót, amelyet be lehet helyezni az indexekbe. A megvalósításnak nem kötelező beilleszteni a kért posztot a decentralizált hálózatba. A megvalósítás ellenőrizheti az azonosító helyességét az indexben a folyamat helyi reprodukálásával. Az index megvalósításának ellenőriznie kell az azonosítók generálásának helyességét a folyamat helyi reprodukálásával.
Ez a determinisztikus folyamat lehetővé teszi, hogy megváltoztathatatlan linkeket generáljon a tartalomra, még azokhoz a tweetekhez is, amelyek posztolói még nem vesznek részt a twitterhelyettesítési programban. Amikor ezek közül egyesek feltöltik tweetjeiket az IPFS-re, az algoritmus azonosítókat generál számukra, amelyek megegyeznek a már használt linkek azonosítóival, feltéve, hogy az index helyes leképezéseket tartalmaz, és magának a tartalomnak nem változott meg.
Forrás: opennet.ru
