Den sista offentliga instansen av Nitter har blivit obrukbar. Projektet Nitter utvecklade en fri frontend för att fÄ tillgÄng till X.com/Twitter utan att anvÀnda JavaScript, analysverktyg, tracker och tredjepartstjÀnster. Den 31 januari avslutades utdelningen av tokens som anvÀndes i Nitter för att organisera tillgÄng till innehÄll pÄ X.com. Den 26 februari löpte livslÀngden för de sista av de tidigare utfÀrdade tokens ut, vilket ledde till en total nedstÀngning av Nitter.
Efter att Elon Musk köpte Twitter (numera omdöpt till X) började plattformen implementera en rad tekniska och organisatoriska Ă„tgĂ€rder för att aggressivt montera monetariseringen av plattformen, som tidigare betraktades som olönsam. Bland förĂ€ndringarna infördes en prissĂ€ttning av information som varje konto fĂ„r (det infördes begrĂ€nsningar för olika typer av konton â 10 000 för innehavare av den betalda "blĂ„ checkmarken", 1 000 för vanliga, 500 för nya vanliga); "utvecklarkonton" flyttades till betalstatus med begrĂ€nsningar lĂ€mpliga för storskalig datautvinning (skrapning); Ă„tkomsten av information till anvĂ€ndare utan konton upphörde.
Som en ursÀkt pÄstods offentligt (2023-07-01) att detta var "tillfÀlliga nödinstrument", kopplade till att automatiserade dataladdningar av botar försÀmrar servicen för vanliga anvÀndare. Tidigare (2023-04-19) fanns insinuationer mot Microsoft, kopplade till att detta företag olagligt anvÀnde Twitter-data för att trÀna AI. Senare (2023-11-17) motiverades införandet av grÀnser med Musks utlovade kamp mot botar.
Nitter var ett projekt för att utveckla programvara som skyddar Twitter-anvÀndare som bara lÀser innehÄll, inte skickar meddelanden, genom att erbjuda dem en alternativ webbplats för att se Twitter utan krav pÄ konto eller aktiverat JavaScript. SÄdan programvara Àr i praktiken en skrapare och mellanhand som istÀllet för att spara data i en databas skickar dem direkt till slutanvÀndaren (dock cachas vissa data i Redis).
SĂ„ledes var programvaran Nitter:
Genom analys av alternativa metoder för att fortsÀtta verksamheten under nya förhÄllanden upptÀcktes RSS och vissa Ätkomstpunkter pÄ syndication.twitter.com, som gav information till icke registrerade anvÀndare i JSON-format och anvÀndes för integration med andra sociala nÀtverk. Under en tid fick Nitter information via dessa grÀnssnitt, men de stÀngdes senare. Efter det hittades ett sÀtt att anvÀnda "gÀstkonton" som hade lÀsbehörighet. En av typerna av "gÀstkonton" var avsedd för anvÀndning pÄ IoT-enheter med begrÀnsade webblÀsare.
Men Nitter anvÀnde en annan typ av "gÀstkonton" som anvÀnde OAuth istÀllet för cookies, registrerades via API och verkade anvÀndas av en Android-app. Denna typ av konto har begrÀnsningar pÄ 500 API-begÀrningar var 15:e minut, och dess "registrering" Àr kopplad till IP-adress (frÄn en IP kan ett "gÀstkonto" registreras pÄ en dag, men ett redan registrerat "konto" kan anvÀndas frÄn andra IP-adresser).
Dessa "konton" (Ätkomsttoken) var funktionella i 30 dagar. Vid den tiden skulle en adekvat lösning för problemet med massregistrering av temporÀra konton kunna vara crowdsourcing av deras registrering av anvÀndare, genom att anvÀnda nÄgot liknande Bibliogram (en anvÀndarskript som tar emot gÀsttoken frÄn anvÀndaren och överför det till den offentliga instansen).
I slutet av januari upphörde X att utfÀrda sÄdana token. Avvecklingen av den sista Ätkomstmetoden satte stopp för Nitter som en offentlig gratis multiplattformstjÀnst, vilket fick författaren att utropa Nitter som död.
En del av instanserna stÀngdes omedelbart efter detta, medan andra modifierade koden för strikt ekonomisk anvÀndning av de befintliga token, sÀrskilt med fokus pÄ att anvÀnda dem för att hÀmta listor med tweets frÄn konton, vilket resulterade i felmeddelanden för allt annat. Den 26 februari gick livslÀngden för de sista gÀstÄtkomsttoken ut, vilket ledde till att alla offentliga instanser upphörde att fungera. Diskussioner pÄ buggrapporteringstjÀnsten pÄgÄr dock om sÀtt att pÄ nÄgot sÀtt beröra gÀstÄtkomstkonton.
En av de radikala lösningarna pÄ problemet skulle kunna vara att ersÀtta Twitter genom att skapa en alternativ, decentraliserad tjÀnst baserad pÄ ActivityPub och IPFS, dÀr den primÀra identifieraren för varje meddelande Àr dess IPFS CID. Man kan förestÀlla sig följande flerlagerskonstruktion:
Data frÄn punkt 3 löser dock inte problemet med att anvÀndarna av Twitter inte deltar i programmet för Twitter-ersÀttning.
För varje identifierare av ett inlÀgg pÄ varje centraliserad plattform kan det vara fördelaktigt att stödja visningen av dess IPFS CID, vilket fungerar som en cache som gör det möjligt att utan att kÀnna till sjÀlva texten i inlÀgget, men med kÀnnedom om dess centraliserade identifierare, ta reda pÄ dess decentraliserade identifierare. Vid generering av URI i IPFS (vilket kan göras utan faktisk uppladdning) genomgÄr texten i inlÀgget normalisering, vilket involverar att data placeras i en behÄllare baserad pÄ HTML med maskinlÀsbara metadatan, normalisering av Unicode, konvertering till UTF-8, ersÀttning av vita tecken med enkla mellanslag, och ersÀttning av alla lÀnkar till inlÀgg pÄ denna och andra plattformar som genomgÄr en liknande procedur med URI i IPFS.
Varje plattform har ett maskinlÀsbart dokument som beskriver reglerna för kanonisering av inlÀgg, inklusive mÄnga tjÀnster vars lÀnkar ersÀtts med IPFS-URI i inlÀgg pÄ detta nÀtverk. Varje inlÀgg i varje nÀtverk kanoniseras enligt reglerna för kanonisering av inlÀgg i det nÀtverket som gÀller vid tidpunkten dÄ inlÀgget Àr daterat. Vid kanonisering, om det finns en lÀnk till ett inlÀgg pÄ en av de ersatta plattformarna, extraherar implementationen en centraliserad identifierare frÄn lÀnken och kontrollerar dess nÀrvaro i betrodda index.
Om den finns i indexet, anvÀnder implementationen den decentraliserade identifieraren frÄn indexen. Om den inte finns, begÀr implementationen inlÀgget via lÀnken, kanoniserar det och skapar en identifierare som kan placeras i indexen. Implementation behöver inte placera det begÀrda inlÀgget i det decentraliserade nÀtverket. Implementation kan kontrollera korrektheten av identifieraren i indexet genom lokal reproduktion av processen. Implementeringen av indexet Àr skyldig att verifiera korrektheten av identifierargenerering genom lokal reproduktion av processen.
En sÄdan deterministisk process gör det möjligt att generera oförÀnderliga lÀnkar till innehÄll Àven för tweets vars posters för nÀrvarande inte deltar i programmet för Twitter-ersÀttning. NÀr en del av dem börjar ladda upp sina tweets till IPFS, kommer algoritmen att generera identifierare för dem som Àr identiska med dem som redan anvÀnds i lÀnkarna, förutsatt att indexet innehÄller korrekta avbildningar och att sjÀlva innehÄllet inte har förÀndrats.
KĂ€lla: opennet.ru
