Den sidste offentlige forekomst af Nitter er faldet i forfald. Nitter-projektet udviklede en gratis frontend til at få adgang til X.com/Twitter uden at pålægge JavaScript, analyser, trackere og tredjepartstjenester. Den 31. januar blev udstedelsen af tokens brugt af Nitter til at give adgang til indhold på X.com stoppet. Den 26. februar udløb den sidste af de tidligere udstedte tokens, hvilket førte til et fuldstændigt stop for Nitter.
Efter at være blevet købt af Elon Musk begyndte Twitter (nu omdøbt til X) at implementere et sæt tekniske og organisatoriske foranstaltninger, der sigtede på aggressivt at tjene penge på platformen, som tidligere blev anset for urentabel. Blandt ændringerne blev tariffer implementeret for de oplysninger, der blev modtaget af hver konto (grænser blev indført for forskellige typer konti - 10000 for indehavere af et betalt "blåt flueben", 1000 for almindelige, 500 for nye almindelige); "udvikler"-konti med grænser, der er egnede til massedataudtrækning (skrabning), er blevet overført til kategorien betalte; Distribution af information til brugere uden konti er stoppet.
Begrundelsen blev offentligt anført (2023-07-01), at der er tale om "midlertidige nødforanstaltninger" på grund af det faktum, at automatiseret dataupload af bots fører til forringelse af tjenesten for almindelige brugere. Før dette (2023-04-19) var der insinuationer mod Microsoft relateret til det faktum, at virksomheden ulovligt brugte Twitter-data til at træne AI. Senere (2023-11-17) blev indførelsen af grænser retfærdiggjort af kampen mod bots lovet af Musk.
Nitter var et projekt for at udvikle software til at beskytte Twitter-brugere, der ikke sender beskeder, men kun læser indhold, mod at blive sporet ved at give dem et alternativt websted til at se Twitter, der ikke kræver en konto eller JavaScript aktiveret. Sådan software er faktisk en skraber og mellemmand, som i stedet for at lagre data i databasen sender dem til slutbrugeren (dog cachelagres nogle servicedata i Redis).
Således Nitter-software:
Som et resultat af analysen af løsninger til at fortsætte arbejdet under de nye forhold, blev RSS og nogle indgangspunkter på syndication.twitter.com opdaget, der gav oplysninger til uregistrerede brugere i JSON-format og blev brugt til integration med andre sociale netværk. I nogen tid modtog Nitter information gennem disse grænseflader, men så blev de lukket. Herefter blev der fundet en måde at bruge "gæstekonti", der havde læserettigheder. En type "gæstekonto"-type var beregnet til brug på Internet of Things-enheder med afisolerede browsere.
Men Nitter brugte en anden type "gæstekonti", der brugte OAuth i stedet for Cookie, registrerede via en API, og som tilsyneladende blev brugt af appen til at AndroidDenne kontotype har en grænse på 500 API-anmodninger pr. 15 minutter, og dens "registrering" er knyttet til IP-adresse (fra én IP-adresse kan du registrere én "gæstekonto" pr. dag, men en allerede registreret "konto" kan bruges fra andre IP-adresser).
Sådanne "konti" (adgangstokens) var operationelle i 30 dage. På det tidspunkt ville en passende løsning på problemet med masseregistrering af midlertidige konti være at crowdsource deres registrering af brugere ved at bruge noget, der ligner Bibliogram (et brugerscript, der tager gæstetokenet fra brugeren og overfører det til en offentlig instans) .
I slutningen af januar holdt X op med at udstede sådanne tokens. Fjernelsen af sidstnævnte adgangsmetode satte en stopper for Nitter som en offentlig, gratis flerbrugertjeneste, hvilket resulterede i, at forfatteren erklærede Nitter for død.
Nogle forekomster lukkede straks efter dette, andre ændrede koden for alvorligt at redde brugen af eksisterende tokens, især med deres primære brug til at få lister over tweets fra konti, med fejlmeddelelser, der blev udstedt for alt andet. Den 26. februar udløb de sidste gæstetokens, hvilket fik alle offentlige instanser til at ophøre med at fungere. Fejlsporingen diskuterer dog problemer, der på en eller anden måde påvirker gæstekonti.
En af de radikale løsninger på problemet kunne være Twitter-erstatning ved at skabe en alternativ decentraliseret tjeneste baseret på ActivityPub og IPFS, hvor den vigtigste identifikator for hver besked er dens IPFS CID. Vi kan forestille os følgende struktur på flere niveauer:
Disse 3 punkter løser dog ikke problemet med Twitter-brugere, der ikke deltager i Twitter-erstatningsprogrammet.
For hver post-id på hver centraliseret platform kan det være tilrådeligt at vedligeholde dens kortlægning i IPFS CID, der fungerer som en cache, der giver dig mulighed for at finde ud af dens decentraliserede identifikator uden at kende teksten til selve indlægget, men at kende dens centraliserede identifikator. . Ved generering af en URI i IPFS (som kan gøres uden egentlig at udfylde), gennemgår postteksten kanonisering, som består i at placere dataene i en HTML-baseret container med maskinlæsbare metadata, Unicode-normalisering, konvertering til UTF-8, udskiftning blanktegn med enkle enkelt mellemrum, og erstatter alle links til indlæg på denne og andre platforme, der gennemgår en lignende procedure med URI'er i IPFS.
Hver platform har et maskinlæsbart dokument, der beskriver reglerne for kanonisering af indlæg, herunder mange tjenester, hvis links er erstattet med IPFS URI'er i indlæg på det netværk. Hver post i hvert netværk kanoniseres i overensstemmelse med reglerne for kanonisering af stillinger i det pågældende netværk, der er gældende på det tidspunkt, som selve indlægget er dateret til. Under kanonisering, hvis et indlæg indeholder et link til et indlæg i en af de erstattede platforme, udtrækker implementeringen en centraliseret identifikator fra linket og kontrollerer dets tilstedeværelse i betroede indekser.
Når den er til stede i et indeks, bruger implementeringen den decentraliserede identifikator fra indekserne. Hvis den er fraværende, anmoder implementeringen om posten ved reference, kanoniserer den og genererer en identifikator, der kan placeres i indekser. Implementeringen er ikke forpligtet til at placere den ønskede post på det decentrale netværk. En implementering kan verificere gyldigheden af identifikatoren i indekset ved at afspille processen lokalt. Det er indeksimplementeringens ansvar at verificere den korrekte generering af identifikatorer ved lokalt at reproducere processen.
Denne deterministiske proces vil tillade generering af uforanderlige indholdslinks, selv for tweets, hvis plakater endnu ikke deltager i Twitter-erstatningsprogrammet. Når nogle af dem uploader deres tweets til IPFS, vil algoritmen generere identifikatorer til dem, der er identiske med dem, der allerede er brugt i links til dem, forudsat at indekset indeholder de korrekte kortlægninger, og selve indholdet ikke er ændret.
Kilde: opennet.ru
