W czasach, gdy cyfrowe życie społeczne coraz częściej toczy się w zamkniętych, unikalnie zaprojektowanych aplikacjach, nowe ramy badawcze o nazwie Graffiti oferują radykalnie inną wizję: każdy może stworzyć własną aplikację społecznościową, która dokładnie odpowiada potrzebom jego społeczności, nie tracąc przy tym istniejących kontaktów ani swoich danych. Jest to warstwa komunikacyjna i danych przeznaczona do prostego tworzenia spersonalizowanych narzędzi społecznościowych za pomocą typowych technologii front-endowych (HTML, CSS, JavaScript), z wbudowaną interoperacyjnością między różnymi aplikacjami oraz własnością użytkownika nad danymi przechowywanymi na zdecentralizowanej infrastrukturze.

Dlaczego spersonalizowane aplikacje społecznościowe w ogóle powinny istnieć

Wyobraźmy sobie niezależny klub koncertowy, który chce gromadzić lokalną publiczność wokół nowych wykonawców: wymiana rekomendacji, krótkie fragmenty z prób, szybkie ankiety przed programem, listy piosenek po występie... Wszystko to może zmieścić się w jednej specjalistycznej aplikacji społecznościowej, skrojonej na miarę mikro-społeczności. Problem pojawia się w momencie, gdy - dla takiej personalizacji - publiczność musi „przenieść się” do nowego serwisu i tam od nowa budować swój graf społeczny, podczas gdy twórcy aplikacji muszą opanować i utrzymywać złożony back-end. Graffiti przełamuje to błędne koło na dwa sposoby: upraszcza rozwój, oferując wspólną warstwę tła, do której dostęp mają wszystkie aplikacje, a jednocześnie gwarantuje, że posty i powiązania społeczne mogą być widoczne i używane w każdej kompatybilnej aplikacji, bez utraty ciągłości między ludźmi.

Kluczowa idea: interoperacyjność bez zgody właściciela platformy

W przeciwieństwie do konwencjonalnych sieci społecznościowych, w których interoperacyjność jest zwykle ograniczona do API zdefiniowanych przez właściciela platformy, Graffiti proponuje poziom protokołu, na którym wszystkie działania społeczne są „przekształcane” w dane, które można odczytywać, udostępniać i interpretować w różnych aplikacjach klienckich. Takie podejście autorzy nazywają całkowitą reifikacją: każda interakcja – od posta i odpowiedzi po polubienie, zablokowanie, zgłoszenie czy moderację – jest zapisywana jako osobny artefakt danych. Aplikacje następnie według własnych zasad decydują, jak te artefakty wyświetlić (lub zignorować), co pozwala na jednoczesne wdrażanie różnych polityk i filozofii projektowych na tym samym grafie społecznym.

W praktyce oznacza to, że społeczności mogą wybierać własnych moderatorów i własne zasady, a przy tym nadal pozostawać „w tej samej sieci” z innymi. Jeśli jedna aplikacja zdecyduje się ukryć posty, które dana osoba oznaczyła jako nieodpowiednie, inna aplikacja może użyć tego samego zestawu metadanych tylko do ostrzeżenia lub do rankingu. Moderacja w ten sposób z monolitycznej, scentralizowanej interwencji przeradza się w konkurencję polityk i narzędzi, które wybierają użytkownicy.

Rozwiązywanie „zapaści kontekstu” za pomocą kanałów

Interoperacyjność ma też ciemną stronę: treści stworzone dla jednej publiczności mogą trafić do zupełnie innej. To zjawisko, znane w literaturze jako zapaść kontekstu (ang. context collapse), może powodować nieporozumienia i szkody społeczne, gdy wiadomość zostanie wyrwana z zamierzonego kontekstu. Graffiti adresuje ten problem za pomocą koncepcji kanałów. Kanał to elastyczne „ogrodzenie” wokół wiadomości (lub całego wątku), które reprezentuje określony kontekst – osobę, aplikację, organizację, lokalizację, wydarzenie lub jednostkę tematyczną. Posty widoczne w jednym kanale nie muszą automatycznie „przeciekać” do drugiego; autor może precyzyjniej określić publiczność i tym samym zapobiec niechcianemu mieszaniu się kontekstów.

Rozwój front-endu bez ciężkiego back-endu

Jedną z atrakcyjnych ambicji frameworka jest obniżenie progu wejścia dla rozwoju aplikacji społecznościowych. Ponieważ przechowywanie treści i wymiana danych odbywają się na wspólnej, rozproszonej infrastrukturze, autorzy podkreślają, że możliwe jest budowanie funkcjonalnych klientów społecznościowych przy użyciu wyłącznie narzędzi front-endowych: HTML-a, CSS-a, bibliotek komponentów lub popularnych frameworków, takich jak Vue. Zamiast pisać i utrzymywać własne serwery, Graffiti standaryzuje sposób zapisywania i pobierania reifikowanych zdarzeń, co pozwala przekierować energię na doświadczenie użytkownika, polityki bezpieczeństwa po stronie klienta i szybką iterację nowych funkcji.

Własność danych i przenośna tożsamość

Centralna obietnica zdecentralizowanych sieci społecznościowych brzmi: użytkownicy zachowują dane i tożsamość nawet po zmianie aplikacji. Graffiti operacjonalizuje to w ten sposób, że dane nie „należą” do klienta, lecz znajdują się w rozproszonej pamięci, z którą mogą łączyć się różne klienty. Tożsamość i graf społeczny stają się przy tym przenośne, więc zmiana aplikacji nie oznacza już utraty połączeń. Taka architektura idzie w parze z szerszymi trendami w zdecentralizowanej sieci społecznościowej, która od lat bada, jak uniknąć uwięzienia w silosach – od standardu ActivityPub, który napędza fediwersum, po nowsze podejścia, takie jak AT Protocol, na którym powstaje szereg interoperacyjnych aplikacji.

Czym Graffiti różni się od istniejących zdecentralizowanych protokołów

ActivityPub (rekomendacja W3C z 2018 r.) opiera się na federacji serwerów, które wymieniają aktywności w formacie ActivityStreams 2.0; korzystają z niego Mastodon i inne serwisy fediwersum. AT Protocol, który stoi za rosnącym ekosystemem aplikacji, oferuje przenośne tożsamości i oddzielenie przechowywania od klientów, a także elastyczne algorytmiczne kanały i otwarte narzędzia do moderacji. Graffiti dzieli z nimi cel przenośności tożsamości i danych, ale wyróżnia się właśnie całkowitą reifikacją działań społecznych i uniwersalnym, agnostycznym wobec aplikacji modelem danych, w którym nawet sama moderacja jest zapisywana jako dane. Ten poziom reprezentacji ułatwia współistnienie sprzecznych zasad i pozwala różnym społecznościom na jednoczesne wdrażanie własnych polityk widoczności i zachowania na tym samym grafie.

Przykłady użycia: od scen kulturalnych po zespoły robocze

Autorzy zademonstrowali już kilka aplikacji powstałych na bazie frameworka – od interfejsu mikroblogowego przypominającego „klasyczne” sieci społecznościowe po wspólne redagowanie treści w stylu encyklopedii, wymianę krótkich wiadomości w czasie rzeczywistym i dedykowane aplikacje dla lokalnych społeczności. W konkretnym, pozornie skromnym przykładzie klubu koncertowego, Graffiti umożliwia publiczności otwieranie kanałów tematycznych (np. według gatunków, wykonawców lub sal), udostępnianie fragmentów i playlist, a moderatorzy – wybierani przez samą społeczność – ustalają zasady widoczności, bez obawy, że te wytyczne „zaleją” profile użytkowników poza kontekstem kanału muzycznego.

Jest to równie stosowalne w środowiskach zawodowych: zespoły mogą stworzyć minimalne narzędzie do szybkiej koordynacji z wątkami według projektów, podczas gdy zachowania takie jak „polubienie”, „ping” czy „eskalacja” są zapisywane jako dane, które inne klienty mogą przetłumaczyć na własne wzorce interfejsu użytkownika. Rezultatem jest mozaika kompatybilnych aplikacji o różnej estetyce i głębi, ale z tym samym społecznym „rezerwuarem”.

Moderacja jako rynek usług, a nie centralne polecenie

Powszechny zarzut wobec systemów zdecentralizowanych dotyczy egzekwowania zasad: kto „usuwa” nielegalne lub szkodliwe treści? Graffiti nie oferuje jednej policji treści, ale umożliwia konkurencyjnym serwisom moderacyjnym działanie na tym samym społecznym zbiorze danych. Użytkownicy – lub całe społeczności – wybierają jedną lub więcej usług, przy czym decyzje (znaczniki, blokady, ostrzeżenia) są zapisywane jako reifikowane zdarzenia. Aplikacje następnie interpretują te zdarzenia zgodnie z własnymi zasadami. Unika się w ten sposób jednego standardu, który jest z konieczności zbyt sztywny dla różnorodnych kontekstów kulturowych i prawnych, ale otwiera to również poważne pytania badawcze o granice ochrony osobistej i zbiorowej.

Bezpieczeństwo, prywatność i granice interoperacyjności

Niezależnie od podejścia do interoperacyjności, pozostaje nierozwiązane napięcie między otwartością a zapobieganiem rozprzestrzenianiu się treści poza zamierzoną publiczność. Kanały pomagają, ale nie zdejmują odpowiedzialności z projektantów klientów i opiekunów społeczności za zdefiniowanie rozsądnych domyślnych ustawień widoczności, możliwości „rozwidlania” wątków w bardziej zamknięte przestrzenie, a także jasnych sygnalizatorów kontekstu. Ponadto, reifikacja blokad i skarg tworzy metadane, które – jeśli nie zostaną zabezpieczone – mogą ujawnić wzorce relacji społecznych. Wzmacnianie prywatności wymaga zatem mechanizmów kryptograficznych, podejść typu „selective disclosure” i surowych zasad przechowywania danych, co autorzy zapowiedzieli jako przyszły kierunek rozwoju.

Status badawczy i wyróżnienia

Praca, która systematycznie przedstawia koncepcję i implementację Graffiti, została zaprezentowana na corocznej konferencji UIST 2025, która odbyła się od 28 września do 1 października 2025 r. w Pusan. W programie konferencji wymieniono właśnie tę publikację autorstwa Theia Henderson, David R. Karger i David D. Clark, a praca została również zaliczona do nagrodzonych prac konferencji. Dostępny jest także recenzowany rękopis w otwartym dostępie.

Sam kontekst badawczy wpisuje się w wieloletnie dążenia społeczności akademickich i technologicznych do budowy zdecentralizowanych systemów informacyjnych, które zwracają użytkownikom kontrolę nad danymi i tożsamością – tradycję, którą na MIT symbolicznie reprezentuje również praca grup poświęconych paradygmatom zdecentralizowanej sieci.

Porównanie paradygmatów projektowych: co oznacza „komponowalna” sieć społecznościowa

W sieci semantycznej mieliśmy już szereg prób standaryzacji komunikacji za pomocą ogólnych obiektów i działań (np. ActivityStreams). Graffiti przywraca tego ducha po stronie klienta i czyni go praktycznym do budowy aplikacji: zamiast dostosowywać się do jednej „głównej” aplikacji, która określa, jak wygląda post, odpowiedź czy zgłoszenie, Graffiti standaryzuje reprezentację zdarzeń, podczas gdy interfejs, przepływy i zasady interpretacji pozostają kwestią wyboru. Stąd wynika również jedna nieoczekiwana konsekwencja: łatwiej jest budować „mosty” między protokołami (np. w kierunku fediwersum lub ekosystemu AT-protocol), ponieważ tłumaczenie odbywa się na poziomie zdarzeń, a nie przez przymusowe klonowanie całej logiki platformy.

Co to oznacza dla twórców treści i małych organizacji

Dla lokalnych mediów, organizacji kulturalnych, szkół, stowarzyszeń i startupów największą przeszkodą do tej pory była kombinacja złożoności technicznej i ryzyka „pustego pokoju”. Jeśli społeczność musi opuścić istniejącą sieć, projekt z trudem się rozwija. Graffiti stawia czoła temu problemowi, oferując trzy praktyczne korzyści: (1) tworzenie MVP wyłącznie za pomocą front-endu, (2) przenośność tożsamości i danych bez „resetowania” powiązań społecznych oraz (3) natywną interoperacyjność, która pozwala, aby posty z jednej aplikacji były widoczne w drugiej – bez przymusu jednolitego projektu czy scentralizowanych zasad.

Przykładowe scenariusze i wzorce użytkowania

• Mikroblog dla dzielnic miejskich: kanały według osiedli i tematów (harmonogram wydarzeń, wezwania do wolontariatu, rzeczy znalezione); w każdym kanale inne zasady moderacji, które społeczność wybiera poprzez „subskrypcję” serwisów moderacyjnych.


• Spółdzielnia redakcyjna: redagowanie tekstów w formie „wątków wiki”, gdzie zmiany, recenzje i oceny jakości są również reifikowanymi zdarzeniami; inny klient może te same dane wyświetlić jako klasyczny przepływ recenzji.


• Scena muzyczna: posty z prób, setlisty i nagrania z występów podróżują przez kanały wykonawców, klubów i promotorów; publiczność wybiera klienta z naciskiem na audio, ktoś inny klienta z wątkami forum – wszyscy mają wspólny ten sam zbiór danych.


• Zespoły robocze: łatwe integracje z innymi protokołami i serwisami: tożsamość jest przenośna, więc przejście na nowego klienta nie zakłóca sieci kontaktów; polityki moderacyjne mogą naśladować wzorce „code-review”.

Szerszy obraz: wyścig o interoperacyjną warstwę społeczną

Ostatnie dwa lata przyniosły gwałtowny rozwój inicjatyw, które chcą uniknąć zależności od jednej firmy: fediwersum oparte na ActivityPub rozszerza się poprzez różne oprogramowanie i integracje, podczas gdy ekosystem oparty na AT-protocol odnotowuje wzrost liczby aplikacji i użytkowników oraz kampanie podkreślające „interesy publiczne” i rekonfigurację własności infrastruktur. Graffiti wpisuje się w ten krajobraz jako propozycja badawcza, która maksymalnie uwalnia klientów – programiści mogą wprowadzać innowacje na poziomie doświadczenia i funkcji, nie naruszając przy tym interoperacyjności.

Otwarte pytania i przyszły rozwój

Jak daleko może posunąć się „osobista” moderacja, zanim stanie się nieskuteczna wobec zorganizowanego nadużycia? Jak zapobiec wykorzystywaniu reifikowanych zdarzeń (szczególnie tych wskazujących na konflikty społeczne) jako narzędzia do doxxingu lub celowego nękania? Jakie są minimalne standardy bezpieczeństwa kanałów potrzebne, aby uniknąć rekonstrukcji prywatnych sieci z metadanych? I wreszcie, gdzie pociągnąć granicę między swobodą projektowania a odpowiedzialnością wobec najbardziej wrażliwych grup użytkowników? Autorzy projektu zapowiedzieli już dalsze ulepszenia techniczne – od narzędzi do graficznego tworzenia klientów po silniejsze mechanizmy ochrony prywatności i bezpieczeństwa – ale także badania podłużne nad wpływem na zachowanie społeczności.

Dla kogo Graffiti jest przeznaczone już dziś

Największe korzyści od razu mogą odnieść organizacje i twórcy, którzy chcą szybkiej, tematycznie ukierunkowanej interakcji społecznej bez budowania back-endu i bez „wyprowadzania” publiczności: lokalne media i instytucje kultury, społeczności edukacyjne, zespoły open-source i stowarzyszenia. Z pewną wiedzą na temat front-endu i jasnym pomysłem na kanały i zasady, mogą stworzyć własnego klienta, włączyć się w istniejące przepływy treści i przy tym zachować własność nad tym, co produkują. Dla szerszego zastosowania – od masowych dyskusji publicznych po wrażliwe tematy – kluczowa będzie jakość serwisów moderacyjnych, ergonomia klientów i standardy ochrony prywatności uzgodnione przez społeczność.

Jak zacząć: wskazówki projektowe dla pierwszego eksperymentu

1. Zdefiniuj kanały i publiczność: przed stworzeniem interfejsu użytkownika, zmapuj konteksty (osoby, zespoły, lokalizacje, wydarzenia) i zdecyduj, gdzie jakie treści mogą się pojawiać, aby uniknąć zapaści kontekstu. Wprowadź jasne wizualne oznaczenia kontekstu i domyślne ustawienia prywatności.


2. Modeluj interakcje jako dane: zdecyduj, które działania będą reifikowane (oceny jakości, role, blokady, zgłoszenia, eskalacje) i jak Twoja aplikacja będzie je interpretować. Zaplanuj możliwość, że inny klient zinterpretuje te same zdarzenia inaczej.


3. Wybierz serwisy moderacyjne: zacznij od co najmniej dwóch niezależnych usług, aby przetestować współistnienie różnych polityk. Dodaj w interfejsie jasne wskazanie źródła decyzji moderacyjnych.


4. Zapewnij przenośną tożsamość: zaplanuj integracje z protokołami, które ułatwiają migrację i zachowanie grafu społecznego oraz wskaż użytkownikom, gdzie przechowywane są ich dane.


5. Iteruj z użytkownikami: ponieważ tworzenie klientów jest łatwe, używaj szybkich cykli prototypowania; obserwuj wpływ na kulturę komunikacji, zwłaszcza ponad granicami kanałów.