Shembulli i fundit publik i Nitter ka rënë në gjendje të keqe. Projekti Nitter zhvilloi një frontend falas për të hyrë në X.com/Twitter pa imponuar JavaScript, analitikë, gjurmues dhe shërbime të palëve të treta. Më 31 janar, lëshimi i argumenteve të përdorura nga Nitter për të siguruar akses në përmbajtje në X.com u ndalua. Më 26 shkurt, i fundit nga argumentet e lëshuara më parë skadoi, gjë që çoi në ndalimin e plotë të Nitter.
Pasi u ble nga Elon Musk, Twitter (tani i riemërtuar X) filloi zbatimin e një sërë masash teknike dhe organizative që synonin të fitonin para në mënyrë agresive platformën, e cila më parë konsiderohej joprofitabile. Ndër ndryshimet, tarifat u zbatuan për informacionin e marrë nga secila llogari (u vendosën kufizime për lloje të ndryshme llogarish - 10000 për mbajtësit e një "shenje kontrolli blu", 1000 për ato të rregullta, 500 për ato të reja të rregullta); Llogaritë e "zhvilluesit" me kufij të përshtatshëm për nxjerrjen masive të të dhënave (skrapim) janë transferuar në kategorinë e atyre me pagesë; Shpërndarja e informacionit për përdoruesit pa llogari është ndalur.
Arsyetimi u deklarua publikisht (2023-07-01) se këto janë "masa të përkohshme emergjente" për faktin se ngarkimi i automatizuar i të dhënave nga bots çon në përkeqësim të shërbimit për përdoruesit e zakonshëm. Përpara kësaj (2023-04-19), kishte insinuata kundër Microsoft në lidhje me faktin se kompania po përdorte ilegalisht të dhënat e Twitter për të trajnuar AI. Më vonë (2023-11-17) futja e kufijve u justifikua nga lufta kundër robotëve të premtuar nga Musk.
Nitter ishte një projekt për të zhvilluar softuer për të mbrojtur përdoruesit e Twitter që nuk dërgojnë mesazhe, por vetëm lexojnë përmbajtje, nga gjurmimi duke u ofruar atyre një faqe alternative për shikimin e Twitter që nuk kërkon një llogari ose JavaScript të aktivizuar. Një softuer i tillë është në fakt një gërvishtës dhe ndërmjetës, i cili, në vend që të ruajë të dhënat në bazën e të dhënave, i dërgon ato te përdoruesi përfundimtar (megjithatë, disa të dhëna shërbimi ruhen në Redis).
Kështu softueri Nitter:
Si rezultat i analizës së zgjidhjeve për vazhdimin e punës në kushtet e reja, u zbuluan RSS dhe disa pika hyrëse në syndication.twitter.com që u jepnin informacion përdoruesve të paregjistruar në formatin JSON dhe u përdorën për integrim me rrjete të tjera sociale. Për ca kohë Nitter mori informacion përmes këtyre ndërfaqeve, por më pas ato u mbyllën. Pas kësaj, u gjet një mënyrë për të përdorur "llogaritë e mysafirëve" që kishin privilegje të lexuara. Një lloj i llojit të "llogarisë së mysafirëve" ishte menduar për t'u përdorur në pajisjet e Internetit të Gjërave me shfletues të zhveshur.
Por Nitter përdori një lloj tjetër të "llogarive të mysafirëve" që përdornin OAuth në vend të Cookie, të regjistruara nëpërmjet një API-je dhe me sa duket përdoreshin nga aplikacioni për të AndroidKy lloj llogarie ka një limit prej 500 kërkesash API për 15 minuta, dhe "regjistrimi" i saj është i lidhur me adresa IP (nga një IP mund të regjistroni një "llogari mysafiri" në ditë, por një "llogari" e regjistruar tashmë mund të përdoret nga adresa të tjera IP).
Këto "llogari" (tokenat e aksesit) ishin funksionale për 30 ditë. Në atë kohë, një zgjidhje adekuate për problemin e regjistrimit masiv të llogarive të përkohshme mund të ishte grumbullimi i regjistrimit të tyre nga përdoruesit, duke përdorur diçka të ngjashme me Bibliogram (një skript përdoruesi që merr shenjën e vizitorit nga përdoruesi dhe e transferon atë në një instancë publike).
Në fund të janarit, X ndaloi lëshimin e shenjave të tilla. Heqja e metodës së fundit të aksesit i dha fund Nitter-it si një shërbim publik, falas, me shumë përdorues, duke rezultuar në deklarimin e autorit të Nitter-it të vdekur.
Disa raste u mbyllën menjëherë pas kësaj, të tjera e modifikuan kodin për të kursyer rëndë përdorimin e shenjave ekzistuese, veçanërisht me përdorimin e tyre kryesor për marrjen e listave të cicërimave nga llogaritë, me mesazhe gabimi që lëshoheshin për gjithçka tjetër. Më 26 shkurt, skaduan shenjat e fundit të të ftuarve, duke bërë që të gjitha instancat publike të pushojnë së funksionuari. Megjithatë, gjurmuesi i gabimeve diskuton çështje që ndikojnë disi në llogaritë e mysafirëve.
Një nga zgjidhjet radikale të problemit mund të jetë zëvendësimi i Twitter duke krijuar një shërbim alternativ të decentralizuar bazuar në ActivityPub dhe IPFS, ku identifikuesi kryesor i çdo mesazhi është IPFS CID i tij. Mund të imagjinojmë strukturën e mëposhtme me shumë nivele:
Megjithatë, këto 3 pika nuk e zgjidhin problemin e përdoruesve të Twitter që nuk marrin pjesë në programin e zëvendësimit të Twitter.
Për çdo identifikues postimi në çdo platformë të centralizuar, mund të këshillohet të ruani hartën e tij në IPFS CID, i cili vepron si një cache që ju lejon të zbuloni identifikuesin e tij të decentralizuar pa e ditur vetë tekstin e postimit, por duke ditur identifikuesin e tij të centralizuar. . Kur gjenerohet një URI në IPFS (që mund të bëhet pa plotësuar realisht), teksti i postimit i nënshtrohet kanonikizimit, i cili konsiston në vendosjen e të dhënave në një kontejner të bazuar në HTML me meta të dhëna të lexueshme nga makineri, normalizim Unicode, konvertim në UTF-8, zëvendësim karaktere të hapësirës së bardhë me hapësira të thjeshta të vetme dhe duke zëvendësuar të gjitha lidhjet me postimet në këtë dhe platforma të tjera që kalojnë një procedurë të ngjashme me URI-të në IPFS.
Çdo platformë ka një dokument të lexueshëm nga makina që përshkruan rregullat për kanonikizimin e postimeve, duke përfshirë shumë shërbime, lidhjet e të cilave zëvendësohen me IPFS URI në postimet në atë rrjet. Çdo postim në secilin rrjet kanonizohet në përputhje me rregullat për kanonikizimin e postimeve në atë rrjet në fuqi në momentin në të cilin daton vetë postimi. Gjatë kanonikizimit, nëse një postim përmban një lidhje me një postim në një nga platformat e zëvendësuara, zbatimi nxjerr një identifikues të centralizuar nga lidhja dhe kontrollon praninë e tij në indekset e besuara.
Kur është i pranishëm në një indeks, zbatimi përdor identifikuesin e decentralizuar nga indekset. Nëse mungon, zbatimi kërkon postimin me referencë, e kanonizon dhe gjeneron një identifikues që mund të vendoset në indekse. Implementimi nuk është i detyruar të vendosë postin e kërkuar në rrjetin e decentralizuar. Një zbatim mund të verifikojë vlefshmërinë e identifikuesit në indeks duke riluajtur procesin në nivel lokal. Është përgjegjësi e zbatimit të indeksit të verifikojë gjenerimin e saktë të identifikuesve duke riprodhuar në nivel lokal procesin.
Ky proces determinist do të lejojë gjenerimin e lidhjeve të pandryshueshme të përmbajtjes edhe për tweet-et, posterët e të cilëve nuk po marrin pjesë ende në programin e zëvendësimit të Twitter. Kur disa prej tyre ngarkojnë tweet-et e tyre në IPFS, algoritmi do të gjenerojë identifikues për ta, identikë me ata që tashmë janë përdorur në lidhjet me ta, me kusht që indeksi të përmbajë pasqyrat e sakta dhe vetë përmbajtja nuk ka ndryshuar.
Burimi: opennet.ru
