At a time when digital social life is increasingly taking place within closed, uniquely designed applications, a new research framework called Graffiti offers a radically different vision: anyone can create their own social application that precisely fits the needs of their community, without losing existing contacts or their data. It is a communication and data layer designed for the simple creation of personalized social tools using typical front-end technologies (HTML, CSS, JavaScript), with built-in interoperability between different applications and user ownership of data stored on a decentralized infrastructure.

Why personalized social applications should even exist

Imagine an independent concert venue that wants to gather a local audience around new performers: exchanging recommendations, short clips from rehearsals, quick polls before the show, setlists after the performance... All of this can fit into one specialized social application tailored to the micro-community. The problem arises the moment when—for the sake of such personalization—the audience has to "move" to a new service and rebuild their social graph there, while the application creators have to master and maintain a complex back-end. Graffiti breaks this vicious circle in two ways: it simplifies development by offering a common background layer that all applications access, and at the same time, it guarantees that posts and social connections can be seen and used in every compatible application, without loss of continuity between people.

The key idea: interoperability without the platform owner's consent

Unlike conventional social networks where interoperability is usually limited to APIs defined by the platform owner, Graffiti proposes a protocol level where all social actions are "turned into" data that can be read, shared, and interpreted in different client applications. The authors call this approach total reification: every interaction—from a post and reply to a like, block, report, or moderation—is recorded as a separate data artifact. Applications then decide according to their own rules how to display (or ignore) these artifacts, allowing different policies and design philosophies to be simultaneously implemented on the same social graph.

In practice, this means that communities can choose their own moderators and their own rules, while still remaining "on the same network" with others. If one application decides to hide posts that a certain person has marked as inappropriate, another application can use the same set of meta-data just for a warning or for ranking. Moderation thus transforms from a monolithic, centralized intervention into a competition of policies and tools that users choose.

Solving "context collapse" with channels

Interoperability also has a dark side: content created for one audience can end up in front of a completely different one. This phenomenon, known in literature as context collapse, can cause misunderstandings and social harm when a message is taken out of its intended frame. Graffiti addresses this with the concept of channels. A channel is a flexible "fence" around a message (or an entire thread) that represents a specific context—a person, an application, an organization, a location, an event, or a thematic unit. Posts visible in one channel do not have to automatically "leak" into another; the author can more finely define the audience and thereby prevent unwanted mixing of contexts.

Front-end development without a heavy back-end

One of the framework's attractive ambitions is to lower the entry barrier for social application development. As content storage and data exchange run on a common, distributed infrastructure, the authors emphasize that it is possible to build functional social clients with only front-end tools: HTML, CSS, component libraries, or popular frameworks like Vue. Instead of teams writing and maintaining their own servers, Graffiti standardizes the way reified events are stored and retrieved, thereby allowing energy to be redirected to user experience, client-side security policies, and rapid iteration of new features.

Data ownership and portable identity

The central promise of decentralized social networks is: users retain their data and identity even when they change applications. Graffiti operationalizes this by ensuring that data does not "belong" to the client but is located in distributed storage to which different clients can connect. Identity and the social graph thereby become portable, so changing applications no longer means losing connections. Such an architecture is in step with broader trends in the decentralized social web, which has been exploring for years how to avoid being trapped in silos—from the ActivityPub standard that powers the fediverse, to newer approaches like the AT Protocol on which a series of interoperable applications are being built.

How Graffiti differs from existing decentralized protocols

ActivityPub (a W3C recommendation from 2018) relies on a federation of servers that exchange activities in the ActivityStreams 2.0 format; it is used by Mastodon and other fediverse services. The AT Protocol, which is behind a growing ecosystem of applications, offers portable identities and separation of storage from clients, as well as flexible algorithmic feeds and open moderation tools. Graffiti shares with them the goal of identity and data portability, but it stands out precisely because of the total reification of social actions and a universal, application-agnostic data model where moderation itself is recorded as data. This level of representation facilitates the coexistence of conflicting rules and allows different communities to simultaneously enforce their own visibility and behavior policies on the same graph.

Use cases: from cultural scenes to work teams

The authors have already demonstrated several applications built on the framework—from a microblogging interface similar to "classic" social networks to collaborative content editing in the style of an encyclopedia, real-time exchange of short messages, and dedicated applications for local communities. In the concrete, seemingly modest example of the concert venue, Graffiti allows the audience to open thematic channels (e.g., by genre, artists, or venues), share clips and playlists, and moderators—chosen by the community itself—set visibility rules, without fear that these determinants will "flood" users' profiles outside the context of the music channel.

It is equally applicable in professional environments: teams can assemble a minimal tool for quick coordination with threads per project, while behaviors like "liking," "pinging," or "escalating" are recorded as data that other clients can translate into their own UI patterns. The result is a mosaic of compatible applications with different aesthetics and depths, but with the same social "reservoir."

Moderation as a market of services, not a central command

A common objection to decentralized systems concerns the enforcement of rules: who "takes down" illegal or harmful content? Graffiti does not offer a single content police force but enables competing moderation services to act on the same social data set. Users—or entire communities—choose one or more services, whereby decisions (tags, blocks, warnings) are recorded as reified events. Applications then interpret these events according to their own rules. This avoids a single standard that is necessarily too rigid for diverse cultural and legal contexts, but it also opens up serious research questions about the limits of personal and collective protection.

Security, privacy, and the limits of interoperability

However one approaches interoperability, an unresolved tension remains between openness and preventing the spread of content beyond its intended audience. Channels help, but they do not remove the responsibility of client designers and community stewards to define reasonable default visibility settings, the ability to "branch" threads into more private spaces, and clear context signalers. In addition, the reification of blocks and complaints creates metadata that—if not protected—can reveal patterns of social relationships. Strengthening privacy therefore implies cryptographic mechanisms, "selective disclosure" approaches, and strict data retention policies, which the authors have announced as a future direction for development.

Research status and acknowledgments

The paper that systematically presents the concept and implementation of Graffiti was presented at the annual UIST 2025 conference, held from September 28 to October 1, 2025, in Busan. The conference program lists this very publication authored by Theia Henderson, David R. Karger, and David D. Clark, and the paper was also included among the conference's award-winning papers. A peer-reviewed manuscript is also available in open access.

The research context itself fits into the multi-year efforts of academic and technological communities to build decentralized information systems that give users back control over their data and identity—a tradition at MIT symbolically represented by the work of groups dedicated to decentralized web paradigms.

Comparison of design paradigms: what a "composable" social web means

In the semantic web, we have already had a series of attempts to standardize communication through generic objects and activities (e.g., ActivityStreams). Graffiti brings that spirit back to the client side and makes it practical for building applications: instead of adapting to one "main" application that dictates what a post, reply, or report looks like, Graffiti standardizes the representation of events, while the interface, flows, and interpretation rules remain a matter of choice. This leads to an unexpected consequence: it is easier to build "bridges" between protocols (e.g., to the fediverse or the AT-protocol ecosystem) because the translation is done at the event level, not through the forced cloning of the entire platform logic.

What this means for content creators and small organizations

For local media, cultural organizations, schools, associations, and startups, the biggest obstacle so far has been the combination of technical complexity and the risk of an "empty room." If the community has to leave its existing network, the project struggles to take off. Graffiti tackles this by offering three practical benefits: (1) creating an MVP with only the front-end, (2) portability of identity and data without "resetting" social connections, and (3) native interoperability that allows posts from one application to be visible in another—without being forced into a single design or centralized rules.

Example scenarios and usage patterns

• Microblog for city districts: channels by neighborhoods and topics (event schedules, calls for volunteers, lost-and-found); in each channel, different moderation rules that the community chooses by "subscribing" to moderation services.


• Editorial cooperative: editing texts in the form of "wiki-threads" where changes, reviews, and quality tags are also reified events; another client can display the same data as a classic peer-review flow.


• Music scene: posts from rehearsals, set-lists, and recordings from gigs travel through channels of performers, clubs, and promoters; the audience chooses a client with a focus on audio, someone else a client with forum-style threads—all share the same set of data.


• Work teams: easy integrations with other protocols and services: identity is portable, so switching to a new client does not disrupt the contact network; moderation policies can mimic "code-review" patterns.

The bigger picture: the race for an interoperable social layer

The last two years have brought a surge of initiatives aiming to avoid dependence on a single company: the fediverse based on ActivityPub is expanding through various software and integrations, while the ecosystem based on the AT-protocol is seeing growth in the number of applications and users, as well as campaigns emphasizing "public interests" and the reconfiguration of infrastructure ownership. Graffiti fits into this landscape as a research proposal that maximally liberates clients—developers can innovate at the level of experience and functions without breaking interoperability.

Open questions and future development

How far can "personal" moderation go before it becomes ineffective against organized abuse? How to prevent reified events (especially those pointing to social conflicts) from being used as a tool for doxxing or targeted harassment? What are the minimum security standards for channels needed to avoid reconstructing private networks from meta-data? And finally, where to draw the line between design freedom and responsibility towards the most vulnerable user groups? The project authors have already announced further technical improvements—from tools for graphically composing clients to stronger privacy and security mechanisms—as well as longitudinal studies on the effects on community behavior.

Who is Graffiti for today

The greatest immediate benefit can be drawn by organizations and creators who want quick, thematically focused social interaction without building a back-end and without "moving out" their audience: local media and cultural institutions, educational communities, open-source teams, and associations. With some front-end knowledge and a clear idea about channels and rules, they can assemble their own client, join existing content flows, and retain ownership of what they produce. For broader application—from mass public discussions to sensitive topics—the quality of moderation services, client ergonomics, and privacy protection standards agreed upon by the community will be crucial.

How to get started: design guidelines for a first experiment

1. Define channels and audience: before creating the UI, map out the contexts (people, teams, locations, events) and decide where which content may appear to avoid context collapse. Introduce clear visual context markers and default privacy settings.


2. Model interactions as data: decide which actions will be reified (quality tags, roles, blocks, reports, escalations) and how your application will interpret them. Plan for the possibility that another client will interpret the same events differently.


3. Choose moderation services: start with at least two independent services to test the coexistence of different policies. Add a clear display of the source of moderation decisions in the interface.


4. Ensure portable identity: plan integrations with protocols that facilitate migration and retention of the social graph and indicate to users where their data is stored.


5. Iterate with users: since building clients is easy, use rapid prototyping cycles; monitor the effects on the culture of communication, especially across channel boundaries.