Последният публичен екземпляр на 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:
В резултат на анализа на обходните пътища за продължаване на работата в нови условия бяха открити RSS и някои входни точки на syndication.twitter.com, които предоставяха информация на незарегистрировани потребители в JSON формат и се използваха за интеграция с други социални мрежи. Няколко време Nitter получаваше информация чрез тези интерфейси, но след това и те бяха спрени. След това беше намерен начин за използване на "гостови акаунти", които имаха привилегии за четене. Един от типовете "гостови акаунти" беше предназначен за използване на устройства за интернет на нещата с ограничени браузъри.
Но Nitter използваше друг тип "гостови акаунти", които прилагаха OAuth вместо Cookie, регистрираха се през API и очевидно се използваха от приложението за Android. Този тип акаунти има лимити от 500 запитвания към API в рамките на 15 минути, а "регистрацията" му е свързана с IP адрес (от един IP може да се регистрира един "гостов акаунт" в рамките на ден, но вече регистрираният "акаунт" може да се използва от други IP адреси).
Такива "акаунти" (токени за достъп) бяха работоспособни в продължение на 30 дни. В този момент адекватно решение на проблема с масовата регистрация на временни акаунти можеше да бъде краудсорсингът на тяхната регистрация от потребителите, използващи нещо подобно на Bibliogram (потребителски скрипт, който взема гостовия токен от потребителя и го предава на публичната инстанция).
В края на януари X спря издаването на такива токени. Отстраняването на последния метод на достъп сложи край на Nitter като публичен безплатен многопотребителски сервис, в резултат на което авторът обяви Nitter за мъртъв.
Част от инстанциите след това веднага спряха, други модифицираха кода за строго икономисване на съществуващите токени, като в частност се концентрираха върху получаването на списъци с туитове от акаунти, докато за всичко останало се издаваха съобщения за грешки. На 26 февруари експирацията на последните гостови токени настъпи, в резултат на което всички публични инстанции прекратиха функционирането си. Ненакрая в баг-трекера се обсъждат начини, които по някакъв начин се отнасят до гостови акаунти.
Едно от кардиналните решения на проблема би могло да бъде замяната на Туитър чрез създаване на алтернативна децентрализирана услуга на базата на ActivityPub и IPFS, където основният идентификатор на съобщението е неговият IPFS CID. Може да си представим следната многостепенна конструкция:
Данните от точка 3 не решават обаче проблема с неучастието на потребители на Туитър в програмата за замяна на Туитър.
За всеки идентификатор на пост на всяка централизирана платформа може да бъде целесъобразно да се поддържа отразяване в IPFS CID, който служи като кеш, позволявайки без знание на самия текст на поста, а единствено при знание на неговия централизован идентификатор, да се узнаe неговият децентрализиран идентификатор. При генерирането на URI в IPFS (което може да бъде направено без фактическо качване), текстът на поста преминава през каноникализация, която се състои в поставяне на данни в контейнер на базата на HTML с машинно четими метаданни, нормализация на юникода, конвертиране в UTF-8, замяна на интервалите с обикновени единични интервали и замяна на всички линкове към постове в тази и други платформи, преминаващи през аналогична процедура, с URI в IPFS.
Всяка от платформите разполага с машиночитаем документ, в който се описват правилата за каноникализация на публикации, включително множество услуги, чиито линкове се заменят с IPFS URI в публикациите на тази мрежа. Всяка публикация в мрежата се канониализира в съответствие с правилата за каноникализация на публикации, действителни към момента на публикуването, на която е датирана самата публикация. При каноникализация, ако в публикацията има линк към публикация на една от заменяемите платформи, реализацията извлича от линка централизирания идентификатор и проверява наличието му в доверените индекси.
При наличие в индекса, реализацията използва децентрализирания идентификатор от индексите. При отсъствие, реализацията запитва публикацията по линка, канониализира я и формулира идентификатор, който може да бъде поставен в индексите. Реализацията не е задължена да поставя запитаната публикация в децентрализираната мрежа. Реализацията може да проверява валидността на идентификатора в индекса чрез локално възпроизвеждане на процеса. Реализацията на индекса е задължена да провери валидността на генерирането на идентификатори чрез локално възпроизвеждане на процеса.
Такъв детерминиран процес ще позволи генерирането на неизменяеми линкове към съдържание дори за туитове, чиито постери все още не участват в програмата за заместване на Twitter. Когато част от тях започне да качва своите туитове в IPFS, алгоритъмът ще генерира за тях идентификатори, идентични на тези, които вече се използват в линковете към тях, при условие че индексът съдържа верните отображения и самото съдържание не се е променило.
Източник: opennet.ru
