The last publicly available instance of Nitter has become inoperative. The Nitter project developed a free frontend for accessing X.com/Twitter without enforcing JavaScript, analytics, trackers, and third-party services. On January 31, the issuance of tokens used in Nitter for accessing content on X.com was halted. On February 26, the lifetime of the last issued tokens expired, leading to a complete shutdown of Nitter.
After Elon Musk's acquisition, Twitter (now renamed X) began implementing a series of technical and organizational measures aimed at aggressive monetization of the platform, which was previously considered unprofitable. Among the changes, a pricing model was introduced for information received by each account (limits were set for different types of accounts — 10,000 for paid 'blue check' holders, 1,000 for regular users, and 500 for new regular accounts); 'developer' accounts were reclassified as paid with limits suitable for mass data extraction (scraping); access to information for users without accounts was discontinued.
As a justification, it was publicly stated (2023-07-01) that these were 'temporary emergency measures' related to the fact that automated data loading by bots deteriorates the service for regular users. Prior to this (2023-04-19), there were insinuations against Microsoft concerning the company's illegal use of Twitter data for training AI. Later (2023-11-17), the introduction of limits was justified by Musk's promised fight against bots.
Nitter was a software project designed to protect Twitter users from surveillance, who do not post messages but only read materials, by providing them with an alternative site for viewing Twitter that requires neither an account nor enabled JavaScript. Such software essentially acts as a scraper and intermediary, which instead of saving data in a database, sends it directly to the end user (nevertheless, some service data is cached in Redis).
Thus, the Nitter software:
As a result of analyzing workarounds to continue operating under new conditions, RSS and some entry points on syndication.twitter.com were discovered, which provided information to unregistered users in JSON format, and were used for integration with other social networks. For a while, Nitter was receiving information through these interfaces, but they were subsequently shut down. After that, a way was found to use 'guest accounts' that had read privileges. One type of 'guest account' was designed for use on Internet of Things devices with limited browsers.
However, Nitter used another type of 'guest account' that used OAuth instead of cookies, was registered via the API, and seemingly was used by an Android application. This type of account has limits of 500 API requests within 15 minutes, and its 'registration' is tied to IP address (one 'guest account' can be registered from one IP per day, but an already registered 'account' can be used from other IP addresses).
Such 'accounts' (access tokens) were operational for 30 days. At that time, a viable solution to the problem of mass registration of temporary accounts could have been crowd-sourcing their registration by users, using something similar to Bibliogram (a user script that retrieves the guest token from the user and transfers it to the public instance).
At the end of January, X stopped issuing such tokens. The elimination of the last access method dealt a fatal blow to Nitter as a public free multi-user service, resulting in the author declaring Nitter dead.
Some instances closed immediately after that, while others modified the code for strict savings on existing tokens, particularly with a preference for using them to retrieve lists of tweets from accounts, issuing error messages for everything else. On February 26, the lifespan of the last guest tokens expired, resulting in all public instances ceasing to function. Nevertheless, discussions are ongoing in the bug tracker about ways concerning guest accounts.
One radical solution to the problem could be a Twitter replacement by creating an alternative decentralized service based on ActivityPub and IPFS, where the main identifier of each message is its IPFS CID. A multi-layered structure can be envisioned:
However, the data in point 3 does not solve the problem of Twitter users not participating in the Twitter replacement program.
For each post identifier on each centralized platform, it may be prudent to maintain a mapping to its IPFS CID, which acts as a cache, allowing one to know its decentralized identifier without knowing the actual text of the post, but with knowledge of its centralized identifier. When generating a URI in IPFS (which can be done without actual uploading), the text of the post undergoes canonicalization, which includes placing data in a container based on HTML with machine-readable metadata, normalizing Unicode, converting to UTF-8, replacing whitespace characters with simple single spaces, and replacing all links to posts on this and other platforms, undergoing a similar procedure, with URIs in IPFS.
Each platform has a machine-readable document describing the canonicalization rules for posts, including many services whose links are replaced with IPFS URIs in posts on this network. Each post in every network is canonicalized according to the canonicalization rules of that network, effective at the time the post is dated. During canonicalization, if there is a link to a post on one of the substitute platforms, the implementation extracts the centralized identifier from the link and checks its presence in trusted indexes.
If present in the index, the implementation uses the decentralized identifier from the indexes. If absent, the implementation requests the post via the link, canonicalizes it, and generates an identifier that can be placed in indexes. The implementation is not obligated to place the requested post in a decentralized network. The implementation can verify the correctness of the identifier in the index by locally reproducing the process. The index implementation is required to check the correctness of identifier generation by locally reproducing the process.
Such a deterministic process allows for the generation of immutable links to content even for tweets, the posters of which are not yet participating in the Twitter substitution program. When some of them start uploading their tweets to IPFS, the algorithm will generate identifiers for them that are identical to those already used in links to them, provided the index contains correct mappings and the content itself has not changed.
Source: opennet.ru
