Ekzemplarët e fundit publikë të Nitter kanë dalë jashtë funksionit. Projekti Nitter zhvilloi një frontend të lirë për qasje në X.com/Twitter pa imponimin e JavaScript, analizave, ndjekësve dhe shërbimeve të tjera të palëve të treta. Më 31 janar, shpërndarja e tokeneve që përdoren në Nitter për organizimin e qasjes në përmbajtjen e X.com u ndërpre. Më 26 shkurt, skadoi koha e jetës së tokeneve të fundit të lëshuara më parë, gjë që çoi në një ndalim të plotë të funksionimit të Nitter.
Pas blerjes nga Elon Musk, Twitter (tani i rinovuar si X) filloi tĂ« zbatojĂ« njĂ« sĂ«rĂ« masash teknike dhe organizative, tĂ« dizajnuara pĂ«r tĂ« monetizuar nĂ« mĂ«nyrĂ« agresive platformĂ«n, e cila mĂ« parĂ« ishte konsideruar e humbur. NdĂ«r ndryshimet ishte realizimi i tarifimit tĂ« informacionit tĂ« marrĂ« nga çdo llogari (u vendosĂ«n kufij pĂ«r lloje tĂ« ndryshme llogarish â 10,000 pĂ«r mbajtĂ«sit e âkorrigjimit bluâ me pagesĂ«, 1,000 pĂ«r tĂ« zakonshmit, 500 pĂ«r tĂ« rinjtĂ« e zakonshĂ«m); u kaluan nĂ« kategorinĂ« e llogarive me pagesĂ« llogaritĂ« e âzhvilluesveâ me kufij tĂ« pĂ«rshtatshĂ«m pĂ«r nxjerrjen masive tĂ« tĂ« dhĂ«nave (skraping); u ndal shpĂ«rndarja e informacionit pĂ«r pĂ«rdoruesit pa llogari.
Si justifikim u tha publikisht (2023-07-01), se kĂ«to janĂ« âmasa emergjente tĂ« pĂ«rkohshmeâ, tĂ« lidhura me faktin se ngarkimi i automatizuar i tĂ« dhĂ«nave nga botĂ«t çon nĂ« pĂ«rkeqĂ«simin e shĂ«rbimit pĂ«r pĂ«rdoruesit e zakonshĂ«m. Para kĂ«saj (2023-04-19) kishte insinuata ndaj Microsoft, lidhur me faktin se kjo kompani pĂ«rdor nĂ« mĂ«nyrĂ« tĂ« paligjshme tĂ« dhĂ«nat e Twitter pĂ«r trajnim tĂ« AI. MĂ« vonĂ« (2023-11-17) futja e kufijve u arsyetua me premtimin e Musk pĂ«r tĂ« luftuar botĂ«t.
Nitter ishte një projekt për zhvillimin e një software për mbrojtjen nga ndjekja e përdoruesve të Twitter, të cilët nuk dërgojnë mesazhe, por thjesht lexojnë materiale, duke u ofruar atyre një faqe alternative për shikimin e Twitter, që nuk kërkon as llogari, as JavaScript të aktivizuar. Ky software në fakt është një skraper dhe ndërmjetës, i cili në vend që të ruajë të dhënat në një bazë të dhënash, i dërgon ato përdoruesit përfundimtar (megjithatë disa të dhëna shërbimi ruhen në Redis).
Pra, software-i Nitter:
Si rezultat i analizës së shpëtimve për të vazhduar punën në kushte të reja, u zbuluan RSS dhe disa pika hyrjeje në syndication.twitter.com, që jepnin informacion për përdoruesit e pa regjistruar në formatin JSON, dhe që përdorej për integrimin me rrjete të tjera sociale. Për një kohë Nitter merrte informacion nëpërmjet këtyre ndërfaqeve, por më pas edhe ato u mbyllën. Pas kësaj u gjet një mënyrë për të përdorur "llogaritë e mysafirëve", të cilat kishin privilegje për të lexuar. Një nga llojet e "llogaritë e mysafirëve" ishte e destinuar për përdorim në pajisjet e internetit të gjërave me shfletues të kufizuar.
Por Nitter përdori një lloj tjetër "llogaritë e mysafirëve", të cilat aplikuan OAuth në vend të Cookie, regjistroheshin përmes API dhe duket se përdoroheshin nga aplikacioni për Android. Ky tip llogarish ka kufizime prej 500 kërkesash për API në një periudhë 15-minutëshe dhe "regjistrimi" i tij është i lidhur me adresë IP (nga një IP mund të regjistrohet një "llogari mysafire" brenda një dite, por një "llogari" e regjistruar mund të përdoret nga IP të tjera).
Këto "llogari" (tokenet e aksesit) ishin funksionale për 30 ditë. Në atë kohë, një zgjidhje adekuate për problemin e regjistrimit masiv të llogarive temporale mund të ishte crowdsourcing-u i regjistrimit të tyre nga përdoruesit, duke përdorur diçka të ngjashme me Bibliogram (një skript përdoruesi, i cili merr tokenin e mysafirit nga përdoruesi dhe e dërgon atë në ekspozitën publike).
Në fund të janarit, X ndaloi dhënien e tillë të tokenëve. Eliminimi i mënyrës së fundit të qasjes e vendosi Nitter-in në fund si një shërbim publik falas dhe shumë përdorues, duke rezultuar në shpalljen e Nitter-it si të vdekur nga autori.
Disa nga ekzemplarët pas kësaj u mbyllën menjëherë, të tjerët modifikuan kodin për të kursyer fuqishëm përdorimin e tokeneve ekzistuese, veçanërisht duke i përdorur ato për të marrë lista të tweet-eve të llogarive, duke dhënë mesazhe gabimi për gjithçka tjetër. Më 26 shkurt, koha e jetës së tokeneve të fundit të vizitorëve skadoi, si rezultat i të cilit të gjithë ekzemplarët publikë ndaluan funksionimin. Megjithatë, në sistemin e raportimit të defekteve po diskutohen mënyrat që lidhen në një farë mënyre me llogaritë e vizitorëve.
Një nga zgjidhjet radikale për problemin mund të ishte zëvendësimi i Twitterit duke krijuar një shërbim alternativ të decentralizuar mbi bazën e ActivityPub dhe IPFS, ku identifikuesi kryesor për çdo mesazh është CID-i i tij IPFS. Mund të imagjinohet ndërtimi i një strukture me shumështresa:
Megjithatë, të dhënat nga pika 3 nuk e zgjidhin problemin e mosangazhimit të përdoruesve të Twitterit në programin e zëvendësimit të Twitterit.
Për çdo identifikator të postimit në çdo platformë të centralizuar mund të jetë e arsyeshme të mbajmë shfaqjen e tij në CID-in IPFS, i cili shërben si një cache, duke lejuar që pa e ditur tekstin e vetë postimit, por duke njohur identifikatorin e tij të centralizuar, të dihet identifikatori i tij decentralizuar. Gjatë gjenerimit të URI në IPFS (gjë që mund të bëhet pa ngarkim real), teksti i postimit kalon një proces kanonizimi, i cili përfshin vendosjen e të dhënave në një kontenier të bazuar në HTML me metadatë të lexueshme nga makina, normalizimin e Unicode, konvertimin në UTF-8, zëvendësimin e simboleve të zbrazëta me hapje të thjeshta të vetme, dhe zëvendësimin e të gjitha lidhjeve në postime në këtë dhe platforma të tjera, që kalojnë nëpër një procedurë të ngjashme, me URI në IPFS.
Ădo platformĂ« ka njĂ« dokument tĂ« lexueshĂ«m nga makina qĂ« pĂ«rshkruan rregullat e kanonikimit tĂ« postimeve, duke pĂ«rfshirĂ« shumĂ« shĂ«rbime, tĂ« cilat lidhjet e tyre zĂ«vendĂ«sohen me URI IPFS nĂ« postimet e kĂ«saj rrjete. Ădo post nĂ« çdo rrjet kanonizohet nĂ« pĂ«rputhje me rregullat e kanonikimit tĂ« postimeve nĂ« atĂ« rrjet, tĂ« cilat janĂ« nĂ« fuqi nĂ« momentin kur Ă«shtĂ« datuar vetĂ« posti. GjatĂ« kanonikimit, nĂ«se nĂ« post ka njĂ« lidhje ndaj njĂ« posti nĂ« njĂ« nga platformitat e zĂ«vendĂ«suara, realizimi nxjerr nga lidhja njĂ« identifikues qendror dhe kontrollon praninĂ« e tij nĂ« indekset e besueshme.
Në rast se është në indeks, realizimi përdor identifikuesin në mënyrë të decentralizuar nga indekset. Në rast mungese, realizimi kërkon postin përmes lidhjes, e kanonizon atë dhe formon një identifikues që mund ta vendosë në indekset. Realizimi nuk është i detyruar ta vendosë postin e kërkuar në një rrjet të decentralizuar. Realizimi mund të verifikojë saktësinë e identifikuesit në indeks përmes riprodhimit lokal të procesit. Realizimi i indeksit është i detyruar të verifikojë saktësinë e gjenerimit të identifikuesve përmes riprodhimit lokal të procesit.
Ky proces i deterministshëm lejon gjenerimin e lidhjeve të pandryshueshme për përmbajtjen, madje edhe për tweet-et, posterat e të cilave ende nuk marrin pjesë në programin e zëvendësimit të Twitter. Kur disa prej tyre të ngarkojnë tweet-et e tyre në IPFS, algoritmi do të gjenerojë për ta identifikues të njëjtë me ato që përdoren tashmë në lidhjet për ta, me kusht që indeksi të ketë përfaqësime të sakta dhe vetë përmbajtja të nuk ka ndryshuar.
Burimi: opennet.ru
