🥇Прекратяване на съществуването на Nitter, свободен алтернативен фронтенд за Twitter

Последният публичен екземпляр на Nitter стана неизползваем. Проектът Nitter развиваше безплатен фронтенд за достъп до X.com/Twitter без навременен JavaScript, аналитика, тракери и трети услуги. На 31 януари спряха издаването на токени, използвани в Nitter за организиране на достъп до съдържание в X.com. На 26 февруари срокът на последните от преди издадени токени изтече, което доведе до пълно прекратяване на работата на Nitter.

След покупката от Илон Мъск, Twitter (сега преименуван на X) започна да прилага комплекс от технически и организационни мерки, насочени към агресивна монетизация на платформата, която преди беше считана за нерентабилна. Включените промени обхванаха тарифиране на информацията, получена от всяка сметка (въведени лимити за различни видове сметки — 10000 за притежателите на платена „синя отметка“, 1000 за обикновените, 500 за нови обикновени); сметките на „разработчиците“ бяха преместени в платената категория с лимити, подходящи за масово извличане на данни (скрейпинг); предоставянето на информация на потребители без акаунти беше прекратено.

Като оправдание публично беше заявено (2023-07-01), че това са „временни извънредни мерки“, свързани с факта, че автоматизираното изтегляне на данни от ботове влошава услугата за обикновените потребители. Преди това (2023-04-19) имаше инсинуации срещу Microsoft, свързани с твърдението, че тази компания незаконно използва данни от Twitter за обучение на AI. По-късно (2023-11-17) въведените лимити бяха обосновани с обещаната от Мъск борба с ботове.

Nitter беше проект за разработка на софтуер, който защитава потребителите на Twitter, които не изпращат съобщения, а само четат материали, предоставяйки им алтернативен сайт за разглеждане на Twitter, който не изисква нито акаунт, нито активиран JavaScript. Такъв софтуер по същество е скрейпер и посредник, който вместо да съхранява данни в БД, ги изпраща на крайния потребител (въпреки че някои служебни данни се кешират в Redis).

По този начин софтуерът Nitter:

технически представляваше точно онзи тип софтуер, с който ръководството на Twitter обяви активна борба;

беше едно от малкото активно разработвани приложения за достъп до данни, публикувани в Twitter, което обяснява неговата привлекателност за употреба като модул за скрейпинг в по-тесен смисъл на думата — събиране на данни извън официалните интерфейси за това;

публичните инстанции на Nitter сами станаха обект на скрейпинг, което доведе до реализирането на собствен вариант на капча от част от тези инстанции (1 допълнителен POST-заявка, специфична за конкретната инстанция).

В резултат на анализа на обходните пътища за продължаване на работата в новите условия бяха открити RSS и някои входни точки на syndication.twitter.com, които предоставяха информация на незарегистрирани потребители във формат JSON и се използваха за интеграция с други социални мрежи. Някое време Nitter получаваше информация чрез тези интерфейси, но впоследствие и те бяха затворени. След това беше намерен начин за използване на „гостови акаунти“, които имаха привилегии за четене. Един от типовете „гостови акаунти“ беше предназначен за използване на устройства с интернет неща с ограничени браузъри.

Но Nitter използваше друг тип „гостови акаунти“, които прилагаха OAuth вместо бисквитките, регистрираха се чрез API и очевидно се използваха от приложението за Android. Този тип акаунти има лимити от 500 заявки към API за 15 минути, а „регистрацията“ му е свързана с IP-адресу (от един IP може да се регистрира един „гостов акаунт“ в рамките на 24 часа, но вече регистрираният „акаунт“ може да се използва от други IP адреси).

Тези „акаунти“ (токени за достъп) бяха активни в продължение на 30 дни. В този момент адекватно решение на проблема с масовата регистрация на временни акаунти би могла да стане краудсорсинг регистрацията им от потребителите, като се използва нещо подобно на Bibliogram (потребителски скрипт, който получава гостовия токен от потребителя и го предава на публичната инстанция).

В края на януари X спря предоставянето на такива токени. Премахването на последния начин за достъп сложи край на Nitter като публичен безплатен многофункционален сервис, в резултат на което авторът обяви Nitter за мъртъв.

Някои от екземплярите веднага се затвориха след това, а други модифицираха кода, за да икономисат с използването на съществуващите токени, като акцентираха на тяхното използване за получаване на списъци с туитове на акаунти, като за всичко останало се извеждаха съобщения за грешки. На 26 февруари срокът на последните гостуващи токени изтече, в резултат на което всички публични екземпляри прекратиха функционирането си. Въпреки това в баг трекера се обсъждат начини, които по някакъв начин касаят гостуващите акаунти.

Едно от кардиналните решения на проблема би могло да бъде заменянето на Twitter чрез създаването на алтернативен децентрализован сервиз, основан на ActivityPub и IPFS, където основният идентификатор на съобщението е неговият IPFS CID. Може да си представим следната многостепенна конструкция:

Данни, първоначално публикувани във федеративната услуга, както на основната платформа, така и отразени в IPFS.

Данни, публикувани в Twitter от самите потребители, но с помощта на браузърно разширение отразени в техните акаунти на федеративната платформа, а оттам — в IPFS.

Данни, които са били изтеглени от Twitter от самите потребители, ползвайки функцията за изтегляне, и качени в Fediverse + IPFS чрез функцията за масово качване.

Данните от точка 3 обаче не решават проблема с неучастието на потребителите на Twitter в програмата за заменяне на Twitter.

За всеки идентификатор на пост на всяка централизирана платформа може да е целесъобразно да се поддържа отображение на неговия IPFS CID, който служи като кеш, позволяващ без знание на текста на самия пост, но при знание на неговия централизирания идентификатор, да се научи неговия децентрализован идентификатор. При генерирането на URI в IPFS (което може да бъде направено без фактическо качване) текстът на поста преминава през каноникализация, която се състои в поставянето на данните в контейнер, базиран на HTML с машинно четими метаданни, нормализация на UTF-8, замяна на пробелите с обикновени единични интервали и замяна на всички връзки към постовете в тази и другите платформи, преминаващи през подобна процедура, на URI в IPFS.

Всяка от платформите разполага с машинночетим документ, в който са описани правилата за каноникализация на постове, включително множество услуги, чиито линкове се заменят с IPFS URI в постовете на тази мрежа. Всеки пост във всяка мрежа се канониализира съобразно правилата за каноникализация на постовете в тази мрежа, действащи към момента, на който е датирован самият пост. При каноникализация, ако в поста има линк към пост в една от заменените платформи, реализацията извлича от линка централизирания идентификатор и проверява наличието му в доверените индекси.

При наличие в индекса, реализацията използва децентрализирания идентификатор от индексите. При отсъствие, реализацията запитва поста по линка, канониализира го и формира идентификатор, който може да бъде поставен в индексите. Реализацията не е задължена да поставя запитания пост в децентрализирана мрежа. Реализацията може да проверява валидността на идентификатора в индекса чрез локално възпроизвеждане на процеса. Реализацията на индекса е задължена да провери точността на генерирането на идентификаторите чрез локално възпроизвеждане на процеса.

Този детерминиран процес ще позволява генерирането на неизменяеми линкове към съдържание дори за туитове, чийто постери все още не участват в програмата за туитериране. Когато част от тях започнат да качват своите туитове в IPFS, алгоритъмът ще генерира за тях идентификатори, идентични на тези, които вече се използват в линковете към тях, при условие че индексът съдържа верни отразявания и самото съдържание не е било променяно.

Източник: opennet.ru