Поява корпоративно контрольованих платформ соціальних мереж, що приводиться комерційними мотивами, значно підриває початкову надію на участь культурного виробництва в інтернеті. Мережеві інформаційні технології повинні фундаментально демократизувати культурне виробництво, але зараз ці платформи обмежують та формують онлайн-участь переважно для комерційно мотивованих цілей - 'лайк' не є виразом подяки за контент, а є засобом монетизації, який стимулює комерційно мотивовані алгоритми.

Альтернативні платформи соціальних медіа, побудовані на децентралізованих та федеративних протоколах, пропонують повернення до оригінальної концепції онлайн-соціальності. Дані контролюються користувачем та поширюються по децентралізованих базах даних, фронтенди орієнтовані на спільноту, модерація є виразом уподобань спільноти, алгоритми вибираються користувачем, а етика відкритого коду підтримує інновації.

Історія децентралізованих та альтернативних соціальних медіа

До того, як Інтернет став центром комерції, розваг та соціальної взаємодії, він був насамперед академічним та військовим інструментом. Тім Бернерс-Лі дотримувався егалітарного бачення, коли формулював перші веб-протоколи - початковий дизайн Інтернету повинен був бути децентралізованою мережею, де інформація могла б вільно переміщатися між вузлами без будь-якої єдиної точки контролю або збою.

Однак у міру того, як Інтернет набував комерційного значення, централізовані платформи, такі як пошукові системи та гіганти соціальних мереж, стали домінуючими гравцями. Хоча ці сутності надавали значну цінність, вони відхилилися від початкового децентралізованого духу, що призвело до нашого нинішнього середовища web2.

Ключовим нововведенням в хронології альтернативних соціальних мереж було появою концепції федеративних протоколів. Федеративна мережа відноситься до системи, де кілька незалежних серверів або «вузлів» співпрацюють для формування однієї соціальної мережі, на відміну від централізованих платформ, де одна організація контролює всі сервери.

У федеративній системі кожен сервер працює з сумісним програмним забезпеченням, яке дотримується загальних протоколів, що дозволяють їм взаємодіяти між собою. Користувач, зареєстрований на одному сервері, може безперешкодно слідувати, взаємодіяти та ділитися вмістом з користувачами з інших серверів, ніби вони були на одній платформі. Приклади цих протоколів включають ActivityPub та OStatus, які працюють на федеративних платформах, таких як Mastodon та PeerTube.

В об'єднаній конфігурації користувачі можуть вибрати, якому серверу вони довіряють, потенційно мігруючи на інші сервери або налаштовуючи власний, що дає їм більше автономії. Для опису такої системи використовується термін "Fediverse" - портманто від "федерації" і "всесвіту". Fediverse починався з таких платформ, як GNU social та його попередників (StatusNet та Laconica), але справжнім поворотним моментом стала розробка та широке впровадження протоколу ActivityPub, який був опублікований як рекомендований стандарт Консорціумом Всесвітньої павутини (W3C) у 2018 році.

У межах web3 об'єднані соціальні мережі є станом за замовчуванням для децентралізованих систем після перенесення даних у мережу. Блокчейни діють як незалежний сервер для збереженого контенту, а фронтенди індексують цей контент і надають його безпосередньо користувачам. Ідентифікація обробляється публічними та приватними парами ключів, які вже керують гаманцями користувачів, що дозволяє їм легко автентифікувати будь-які дані чи вміст, які вони створюють. Крім того, використання ончейн-примітивів, таких як NFT, може об'єднувати збережений вміст у метадані та діяти як доменне ім'я або децентралізований ідентифікатор (DID).

Подібно до того, як працює ActivityPub, протоколи web3 прагнуть завантажувати соціальні графи за допомогою автентифікованих зв'язків між вузлами користувачів. Оскільки будь-який фронтенд може індексувати та обслуговувати цей контент, існує гіперконкуренція на рівні фронтенду, що призводить до процвітання ландшафту функцій. Крім того, оскільки дані є ончейн, користувачі можуть вибирати алгоритми, які їм зручно використовувати, і їх можна стимулювати використовувати певні, відновлюючи цінність своїх даних. Це поєднується з більш прямими засобами монетизації їхнього контенту, що робить кращий загальний досвід для творців, які значною мірою залишилися поза монетизацією, навіть незважаючи на те, що їхній контент є тим, що стимулює попит на ці платформи.

Порівняння протоколів

Щоб справді оцінити інновації у децентралізованих протоколах соціальних медіа, потрібно розуміти технічні нюанси, що дозволяють їм працювати. Зокрема, ми не включаємо всі соціальні протоколи тут, але вибираємо деякі з найпоширеніших:

Ідентичність / Простори імен

У контексті федеративних та децентралізованих соціальних графів або мережевих протоколів "простір імен" вказує на домен або область, під якою ідентифікатори користувачів або інші ресурси є унікальними. Це спосіб відрізняти ресурси або ідентичності одного домену/сервера від іншого, забезпечуючи відсутність конфліктів або двозначності при інтеграції або комунікації між кількома доменами.

Ідентифікація та пов'язані простори імен в різних децентралізованих соціальних протоколах охоплюють весь спектр від простих ключових пар (Nostr, Scuttlebutt) до URI, що вказують на HTTPs URL, що містять профілі (ActivityPub), до більш складних моделей, які використовують примітиви onchain, наприклад NFT (і недавно розширення ERC-6551, наприклад, Lens v2).

Farcaster є чудовим прикладом цих прийомів. Обліковий запис Farcaster представляє окрему сутність у мережі. Кожен обліковий запис має унікальний числовий ідентифікатор, який називається Farcaster ID («fid»). Посвідчення видаються та керуються ончейн за допомогою контракту Ethereum під назвою IdRegistry. Користувачі здійснюють транзакцію в IdRegistry для отримання нового фіда. Адреса, якій належить fid, є адресою зберігання користувача. IdRegistry гарантує, що фіди можуть бути передані між адресами, і що жодна з двох адрес не має однакових ідентифікаторів. Farcaster також розширює цей простір імен для підтримки імен ENS, які видаються ончейн або офчейн. Щоб заявити права на ім'я користувача, потрібно надіслати в мережу підписаний доказ.

ActivityPub, з іншого боку, ідентифікує кожного користувача за унікальним URI, зазвичай це HTTPS URL. Цей URI вказує на профіль користувача і слугує його глобальним ідентифікатором у Fediverse. Щоб зробити ці URIs більш дружніми до користувачів, багато платформ ActivityPub використовують систему, яка називається Webfinger. Webfinger дозволяє користувачам мати ідентифікацію, подібну до ‘@username@domain.com’.

Lens та CyberConnect замість цього керують профілями користувачів у якості NFT. У випадку з Lens, адреса користувача містить ProfileNFT, і можливо, що одна адреса містить декілька ProfileNFT. Кожен Profile NFT увібрав у себе весь історію активності користувача, включаючи повідомлення, дзеркала, коментарі та інші типи контенту, які вони створили. Додатково, у Profile NFT є FollowModule, який, по суті, є набором правил, які регулюють, як різні облікові записи можуть отримати Follow NFT. Ці Follow NFT служать для документування зв'язків між обліковими записами та основним профілем безпосередньо на ланцюжку. Також існують ручки, які можуть існувати окремо від профілів, і можуть бути мінтовані окремо один від одного. Ручки існують у власних просторах імен (наприклад, lens/@alice).

Дані

Дані, мабуть, є найважливішою характеристикою децентралізованих мереж, оскільки їх створення та стандартизація є тим, що забезпечує ці системи. Найбільш поширеною технікою управління даними тут є використання стандартизованих форматів, таких як JSON і загальні об'єкти зв'язку (наприклад, likes, follow). До основних об'єктів даних зазвичай належать:

Актори та Об'єкти: Визначені "актори" (наприклад, користувачі або групи) та "об'єкти" (наприклад, повідомлення або повідомлення).

Публікації: Пости або коментарі упаковані у «Публікації», часто пов'язані з зовнішнім вмістом за допомогою URL-адрес.

Зміст у журналах лише для додавання: Журнали, де кожен запис, чи то пост чи оновлення, є окремим елементом вмісту, послідовно доданим та збереженим.

Давайте розглянемо кілька прикладів того, як це працює за допомогою конкретних протоколів.

ActivityPub використовує формат даних ActivityStreams 2.0, структуру на основі JSON, для представлення різних соціальних взаємодій, таких як публікації або вподобання. Протокол розрізняє два основні компоненти: клієнт-сервер (C2S) і сервер-сервер (S2S). C2S дозволяє користувачам за допомогою клієнтських додатків взаємодіяти зі своїми відповідними серверами. На противагу цьому, S2S полегшує зв'язок між серверами, забезпечуючи надійний об'єднаний характер протоколу.

У межах ActivityPub сутності класифікуються як "актори" (часто облікові записи користувачів або групи) та "об'єкти" (вміст або дії, такі як повідомлення або вподобання). Коли актор виконує дію над об'єктом, він створює "активність", таку як "Створити", "Стежити" або "Подобається".

Графіки соціальних мереж Web3 використовують багато базових ідей ActivityPub, але застосовують їх onchain. Протокол Lens, наприклад, представляє "Публікації", які включають в себе різноманітний контент, створений користувачем, такий як повідомлення, дзеркала, коментарі та інші форми медіа. Кожна Публікація пов'язана з ContentURI, який направляє на конкретний контент, збережений в децентралізованому протоколі, такому як IPFS або Arweave, або, згідно, у централізованому сервісі зберігання, такому як AWS S3. Ця конфігурація забезпечує, що профіль користувача та всі пов'язані публікації зберігаються безпечно в їх особистому гаманці, віддаляючись від залежності від централізованих баз даних.

Крім того, Web3 дозволяє більш простий підхід до монетизації вмісту та впливу користувачів порівняно з Web2-структурою. Користувачі можуть брати плату за виготовлення Follow NFT або інтегрувати модулі збору зі своїми Публікаціями. Остання опція дозволяє їм отримувати винагороду за виготовлення NFT, пов'язаних із ContentURI їх публікації. Крім цих можливостей, протокол об'єктива пропонує GraphQL API, який служить для маскування компонентів блокчейну з інтерфейсами фронтенду, тим самим забезпечуючи більш дружній для користувача досвід, ніж попередні спроби децентралізованих соціальних мереж.

У кінцевому підсумку багато децентралізованих протоколів соціальних мереж створюють структури даних, які можна тільки доповнювати, які аутентифікуються ключами користувачів. Наприклад, на CyberConnect кожен елемент даних, орієнтований на користувача, представлений як потік даних, де оновлення дозволені тільки власником даних. Кожне оновлення даних додається до потоку даних у вигляді журналу додавання тільки та результуюча структура даних стає хеш-зв'язаною структурою даних, яку називають Merkle DAG. Типи даних включають в себе вміст, збори, коментарі та підписки.

Scuttlebutt аналогічно використовує журнал лише для додавання. У кожного користувача є власний журнал, де кожне нове повідомлення або дія додається до кінця після підписання посвідченням користувача (тобто пов'язаною парою ключів Ed25519). Він також підтримує обмін двійковими даними, які називаються «блобами». Це можуть бути зображення, відео або будь-який інший бінарний контент. Blob-об'єкти зберігаються окремо від журналів, які містять лише додавання, але посилання (хеші) на ці BLOB-об'єкти можуть бути включені до журналів.

Для Farcaster повідомлення - це загальнодоступні оновлення, такі як створення допису, підписка на когось або додавання зображення профілю, і ці повідомлення кодуються у вигляді protobuf і повинні бути зхешовані та підписані власником облікового запису. Користувачі можуть публікувати повідомлення в Хаби, якщо у них є достатньо місця для зберігання. Хаби перевіряють правомірність підписників кожного повідомлення перед їх прийняттям.

Зберігання

Ранні підходи до зберігання даних для децентралізованих протоколів були значною мірою офчейн, хоча й нагадували ончейн-консенсус. Наприклад, Scuttlebutt використовує однорангову мережу пліток, покладаючи відповідальність за зберігання даних на локальний пристрій користувача. Такий підхід забезпечує суверенітет даних, оскільки користувачі мають повний контроль над власною інформацією. Однак це також означає, що доступність даних залежить від того, чи знаходиться пристрій користувача в мережі, або інші вузли мережі, які мають копію даних. З часом, щоб керувати простором для зберігання, деяким клієнтам Scuttlebutt може знадобитися впровадити стратегії збору сміття, щоб скоротити старі або менш релевантні дані.

Альтернативою цьому одноранговому підходу є сервери, що зберігають дані, хоча і з резервуванням у порівнянні з традиційними медіа-платформами. Наприклад, Matrix має кілька домашніх серверів, які зберігають копії історій кімнат і синхронізуються один з одним. Коли користувач надсилає повідомлення (або будь-яку подію) у кімнаті, його домашній сервер транслює цю подію іншим домашнім серверам, які беруть участь у програмі, які потім зберігають і пересилають подію своїм підключеним клієнтам. Аналогічно, ActivityPub має кожен екземпляр (або сервер) у мережі, який зберігає свої дані, як правило, у базі даних. Вибір бази даних (реляційної, NoSQL і т.д.) залежить від конкретної реалізації програмного забезпечення ActivityPub. Наприклад, Mastodon, популярна платформа ActivityPub, використовує базу даних PostgreSQL.

Протоколи, такі як Cyberconnect, Farcaster та Lens, взяли на озброєння блокчейни для зберігання. Використання зберігання on-chain забезпечує незмінність та перевірку даних, що надає міцну основу для децентралізованих додатків, які використовують підґрунтеві консенсусні механізми для синхронізації стану. Однак такий підхід може призвести до проблем з масштабованістю, оскільки кожен елемент даних повинен бути збережений onchain, що потенційно може призвести до високих комісій за транзакції та повільних часів отримання даних.

Це спонукало багато соціальних протоколів web3 експериментувати з гібридними підходами, які використовують зберігання onchain для менш часто використовуваних дій (наприклад, профілі, підписки) та зберігання offchain для подій високої частоти (наприклад, лайки, репости, коментарі) або пакетне завантаження даних onchain в часті інтервали з використанням зберігання offchain як проміжної запобіжної міри.

CyberConnect, щоб ефективно обробляти часті оновлення між з'єднаннями користувачів, використовує список, пов'язаний з хешем, у децентралізованому сховищі даних. При ініціюванні з'єднання створюється «журнал операцій». Подальші зміни стану, як-от перемикання між стеженням і відстеженням, додаються як нові вузли до цього журналу. Хоча ці оновлення спочатку зберігаються на центральному сервері, вони періодично пакетно завантажуються на децентралізовані платформи зберігання, такі як Arweave або IPFS. Для швидкого пошуку даних вузли в журналі операцій зберігаються централізовано. Однак користувачі можуть незалежно перевірити цілісність даних, перейшовши по цьому списку з посиланнями на хеш. Незважаючи на залежність від центрального сервера для деяких запитів даних, система CyberConnect розроблена таким чином, щоб бути достатньо децентралізованою, а також забезпечувати високу продуктивність.

Farcaster аналогічно використовує гібридний підхід: ончейн-контракти використовуються для нечастих дій, де важлива послідовність і децентралізація. Облікові записи, імена користувачів, сховище та ключі керуються за допомогою серії контрактів Ethereum. Офчейн-системи використовуються для частих дій, де продуктивність має вирішальне значення. Повідомлення, створені обліковими записами користувачів, зберігаються та розповсюджуються в одноранговій мережі центрів Farcaster.

Обговорення

Децентралізовані соціальні протоколи готові революціонізувати користувацький досвід у цифровій взаємодії. Прискорене впровадження пар публічних-приватних ключів, зумовлене як тягою web3, так і проактивним заходом проти контенту, створеного штучним інтелектом, сприятиме ширшому розумінню та знайомству з примітивами ідентичності в цьому контексті, а подальша модерація та збір даних у компаніях соціальних мереж web2 відкрито підштовхне більше користувачів шукати інші місця. Ми очікуємо прискорення кривої впровадження цих протоколів.

Щоб сприяти еволюції нових додатків, існує нагальна потреба в тому, щоб розробники протоколів і розробники з відкритим вихідним кодом виходили за рамки базових типів даних і об'єктів зв'язків, які в даний час використовуються на рівні інфраструктури. У той час як існуючі примітиви адекватно інкапсулюють функціональні можливості звичайних соціальних мереж web2, існує величезний потенціал для розширення та інновацій. Більшість протоколів, що обговорюються тут, за своєю суттю підтримують розширюваність у своїх системах, забезпечуючи міцну основу для майбутніх розробок і внеску з відкритим вихідним кодом.

Однак важливо підкреслити важливість міжоперабельності. Хоча фронтенд-розробники здатні самостійно розширювати функціональність, це може відволікти від колективних переваг системи, якщо покращення не є взаємносумісними з іншими застосунками, побудованими на тому ж базовому протоколі. Забезпечення сумісності та безшовної інтеграції між різними застосунками є важливим для довгострокового успіху та прийняття децентралізованих соціальних протоколів.

У сфері зберігання даних загальновизнаною стає гібридний підхід в межах виникнення соціальних протоколів web3. Одержавши великий обсяг соціального контенту та залучення, прагматично виділити високоцінні активи, такі як ідентичність та основний контент, для примітивів на ланцюжку, в той час як менш ризикований контент, такий як лайки та реакції, передати на рішення поза ланцюжком. Цей збалансований підхід не лише зберігає цілісність та безпеку важливих даних, але й забезпечує користувачів досвід, схожий на традиційні соціальні медіа платформи.

Disclaimer:

1. Ця стаття була перепублікована з [Gateдзеркало]. Усі авторські права належать оригінальному авторові [1kx]. Якщо є заперечення до цього повторного друку, будь ласка, зв'яжіться Gate Learnкоманда, і вони оперативно цим займуться.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не складають жодної інвестиційної поради.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.