Nitter の最後の公開インスタンスは荒廃しました。 Nitter プロジェクトは、JavaScript、分析、トラッカー、サードパーティ サービスを課すことなく X.com/Twitter にアクセスするための無料のフロントエンドを開発しました。 31 月 26 日、Nitter が X.com 上のコンテンツへのアクセスを提供するために使用するトークンの発行が停止されました。 XNUMX 月 XNUMX 日、以前に発行された最後のトークンの有効期限が切れたため、Nitter は完全に停止されました。
イーロン・マスクに買収された後、Twitter（現在はXに改名）は、以前は採算が取れないと考えられていたプラットフォームを積極的に収益化することを目的とした一連の技術的および組織的対策を導入し始めた。変更点としては、各アカウントが受け取る情報に対して関税が導入されました（アカウントの種類ごとに制限が導入されました。有料の「青いチェックマーク」の所有者には10000、通常のアカウントには1000、新しい通常のアカウントには500）。大量のデータ抽出 (スクレイピング) に適した制限付きの「開発者」アカウントは、有料アカウントのカテゴリーに移されました。アカウントを持たないユーザーへの情報配信は停止されました。
ボットによる自動データアップロードが一般ユーザーへのサービス低下につながるため、これらは「一時的な緊急措置」であるという正当性が公にされている(2023-07-01)。これ以前 (2023 年 04 月 19 日)、Microsoft が AI のトレーニングに Twitter データを違法に使用しているという事実に関連して、Microsoft に対するほのめかしがありました。その後 (2023 年 11 月 17 日)、マスクが約束したボットとの戦いによって制限の導入が正当化されました。
Nitter は、アカウントや JavaScript を有効にする必要がなく、Twitter を閲覧するための代替サイトを提供することで、メッセージを送信せずコンテンツを読むだけの Twitter ユーザーを追跡から保護するソフトウェアを開発するプロジェクトでした。このようなソフトウェアは実際にはスクレイパーおよび仲介者であり、データをデータベースに保存する代わりにエンドユーザーに送信します (ただし、一部のサービス データは Redis にキャッシュされます)。
したがって、Nitter ソフトウェアは次のようになります。
新しい状況でも作業を継続するための回避策を分析した結果、未登録ユーザーに JSON 形式で情報を提供し、他のソーシャル ネットワークとの統合に使用されていた RSS と syndication.twitter.com のいくつかのエントリ ポイントが発見されました。しばらくの間、Nitter はこれらのインターフェイスを通じて情報を受信していましたが、その後閉鎖されました。その後、読み取り権限を持つ「ゲストアカウント」を使用する方法が見つかりました。 「ゲスト アカウント」タイプの 1 つは、必要最低限のブラウザを備えたモノのインターネット デバイスでの使用を目的としています。
しかし、ニッターは、Cookie の代わりに OAuth を使用し、API 経由で登録された別のタイプの「ゲスト アカウント」を使用し、アプリによって明らかに使用されました。 Androidこのタイプのアカウントは、15分あたり500回のAPIリクエストに制限されており、その「登録」は IPアドレス （1つのIPから1日1つの「ゲストアカウント」を登録できますが、他のIPアドレスからは既に登録済みの「アカウント」を使用できます）。
このような「アカウント」（アクセス トークン）は 30 日間運用されていました。その時点で、一時アカウントの大量登録の問題に対する適切な解決策は、ビブリオグラム (ユーザーからゲスト トークンを取得してパブリック インスタンスに転送するユーザー スクリプト) に似たものを使用して、ユーザーによる登録をクラウドソーシングすることです。 。
1月末に、Xはそのようなトークンの発行を停止した。後者のアクセス方法の削除により、Nitter は公共の無料のマルチユーザー サービスとして終了し、その結果、作成者は Nitter の死を宣言しました。
この後すぐに閉鎖されたインスタンスもあれば、特にアカウントからツイートのリストを取得するという主な用途で既存のトークンの使用を大幅に節約するためにコードを変更したインスタンスもあり、それ以外のインスタンスではエラー メッセージが発行されました。 26 月 XNUMX 日に最後のゲスト トークンの有効期限が切れたため、すべてのパブリック インスタンスが機能しなくなってしまいました。ただし、バグ トラッカーでは、ゲスト アカウントに何らかの影響を与える問題について説明しています。
この問題に対する根本的な解決策の 1 つは、ActivityPub と IPFS に基づいた代替の分散サービスを作成することで Twitter を置き換えることです。この場合、各メッセージの主な識別子は IPFS CID になります。次のような複数レベルの構造を想像できます。
ただし、これら 3 つの点では、Twitter ユーザーが Twitter 代替プログラムに参加しないという問題は解決されません。
各集中プラットフォーム上の投稿識別子ごとに、そのマッピングを IPFS CID に維持することをお勧めします。IPFS CID は、投稿自体のテキストを知らなくても、その集中識別子を知っていれば分散識別子を見つけることができるキャッシュとして機能します。 。 IPFS で URI を生成するとき (実際に入力しなくても実行できます)、投稿テキストは正規化されます。これは、機械可読メタデータを含む HTML ベースのコンテナにデータを配置し、Unicode 正規化、UTF-8 への変換、置換で構成されます。空白文字を単純な単一スペースに置き換え、同様の手順を経たこのプラットフォームおよび他のプラットフォーム上の投稿へのすべてのリンクを IPFS の URI に置き換えます。
各プラットフォームには、ネットワーク上の投稿内でリンクが IPFS URI に置き換えられる多くのサービスを含む、投稿を正規化するためのルールを説明する機械可読ドキュメントがあります。各ネットワーク内の各投稿は、投稿自体の日付が設定された時点で有効な、そのネットワーク内の投稿の正規化ルールに従って正規化されます。正規化中に、置き換えられたプラットフォームのいずれかの投稿へのリンクが投稿に含まれている場合、実装はリンクから集中識別子を抽出し、信頼できるインデックスにその識別子が存在するかどうかを確認します。
インデックス内に存在する場合、実装ではインデックスからの分散型識別子が使用されます。存在しない場合、実装は参照によって投稿を要求し、それを正規化し、インデックスに配置できる識別子を生成します。実装には、要求されたポストを分散ネットワーク上に配置する義務はありません。実装では、プロセスをローカルで再生することによって、インデックス内の識別子の有効性を検証できます。プロセスをローカルで再現することによって識別子の正しい生成を検証するのは、インデックス実装の責任です。
この決定論的なプロセスにより、投稿者がまだ Twitter 置換プログラムに参加していないツイートに対しても、不変のコンテンツ リンクを生成できます。彼らの一部が自分のツイートを IPFS にアップロードすると、インデックスに正しいマッピングが含まれており、コンテンツ自体が変更されていない限り、アルゴリズムはそのツイートへのリンクで既に使用されているものと同じ識別子を生成します。
出所： オープンネット.ru
