Последният публичен екземпляр на Nitter се разпадна. Проектът Nitter разработи безплатен интерфейс за достъп до X.com/Twitter без налагане на JavaScript, анализи, тракери и услуги на трети страни. На 31 януари е спряно издаването на токени, използвани от Nitter за предоставяне на достъп до съдържание на X.com. На 26 февруари последният от издадените преди това токени изтече, което доведе до пълното спиране на Nitter.
След като беше закупен от Илон Мъск, Twitter (сега преименуван на X) започна да прилага набор от технически и организационни мерки, насочени към агресивно монетизиране на платформата, която преди беше смятана за нерентабилна. Сред промените са въведени тарифи за информацията, получавана от всеки акаунт (въведени са лимити за различни видове акаунти - 10000 1000 за притежатели на платена „синя отметка“, 500 за редовни, XNUMX за нови редовни); Акаунтите „разработчици“ с лимити, подходящи за масово извличане на данни (скрейпване), са прехвърлени в категорията на платените; Разпространението на информация за потребители без акаунти е спряно.
Обосновката беше публично заявена (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 февруари последните токени за гости изтекоха, което доведе до спиране на функционирането на всички публични инстанции. Програмата за проследяване на грешки обаче обсъжда проблеми, които по някакъв начин засягат акаунтите на гости.
Едно от радикалните решения на проблема може да бъде замяната на Twitter чрез създаване на алтернативна децентрализирана услуга, базирана на ActivityPub и IPFS, където основният идентификатор на всяко съобщение е неговият IPFS CID. Можем да си представим следната многостепенна структура:
Тези 3 точки обаче не решават проблема с неучастието на потребителите на Twitter в програмата за заместване на Twitter.
За всеки идентификатор на публикация на всяка централизирана платформа може да е препоръчително да поддържате нейното картографиране в IPFS CID, който действа като кеш, който ви позволява да откриете нейния децентрализиран идентификатор, без да знаете текста на самата публикация, но да знаете нейния централизиран идентификатор . При генериране на URI в IPFS (което може да се направи без действително попълване), текстът на публикацията претърпява канонизация, която се състои от поставяне на данните в HTML-базиран контейнер с машинно четими метаданни, нормализиране на Unicode, преобразуване в UTF-8, замяна празни знаци с прости единични интервали и замяна на всички връзки към публикации на тази и други платформи, които преминават през подобна процедура с URI в IPFS.
Всяка платформа има машинно четим документ, който описва правилата за канонизиране на публикации, включително много услуги, чиито връзки са заменени с IPFS URI в публикации в тази мрежа. Всяка публикация във всяка мрежа се канонизира в съответствие с правилата за канонизация на публикации в тази мрежа, които са в сила към момента, в който е датирана самата публикация. По време на канонизирането, ако дадена публикация съдържа връзка към публикация в една от заменените платформи, изпълнението извлича централизиран идентификатор от връзката и проверява за присъствието му в надеждни индекси.
Когато присъства в индекс, изпълнението използва децентрализирания идентификатор от индексите. Ако липсва, изпълнението изисква публикацията чрез препратка, канонизира я и генерира идентификатор, който може да бъде поставен в индекси. Реализацията не е задължена да постави исканата публикация в децентрализираната мрежа. Внедряването може да провери валидността на идентификатора в индекса чрез преиграване на процеса локално. Отговорност на изпълнението на индекса е да провери правилното генериране на идентификатори чрез локално възпроизвеждане на процеса.
Този детерминистичен процес ще позволи генерирането на връзки с неизменно съдържание дори за туитове, чиито плакати все още не участват в програмата за заместване на Twitter. Когато някои от тях качат своите туитове в IPFS, алгоритъмът ще генерира идентификатори за тях, идентични с тези, които вече са използвани във връзките към тях, при условие че индексът съдържа правилните съпоставяния и самото съдържание не е променено.
Източник: opennet.ru
