DSNP Blog

Reflecting on 2025: A Year of Growth for DSNP

Mon, 15 Dec 2025 00:00:00 +0000

As we close the year, it is clear that 2025 marked a pivotal chapter for the Decentralized Social Networking Protocol (DSNP) with the main objective to build and strengthen our governance community. Through convenings, publications, and strategic stakeholder engagement, Project Liberty Institute (PLI) as a steward of DSNP, advanced its mission of community participation and alignment with global open digital infrastructure efforts.

Building the Community as a Path Towards Progressive Decentralization

In the first half of the year, we set the stage for DSNP’s broader impact. At RightsCon Taiwan, Sarah Nicole, Policy & Research Manager Governance Lead at Project Liberty Institute together with DSNP advisors and global leaders Audrey Tang and Wendy Seltzer convened over 40 participants to kick off a series of global workshops with the community.

Simultaneously, we launched the first DSNP Community Governance Working Group online meeting, open to the public, starting with a dozen participants. This monthly gathering established the foundation of our ongoing multi‑stakeholder governance community, laying the groundwork for recurring governance structures, feedback on our framework, and early ecosystem partnerships that will endure.

Throughout 2025 we have gathered seven DSNP Community Governance Working Group online meetings. This first series of convenings concluded with two leadership sessions, featuring Project Liberty Institute CEO Sheila Warren and DSNP co-creator and Project Liberty CTO Braxton Woodham. The two sessions highlighted the crucial role of governance especially as we move into an agentic web, and outlined PLI and DSNP strategic direction for 2026.

Governance Expansion & Policy Engagement

In the second half of the year, we doubled down on our efforts, strengthening participation in governance, embedding DSNP within influential policy fora, and expanding awareness across the digital governance ecosystem.

Sarah Nicole, together with Wendy Seltzer and Wes Biggs, Vice President and Chief Architect at Project Liberty, organized the second DSNP convening at the Internet Governance Forum, modeled on our RightsCon format. We also co‑facilitated a workshop with the Digital Public Goods Alliance on open protocols, held at the Norwegian Agency for Development Cooperation.

Additionally, we delivered a DSNP “deep dive” at the Global Digital Collaboration Conference with our partners at Harvard’s Applied Social Media Lab, attracting a full room of participants, at least one of whom traveled internationally specifically because of their involvement in the DSNP Governance Working Group.

Aspiring to have our governance process as transparent as possible, we regularly gave updates to the broader ecosystem through publications such as the Project Liberty newsletter on DSNP’s governance journey. Additionally, with our advocacy efforts across diverse policy fora, we ensured DSNP and data‑agency concepts were embedded in the T7 Summit communiqué through our contribution with a T7 policy brief, thereby placing open protocols like DSNP within G7‑level policy recommendations.

These engagements in 2025 expanded DSNP’s legitimacy across diverse global ecosystems from the UN to civil society, to the DPI and G7-level discussions.

Looking out to 2026

The DSNP Governance Framework has now been reviewed by more than 100 stakeholders across the world between 2024 and 2025. In particular, the DSNP Governance Community Working Group during its monthly meetings has been instrumental in getting us to the finalized version, which will be published in early 2026, when the first DSNP steering committee will be elected.

With a consolidated community and the first ever DSNP governance framework, we are excited to step into 2026, a year that promises more growth for DSNP, with a broadening of its mission to go beyond social data to encompass human data in the age of AI. The DSNP Governance Community Working Group will keep on being central to DSNP development throughout 2026.

If you wish to join the DSNP governance adventure in 2026 please reach out to: dsnpfeedback@projectliberty.io

Expanding the Decentralized Social Networking Protocol (DSNP) Community at RightsCon, Taiwan

Wed, 05 Mar 2025 00:00:00 +0000

Stewardship of the Decentralized Social Networking Protocol (DSNP), a public-interest infrastructure protocol available as a public utility, is central to Project Liberty Institute’s mission.

Over the past year, the DSNP Advisory Council and its Governance Working Group chaired by our advisor, Wendy Seltzer, and led by Research & Policy Manager, Sarah Nicole, have been developing DSNP governance, producing foundational documents that structure the development of the protocol and its relation to the ecosystem. It was time to put those ideas into practice.

Since DSNP is about helping people reclaim control of their digital lives, fostering voice, choice, and stake in a better digital ecosystem, its governance should reflect and support those principles.

Last month at RightsCon Taiwan, the DSNP community took a major step forward. As an official RightsCon Satellite event, Project Liberty Institute hosted the first DSNP community meeting, drawing a full room of over 40 participants.

Participants included representatives from Aapti Institute, CIGI, Creative Commons, Integrity Institute, Metagov, Mozilla Foundation, Open Data Charter, Wikimedia Foundation, independent developers, tech experts, and France’s Digital Ambassador. Beyond helping more people connect with Project Liberty’s work, we aim to foster interconnection among the supporters of the decentralized social web.

The session was co-facilitated by Wendy Seltzer, DSNP advisor & chair of the DSNP Governance Working Group, Audrey Tang, DSNP advisor & Project Liberty Senior Fellow, and Sarah Nicole, Research & Policy Manager.

Under the Chatham House Rule, discussions spanned a wide range of challenges and opportunities for building sustainable, decentralized governance. Participants explored not just technical solutions but the human dynamics that shape effective governance models, drawing examples from their extensive experience in community organizing and decentralization.

Participants were enthusiastic about DSNP’s role as a dependable, censorship-resistant fallback for social feeds. DSNP is not seeking to compete with or overtake other decentralized efforts. Instead, DSNP aims to complement them with a “credible exit” option, affording user choice and pushing platforms to prioritize users.

Key insights included:

Community-led success often comes from a clear sense of immediate purpose (e.g., crisis response, defending communal resources, offering an alternative to exploitative platforms).
Sustainability hinges on the transfer of governance knowledge, robust documentation, rotating leadership, and inclusive ways of onboarding.
Incentives need to balance intrinsic motivations (friendship, personal growth, shared values) with careful application of extrinsic rewards (stipends, grants, vouchers).
Ephemerality is Natural: Some decentralized projects serve their moment. Knowing when to let them fade—or how to hand them off—avoids burnout and resentment.
Incremental steps help people to see their path from the starting point to a bigger contribution.
Bridging Communities is a further step: weaving together small-scale successes into broader networks that share knowledge, resources, and protocols.

These insights underscore that sustainable decentralization goes beyond the initial spark of community empowerment. It depends on the structures and cultural norms that allow new people to join, contribute meaningfully, and eventually take the reins themselves.

Following RightsCon, Project Liberty Institute and DSNP are committed to further engaging our community, beginning with inviting participants to DSNP governance working meetings. The DSNP Draft Governance Framework and the Mission & Principles will be refined with the feedback received during the session, and we look forward to sharing a roadmap of Progressive Decentralization.

The momentum behind DSNP is growing, and there is increasing interest in shaping the future of an open, community-driven social web. Sarah Nicole also joined the panel “How we Build the Social Web” along with Mallory Knodel from Social Web Foundation, Andy Piper from Mastodon, and Palak Sheth from Threads. It was another opportunity to share how DSNP acts as a bridge between different platforms and protocols to build a social web that gives users voice, choice, and stake in their digital lives.

If you want to be part of this journey, now is the time to get involved: dsnpfeedback@projectliberty.io

Community Governance of Decentralized Social Protocols: A DSNP Convening at RightsCon 2025

Wed, 12 Feb 2025 00:00:00 +0000

Project Liberty Institute (PLI) is hosting an initial convening at RightsCon 2025 to discuss the collaborative governance of the Decentralized Social Networking Protocol (DSNP). This event will bring together decentralized social media projects, community organizers, and digital rights advocates to explore governance challenges and solutions in decentralized networks.

As decentralized communication platforms grow, so do the governance challenges they face. How can users, developers, and community members ensure these platforms remain responsive to their needs? This gathering will provide a unique opportunity to share experiences, explore governance models, and build cross-cutting policy networks.

Event Highlights:

Participant-Driven Discussions: Moderated by decentralized technology leaders Wendy Seltzer and Audrey Tang, these interactive sessions will focus on gaining insights from participants on governance challenges and best practices.
Blockchain Governance Toolkit Deployment: Discover cutting-edge tools designed to facilitate transparent and decentralized decision-making processes.
Interactive Peer Exchange Sessions: A series of dynamic discussions and collaborative workshops featuring top practitioners, policymakers, and innovators in the field.

With over 1.5 million users worldwide, DSNP is on its path toward progressive decentralization with the goal of empowering individuals with a voice, choice, and stake in their digital lives. This convening will serve as a key milestone in this journey, gathering feedback on the many governance documents published throughout 2024. Most importantly, this event will serve as a launchpad for ongoing collaborations, with further convenings planned across different regions in 2025.

Join us at RightsCon 2025 on February 24th, 2025, to take part in shaping the future of decentralized governance and ensuring digital networks serve their communities.

For more information contact: institute@projectliberty.io

DSNP Governance Next Steps: A Roadmap for Decentralization

Wed, 06 Nov 2024 00:00:00 +0000

In these last months the DSNP governance working group collected valuable feedback from experts and our community on the first draft governance framework.

This feedback sparked discussions which led us to update our action plan for the upcoming phases in our journey toward decentralization.

Phase 1: Mapping & Definitions

Our first focus is on establishing a shared understanding of key concepts that guide our thinking and actions, such as governance, community, ecosystem, and decentralization, in the context of DSNP. We recognize that every discipline has a unique set of terms with specific interpretations, so here is how we are using these terms for DSNP governance.

We will conduct a community & governance comparative analysis in collaboration with the Comparative Analysis Working Group (CA-WG), drawing insights from similar governance systems to clarify our approach. This includes mapping relevant resources and protocol comparisons to integrate best practices and support the design of our decision-making process.

This phase will also define the scope of our protocol governance and explore its relationship with other layers of governance. This scope will be useful for various stakeholders to engage with their preferred layer of governance depending on their areas of concern.

Phase 2: Minimum Viable Decentralization

In November of 2024, the Project Liberty Summit will take place, where participants will have direct access to the DSNP governance work, making this an opportunity to gather additional feedback.

This phase will most importantly include compiling a Playbook for Progressive Decentralization, which will serve as a practical guide for our roadmap towards more decentralization. This playbook will eventually help us refine our Draft Governance Framework.

Additionally, we will develop metrics to evaluate our progress, ensuring that we stay aligned with our goals and are later held accountable based on our mission and principles.

Together, these phases will lay a solid foundation for our commitment to effective and inclusive decentralization.

As always, please feel free to reach out with questions, comments, thoughts by email to dsnpfeedback@projectliberty.io or on the DSNP Forum.

Sarah Nicole is a Senior Policy & Research Associate for Project Liberty Institute.

Announcing the release of DSNP 1.3

Thu, 26 Sep 2024 00:00:00 +0000

The DSNP community has completed work on the next update to the protocol specification, and version 1.3.0 has been published to the specification website. This new release contains several enhancements and new features, summarized below.

Bringing out our best attributes

DSNP 1.3 brings the concept of verifiable attribute sets to the protocol, and defines how they can be used in a variety of different contexts. Attribute sets are structured data describing someone or something. By establishing a framework for defining and using shared data schemas for attribute sets, DSNP enables the community of applications to collaborate on building a rich language of metadata about users, posts, and more. The specification adds three new types of announcements, allowing verifiable attributes relevant to DSNP users, DSNP content, and external content. Use cases for attribute sets include verified user badges, display of professional accreditations, content provenance, community content tagging and much more. Higher level concepts, such as application-independent content moderation systems and reputation scoring services, become possible with these foundations.

To represent the notion of attested, verifiable attribute sets, DSNP 1.3 adds a new sub-specification detailing interoperability with the W3C Verifiable Credentials body of standards. Attribute sets and attestation take the form of Verifiable Credentials, aligning with important work within the W3C standards process.

Keys are key

Public key encryption and signatures are core to DSNP’s concept of user agency and data security. Core enough, in fact, that the specification now mandates that a user’s public keys must be directly retrievable as user data from the consensus system, instead of being announced as part of a user’s content stream. This enables social graph encryption, pseudonymous relationship identifier generation, and verification of credentials to occur without the need for external indexing or data caching. This also allows DSNP to specify standard Decentralized Identifier (DID) documents, enabling paradigmatic access to a user’s public keys in accordance with the W3C recommendation. The “key agreement” key type is used for social graph encryption and relationship discovery, and the “assertion method” key type is used for issuers of verifiable credentials.

Higher-profile profiles

A great deal of community discussion went into DSNP 1.3 in Zoom meetings, github discussions, and more. An important change that emerged from that process is DSNP 1.3’s concept of profile resources, an extensible mechanism for storing and retrieving user profile information. In previous versions, users announced new and updated profile documents through the content stream. This had the disadvantage of requiring applications to maintain an index of the full history of the profile content stream in order to locate and display a particular user’s profile. The profile resource type moves the linkage to profile documents to the consensus system proper, recognizing the critical role that profile information plays in allowing users to find and discover each other. Combined with the ability to attach attestations to a user profile, this means users can display badges and other verified attributes on their profiles, and know that these can easily be discovered by ecosystem applications and services.

Hashing it out

Digest values from hashing algorithms secure and anchor chains of DSNP-related data, ensuring the authenticity of announced content, attribute sets, media attachments, and more. DSNP 1.3 recognizes the importance of these hashes and aims to make development of DSNP-compliant applications and services simpler by more precisely defining the allowed algorithms (SHA-256 and Blake3), encoding (multihash), and serialization (base32 multibase strings) of hashes. By ensuring consistent usage throughout the specification, developers can focus less on transforming hashes between different representations, and leverage reusable components and libraries across a variety of DSNP-related use cases.

Next steps

The summaries above focus on new and updated affordances provided in the latest version of the specification. For more details and links to related discussions, see the github release notes. In the coming weeks this blog will explore some of the possible use cases and applications of these toward building a vibrant and thriving DSNP ecosystem. Your contributions are welcome and encouraged, too, whether that means starting a discussion on the Project Liberty forums, submitting your own post for this blog, or simply airing your opinion on the monthly community call.

Wes Biggs is a principal software architect at Project Liberty Labs and a maintainer of the DSNP specification.

Workshop Provides Valuable Feedback on DSNP's Draft Governance Framework

Tue, 20 Aug 2024 00:00:00 +0000

On the sidelines of the Ethereum Community Conference (EthCC) in Brussels, a vibrant gathering of over 30 decentralized technology practitioners and academics came together to explore governance solutions for decentralized tech projects. The event featured three insightful breakout sessions where the Blockchain Governance Toolkit produced by Project Liberty Institute in collaboration with BlockchainGov was used to guide the workshop discussions and solution-design process.

The Decentralized Social Networking Protocol (DSNP), particularly its draft governance framework was the focus of one of these breakout session led by Wil Wade, one of the co-authors of the first DSNP whitepaper. It received a lot of valuable feedback from the governance experts who actively participated in the session.

The workshop tackled three challenges DSNP currently encounters or will in the future:

Progressive Decentralization

A primary concern was transitioning from a centralized founding team to a more decentralized governance model. The challenge lies in balancing this decentralization with the need for expedient decision-making, especially as the user base grows.

Participation Incentives

The “no pay for play” model aims to foster genuine participation without financial incentives. Discussions revolved around finding alternative ways to motivate governance participation, particularly as the user base expands.

Norms vs. Rules

The framework seeks to translate social norms into enforceable rules and procedures. Establishing conditions by which web applications using DSNP can make these norms binding through contractual agreements rather than code alone is a path worth exploring to ensure the Mission & Principles of DSNP are enforced.

Key Discussions Points - Flexibility, Functionality and Legitimacy

The governance challenges DSNP is encountering are somewhat similar to a lot of other decentralized projects. Many examples of projects that faced similar governance challenges were shared, which helped derive key insights and strategies.

One of the insight shared regarding the current model displayed in the DSNP Governance Framework v.1 is that it reflects expectations of potential participants that the project might not be attracting at the present time. One practitioner in the room shared how they, in their project, designed their own governance framework based on their aspirations for participation, rather than the reality of actual participation. This approach, however, led to many challenges, including failing to attract the desired participants and overlooking the needs of those who were actually involved. Indeed, what is fundamental is that the governance represents the user base. Therefore, it was suggested to put in place a flexible governance structure that can scale and build legitimacy without prefiguring centralization to complement the current model.

The question of participation and the incentives to participate, especially given our choice of a “no pay for play” model was also at the center of the breakout session. It was suggested to reinforce functional interactions between stakeholders categories. A participation model around community (core members and other circles), recognition (access to different part of the project) and responsibility (giving participation specific role) was also suggested.

Maintaining legitimacy is essential for effective decentralization, and practices like community calls and GitHub code repositories foster trust through transparency. This needs to be continued as it now currently pursued. Addtionally, it was suggested to create a sort of “minimum viable governance” to ensure functional governance. One idea was to design a “constitution” by creating a living document to formalize governance processes.

Future Steps

The outcomes of this workshop will guide the DSNP Advisory Council’s Governance Working Group. The group will take into consideration these initial feedback and keep on refining the governance framework.

Should you be interested in joining this work towards the progressive decentralization of DSNP governance, please write directly at dsnpfeedback@projectliberty.io or post your thoughts on the DSNP Forum, section Governance.

Sarah Nicole is a Senior Policy & Research Associate for Project Liberty Institute.

The DSNP Difference--Federated Protocols Part 2

Wed, 07 Aug 2024 00:00:00 +0000

DSNP Contributor and professional “techsplainer” Jeanette DePatie shares her thoughts in this second in a series of articles about the differences developers will experience between creating on DSNP versus other federated protocols.

In part one of this series, we discussed several of the important advantages DSNP offers over other protocols (namely AT Protocol and ActivityPub). Some of those key advantages included greater economic viability and freedom of choice for developers on the platform, greater decentralization as opposed to a federated model, data persistence where developers and users can feel confident that data won’t be lost and less vulnerability to censorship at the protocol level.

In this article, we will discuss a few additional important differences between DSNP and other protocols like AT Protocol and ActivityPub.

Discoverability

One challenge for developers using ActivityPub and AT Protocol is the lack of discoverability across servers. Since ActivityPub and AT Protocol use federated P2P technology, they don’t provide for unified public spaces with global search capabilities where users can find new apps, new content, or one another. This can present an area of risk for developers using these protocols, as there is no guarantee that users will be able to find the applications they have built or the content posted there. Additionally, this may open the door to developers facing gatekeepers that could restrict their development and content choices–as leaving them out of the search index would be equivalent to isolating their apps to a deserted island.

DSNP developers can rest assured that users will be able to find and access apps and their data. All public activity is replicated in every node, thus there is no place for gatekeepers to arbitrarily lock out nodes or developers. Building hybrid solutions with DSNP and other protocols could help improve discoverability and reduce the risk that developers will find themselves stranded outside the search index.

Identity

ActivityPub handles universal identity through a decentralized social networking protocol that uses ActivityStreams vocabulary. Each user in the ActivityPub network is represented as an “actor” with a unique profile that includes various elements like inbox, outbox, followers, following, and a unique id URL that serves as a globally unique identifier for the user within the network. However, one challenge in user verification on ActivityPub-based platforms is the absence of a cross-server directory. This can make it difficult for users to find and follow people across different servers. Additionally, there is currently no standardized tool or mechanism in widespread use for confirming the authenticity of an account.

Alternatively, the AT Protocol uses two interrelated forms of identifiers: the handle and the DID. AT Protocol handles are DNS names. For DIDs, AT Protocol supports did-web and a temporary method called DID Placeholder for global identification management. While AT Protocol has committed to supporting this placeholder until a better method is found, developers will likely soon be faced with the challenge of upgrading to the new DID system.

DSNP has fully developed and detailed mechanisms for handling universal identity across DSNP applications. DSNP applications must allow users to create pseudonymous identifiers (although users can use their real name if they wish). Users choose a handle which is then paired with a number in the application to create the user’s universal handle. Verification of the user’s identity is managed via a cryptographic key pair–ensuring that content issued by a particular user comes from them and no-one else. The process of tying a user handle to a real world identity is outlined via a process currently proposed for DSNP called Attributes and Attestation, which will be outlined in a future article. With the right bridges in place, DSNP could also potentially be used in concert with other protocols like ActivityPub and AT Protocol to bring verifiable pseudonymous identity to a hybrid system.

Portability

The ability to move one’s identity from one application to another (as discussed above) is just one aspect of portability. Decentralized systems also aim to allow users to move content and their social graph (the web of relationships with others on the system) from one application to another.

AT Protocol offers some ability to migrate data from one host server to another via signed data repositories and DIDs. However, the extent to which this data is portable depends on the implementation of the AT Protocol by individual applications, and the compatibility between them. ActivityPub offers even more constrained portability as it requires the original server to provide a redirect to the new location as well as the new server to allow the transfer. Should an old server go down, it would be unable to offer the required redirect. And if the account is banned or the server to which they are migrating is defederated, then migration would be impossible. Thus the only way to truly ensure content stability is for a user to run their own server (which requires a certain degree of technical aptitude). Other challenges to portability in ActivityPub include the lack of a standard backup format for certain types of content and the possibility of incomplete data transfer during the move from one server to another.

With DSNP all key data is stored in all nodes of the system. Thus, there is no need to “transfer” data from one place to another and risk loss of data in the transfer. The user may take their social graph with them from one application to another without worries about compatibility or redirects. The user needn’t bother running their own node (although they may if they wish to) as the multi-node structure functions as a de-facto backup of their key data. In any case, the data remains persistent without reference to a particular application or server host. Perhaps in the future, DSNP’s universal identifiers could provide risk-free mechanisms for users of other protocols to transfer their identities and social graph.

Privacy and Security

Another key differentiator between DSNP and other protocols lies in data security and privacy. In ActivityPub, the security of the system is largely dependent on how it’s implemented by various applications. For example, ActivityPub as experienced by Mastodon users can make no promises around system-wide privacy and thus must trust that servers are not bad actors. This puts much of the responsibility for security on the individual server administrators. In addition, ensuring secure communications among servers can be challenging, involving not only securing the data while in transit but also verifying the identities of the communicating parties. While the AT Protocol specifies that digital identifiers (DIDs) may be authenticated via rotating cryptographic keys, at this time, AT Protocol as implemented in Bluesky utilizes a simple email certification to determine account authenticity. Additionally, while AT Protocol specifies that private messages and accounts may be available in the future, its current Bluesky implementation does not allow for DMs or other private communication.

DSNP offers publicly provable data encryption to secure user data and maintain privacy (particularly via blockchain). DSNP systems allow users to choose a pseudonymous handle, and users can decide what other information to include in their descriptive profile or via the use of verified attributes. Any private user data stored in DSNP is encrypted using cryptographically strong public/private key technology.

Scalability

Scalability is likely to be one of the largest issues ActivityPub will face as scaling the network requires ever-increasing computing resources to interact with fragmentation and large instances. ActivityPub’s inherent requirement for replicated content could greatly increase the costs for running the massive servers required to meet demand. In short, ActivityPub can be server-load intensive. AT Protocol is less resource intensive as it splits its functions across two types of servers: Personal Data Servers (PDSs), lightweight servers which house user accounts, and crawlers, which access data from various accounts and PDSs and aggregate it for end users. However, one significant challenge to scalability at present is that at the moment, AT Protocol is only effectively used by Bluesky, and has not had to deal with the challenges of working with a more decentralized network architecture. The only way that the true decentralized advantages of AT Protocol can be realized is if a significant number of other applications or service providers join the AT Protocol bandwagon.

DSNP has been designed from the ground up to be massively scalable. Firstly, DSNP allows users to delegate their tasks to providers who may in turn gather many transactions together and send them in batches. This drastically cuts down on costs, while allowing applications to listen to announcements and implement their own strategies for replicating and indexing content.

Conclusions

Decentralized and federated social media protocols have attracted significant interest and rapid advancement. While AT Protocol, ActivityPub and DSNP may be among the most popular of these formats, new ones are being developed all the time. Each decentralized or federated social media protocol has advantages and disadvantages for hosts, developers and users. The spirit of decentralization points to a future which doesn’t split the world into winners and losers, but rather, seeks to find common ground and opportunity in collaboration. Thus it should be of significant interest to all stakeholders to find a way to work together and learn from one another to work towards a future that creates a better, and more empowering, social networking future for all.

Jeanette Depatie is a DSNP contributor and technical writer. The opinions expressed in this post are solely the author’s and do not necessarily express the views or opinions of Project Liberty Institute.

The DSNP Difference--Federated Protocols Part 1

Wed, 31 Jul 2024 00:00:00 +0000

DSNP Contributor and professional “techsplainer” Jeanette DePatie shares her thoughts the differences developers will experience between creating on DSNP versus other federated protocols.

As developers explore different protocols to underpin their social networking application efforts, it’s useful to note how the Decentralized Social Networking Protocol (DSNP) is different from others. Of particular note are the AT Protocol (currently utilized in the Bluesky platform) and ActivityPub (currently utilized in federated social network applications like Mastodon).

AT Protocol

The Bluesky platform is a microblogging social network platform with very short form content like X (formerly known as Twitter). It originated as an initiative within Twitter designed to create a decentralized social protocol. Bluesky Social (incorporated as a public benefit corporation in 2021) was launched by Twitter co-founder Jack Dorsey and XMPP creator Jeremie Miller. Bluesky Social created AT Protocol to underpin the Bluesky platform.

ActivityPub

The ActivityPub protocol, which builds upon the Activity Streams 2.0 data format, provides a client to server API for creating, updating and deleting content and a federated server to server API for delivering notifications and content. The ActivityPub protocol was published as a Recommendation to W3C by the Social Web Working Group in 2014. This group last published official recommendations in 2018. Since then, the Fediverse community has collaborated on improvements, such as those submitted as Fediverse Enhancement Proposals (FEPs). The ActivityPub protocol and a suite of related protocols and conventions is used by applications like Mastodon, Medium, Mozilla.social and Meta’s Threads, among others.

DSNP

DSNP was designed to give users agency and control over their social identities and the connections that form their social network, enabling a secure, universally accessible social graph and facilitating open and trusted communication in public forums. To facilitate these goals, it leverages the capabilities of public permissionless consensus systems. DSNP has an open, community-driven governance model, and is stewarded by the Project Liberty Institute and advised by a group of experts (including Dave Clark, Lawrence Lessig and Wendy Seltzer) with long and deep histories in Internet protocol and governance development.

Comparing the Protocols

While all three of these protocols are utilized and in some ways designed for social networking applications, there are important differences developers should consider before choosing among them as building blocks for their social networking applications.

Economic Viability

One of the main differences between DSNP and AT Protocol/ActivityPub is in the revenue models they can support. Currently AT Protocol earns a small amount of revenue through services sold by Bluesky–starting with custom domains. In addition Web Monetization federation via ActivityPub has been proposed as a W3C standard. However, Activity Pub is largely dependent on donations via grass-roots efforts in order to stay afloat and incentivize developers and server operators. This means that these protocols are dependent on the goodwill of the community they originally attracted in order to keep donations flowing in. This may affect developers that use certain revenue models (e.g. ads, selling data) that are unpopular with donors. While federated protocols may not prevent these developers from using these models, it may control their visibility within the federated network–essentially stranding them on an island away from the rest of the system. Thus, a donation strategy may not only limit the decisions developers on the platform may make, but may also prove untenable as a long term strategy as interest or passion in the protocols wane. While Bluesky generates some income via custom domain services, AT Protocol is largely dependent on Bluesky Social for funding. Thus economic viability is largely dependent on this entity remaining successful and retaining interest in the AT Protocol profile.

While DSNP is also a 501(c)3-stewarded protocol with charitable donations covering advisor meetings and community communications, DSNP can support any number of revenue models for applications and network participants. App developers may choose any monetization strategy they see fit so long as they clearly and transparently divulge this strategy to would-be users on the platform. At the next level, DSNP end users may choose whatever app provider meets with their personal needs. Thus monetization strategies are both presented and selected in a free-market system which may change to accommodate different market conditions and whatever end users are currently willing to support.

Decentralization

Another important difference in DSNP when compared to AT Protocol/ActivityPub is the level of decentralization. Both AT Protocol and ActivityPub are federated systems. These systems (often described as belonging to the “Fediverse”) are composed of a set of servers that may operate with some level of independence from one another, and each individually owned and controlled server may have its own policies and rules. The protocol defines the way content and connections are shared between servers (although ActivityPub can be used both for client-to-server and server-to-server interactions, Mastodon uses it primarily for the latter type). Access to a user’s account, social graph, and content is controlled by the individual server they join. While in theory, a server should treat its users well, at the end of the day, it’s the server not the end user who has final control over the account.

DSNP enables a universal decentralized data plane where accounts, social graphs, and access to content is distributed throughout the system with replication of all important data across nodes via consensus mechanisms, and thus there is no single point of control or failure. This can make the system more resilient to data loss as well as less vulnerable to censorship (see below). Because nodes in the system operate under a shared set of rules, a DSNP system allows for system-wide governance–a process where all stakeholders (including developers and users) will have access to transparent information about how the system is run as well as some say in how the system is managed. At the protocol level, the Project Liberty Institute serves as the initial steward of the DSNP specification, with an open governance model and plans to formalize how everyone within the community can contribute to the growth and governance of the protocol.

A bridge built between DSNP and ActivityPub and AT Protocol could result in greater decentralization for these two federated systems. DSNP could potentially offer greater data resilience and resistance to censorship.

Data Persistence

One key element of user ownership and agency over their social networking data is consistent and persistent access to that data. If users lose access to their data due to network issues, account issues or because they are blocked from using a social networking application, they may lose access to their content and their social graph (i.e. the web of social connections they may have as friends or followers online).

AT Protocol, ActivityPub and DSNP each handle data persistence in a different way. A core idea of ActivityPub is that since neither desktop systems nor mobile devices have a permanent connection to the internet, one needs an agent that does (i.e. a Mastodon instance). ActivityPub hosts user posts under linkable URLs and notifies interested parties (i.e. the people following the content creator or thread) when and where new posts may be found. A potential challenge with this model is that all of this data may be hosted in different places on the Internet that may or may not be available at any given time. So unless a user hosts all of their own content on their own server, their content may become unavailable at any time either because a server shuts down or a moderator removes the user’s access (censorship). And even if a content creator self-hosts, there is no guarantee they will have consistent access to the full content of their replies, posts or threads.

The AT Protocol handles this storage issue somewhat differently. All the user’s data is stored in a Personal Data Server (PDS) that hosts a Personal Data Repository (PDR) which is bound to the user’s identity and contains all the user’s content (including comments). The user may choose to host their own PDS at any time. One issue that remains unclear is where the indexes of User IDs are stored. Until the issue of User Identification indexing is definitively solved, AT Protocol users may lose connections with other users in their network and unless they are self-hosted, they may lose connections to their own content.

As a decentralized platform, DSNP ensures that users can retain control over their content or their social graph. DSNP is run on independent nodes, each of which guarantees access to all critical data such as decentralized user identifiers, public keys, and social graphs. Any data that is not replicated among the DSNP nodes (such as content or media files) can be stored on distributed file systems such as the InterPlanetary File System (IPFS), a peer-to-peer network for storing and sharing data without relying on the continued availability and goodwill of a particular content host. It is conceivable that connections built between DSNP, AT Protocol and ActivityPub could result in a hybrid system. This hybrid system could afford greater data persistence and resilience than is currently enjoyed by either of the federated systems.

Censorship

Decentralization and data persistence each feed into whether a protocol makes users more or less vulnerable to censorship. All three of the protocols discussed in this article allow users who face censorship with one application or server to elect to move to another application or server that uses the protocol. However in practical terms this plays out differently in each case. For example, users of applications on the AT Protocol may choose a server that is aligned with what the user feels is important or what they wish to express. However, Bluesky (the only platform using the AT Protocol at present) does not make it easy for users to understand what the differences among the different servers are. Users are given little information about which server to pick initially and little information about what server might suit them better if they are kicked off a server for violating the rules and sensibilities surrounding that server. The situation is somewhat similar on many ActivityPub applications. What’s more, since ActivityPub and AT Protocol face challenges around data persistence, users risk losing access to their content and connections (social graph) as they move from one server or provider to another.

DSNP users are less vulnerable to censorship, as the delegation model allows them to simply elect to share access to their data with any willing application provider. Each of these providers is expected to provide clear instructions regarding their terms of service. And should a user choose to leave one provider or application, the process of moving to another is quite simple. As all important information the user needs to stay connected to their DSNP identity and relationships is stored among all nodes of the system, the user can move from one application to another without fear that their essential data will be lost.

Again, one could imagine a hybrid system appending the data persistence and ease by which users may move from one provider to another to the current AT Protocol and ActivityPub applications. Bridging between federated and decentralized systems would likely be quite challenging. However, there is a great deal to be gained by creating connecting tools that allow the greatest possible number of users to encounter the advantages DSNP has to offer.

More to Come

These are just a few of the important differences between DSNP and other protocols like AT Protocol and ActivityPub. Stay tuned for further articles with additional details regarding the advantages offered to developers by DSNP.

DSNP Advisor Summit meeting minutes - 2024-06-11

Mon, 01 Jul 2024 00:00:00 +0000

Meeting Minutes
DSNP Advisory Council
June 11, 2024
MIT Media Lab
Cambridge, Mass.

Agenda

Objective, agenda and Project Liberty Institute updates
Comparative Analysis Working Group (CA-WG) update and discussion
Project Liberty updates with Q&A
Workshops:
1. Ecosystem Architecture Working Group (EA-WG)
2. Effective DSNP stewardship
DSNP Advisory Council structure
Technical specification progress and roadmap discussion
Governance Working Group (G-WG) update and discussion
Frequency functional overview, Q&A
Closing summary and meeting actions

Attendees

Tomicah Tilleman (TT), President, Project Liberty
Erik Suhonen (ES), Project Liberty Institute
Wes Biggs (WB), Project Liberty Institute
Sarah Nicole (SN), Project Liberty Institute
Braxton Woodham (BW), Amplica Labs
Harry Evans (HE), Amplica Labs
Denise Duncan (DD), Amplica Labs
Dave Clark (DC), DSNP Advisor
Deb Roy (DR), DSNP Advisor
Wendy Seltzer (WS), DSNP Advisor
Sara Wedeman (SW), DSNP Advisor
Sandy Pentland (SP), DSNP Advisor
Wes Chow (WC), DSNP Advisor Team
Maggie Little (ML), Ethics Lab
Jonathan Healy (JH), Ethics Lab

/ Objectives, agenda, and PLI updates /

ES discussed goals for the day’s agenda, including the continued focus on aligning DSNP and the ecosystem with Project Liberty Institute’s (PLI) 3 core principles of Choice, Voice, and Stake. He also put forward the objectives of enhancing the efficacy of the DSNP Advisory Council and providing additional ideas on successful DSNP stewardship.

ES thanked the group for a productive previous meeting (April 18) and application of the mock trial concept to debating governance and ecosystem architecture.

ES updated the group on various PLI and broader Project Liberty initiatives.

For April 2024:

Harvard’s ASML has now hired a Senior Director to lead developments pods which will be looking at exploring DSNP and will be hiring more people.
PLI has been progressing efforts with the India tech ecosystem. The Centre for Digital Public Infrastructure now recommends DSNP in their curated solution stack. (See https://docs.cdpi.dev/references/home)
The 4/19 PLI Summit was considered a success, and participants were gratefully thanked.
DSNP is now listed in the Civic Tech Field Guide, which is a large principles-aligned resource for others using tech for the common good.

For May 2024:

Frank McCourt announced the People’s Bid for TikTok.
The Governance working group released the draft DSNP governance framework v1 on DSNP.org.
Audrey Tang joined as a DSNP Advisor.
PLI made progress on analysis of DSNP and peer protocols to support our WG.
PLI is working to document use cases for DSNP including social media, commerce, creator economy, sports, media and entertainment, music and gaming.
Matthew Nay from DR’s group published his thesis including DSNP: “Decentralized Social Networking Protocol (DSNP) and User Empowerment: An Analysis of Online Identity Ownership, Data Privacy, and Comparative Assessment with Other Decentralized Protocols”

Ongoing projects:

DSNP stewardship strategy (more in the breakout today)
DSNP messaging (including “Why DSNP”), a new DSNP logo and updates to the DSNP website
Partner Toolkit (content, tooling and support)
Continuing with Working Groups meeting bi-weekly (generally)
Continuing to host monthly DSNP Community Calls
870k+ users on DSNP and Frequency through MeWe, with social graph migration now underway. https://metrics.frequency.xyz
Economic task force, aligned with our 3rd principle
Engaging with creators to better understand how we can advance DSNP and ecosystem to support them

SP highlighted his work with Thomas Hardjono in relation to the India stack, noting that many governments were beginning to sign up to implement different components, and that DSNP may be relevant to those efforts. WB noted that the engagement with CDPI was a first step in sounding out those opportunities.

DR said he would share Matt Nay’s thesis with the group.

DR expressed a hunch that a form of Citizen Assembly would be important and noted the continuing intersection of his team’s work with that of Jonathan Zittrain and Larry Lessig at Harvard. ES noted that this would be a good topic for an update at the PLI Fall summit.

HE and WC discussed details of the graph migration currently underway (MeWe is using the encrypted “private follows” relationship). SW asked how users were opting in to this migration, and if this was causing user confusion. BW noted that the approach was to have users opt in to both identity and graph at the initial point of contact; the current migration was catching up with previously opted-in accounts.

DR asked about the security of graph data and posited a challenge for developers to determine what could be discovered in terms of graph navigability from the current data set. BW noted that Frequency had passed a detailed security audit. SP suggested that all protocols will have certain privacy problems, and the potential leakage should be examined. He noted that timestamp-based traffic analysis was able to yield significant information, even when data on a blockchain was encrypted. WS noted that these questions tie into governance with respect to who (if anyone) has access to side channel data.

/ Comparative Analysis Working Group / \

WC discussed the structure of the analyses proposed as output for the working group and shared a document with proposed assignments of different feature areas to meeting attendees.

WS suggested that the group be provided with a template to be filled in for each category. WC agreed to take an action. For each category, he asked participants to provide concrete use cases, e.g. “User wants to change to a different provider”.

/ Project Liberty updates with Tomicah Tilleman Q&A /

TT provided further updates and plans. He welcomed Audrey to the group and emphasized the value of the working group structure for the advisors.

TT suggested some themes for the Fall summit including proposing an agenda for the next U.S. administration’s technology roadmap as well as a culmination of the “quilting party” begun in April where solutions could be presented.

/ Workshops /

The group split into two workshops as follows.

/ Workshop 1: Ecosystem Architecture Working Group /

DC led the first workshop as a continuation of topics introduced previously within the EA-WG, guided by a working document he shared with the group. He noted that key goals of the ecosystem included privacy, harm prevention, and decentralization of control.

DC discussed learning about the Matrix project (a decentralized network using the same underlying protocol as the Signal app) from AT. The group discussed if DSNP could interoperate with this type of protocol, and whether it could prove instructive for guiding needed DSNP functionality such as direct notification addressing, discovery and introductions.

Signal’s donor-funded economic model was discussed. DC noted that operational costs for pure social network communication technology are much less than costs to operate advertising technology and monetization of the same social networks. Models such as Signal, Spotify, and Medium were discussed. DC suggested that the per-user annual cost of DSNP over Frequency be interrogated.

HE revisited the model of DSNP as a data layer accessible to many applications, detailing some of the assumptions of trustlessness that were fulfilled by a consensus system architecture and differentiating this “neutral space” from a portability goal. DC agreed that the goal of freeing the user from the need for trust was important, but noted that DSNP still assumed that users would create trust relationships with applications. The opposing forces of usability versus trustlessness were highlighted.

The group distilled a number of topics for further discussion in Q3, including data locality by date type (e.g. whether the public and private graph should exist on the consensus system as currently specified), and how the ecosystem can be made economically sustainable.

/ Workshop 2: DSNP Stewardship /

ES led the second workshop, focusing on three aspects:

Current PLI stewardship framework
What does ideal DSNP and ecosystem stewardship look like to you?
Ideas to enhance effectiveness

A key finding from the group was that the desire to have Project Liberty’s mission and principles remain highly influential to DSNP may have ramifications for the governance model.

/ DSNP Advisory Council Structure /

The group discussed how the current structure of the Advisory Council, including the various working groups, could be improved.

SW noted a very practical consideration, that all working group members should have edit access to the relevant documents. The group agreed that it would remedy any access control issues.

WS noted that the prior workshop had highlighted a need to get more feedback from participants outside the working group itself. DC suggested that there should be a cadence for coming together to review findings with the full group.

A structure was proposed for quarterly in-person meetings to replace the current six-weekly ones. DD noted that these meetings needed to be well planned to encourage cross-pollination between working groups. DC asked for more clarity on how decisions are made and communicated within the Advisory Council.

SP suggested the need for a clear value proposition to take to government, business, and other external stakeholder groups. He noted that the current materials took a bottom-up approach, but a top-down view was lacking, which could run the risk of enabling unwanted behavioral outcomes. The group discussed the need to unite the working groups around a common set of such use cases.

SW expressed concern that too much focus on working groups only would not leave space for anecdotal discussion.

After discussion, the group agreed that the next in-person meeting would be held in early September, with a virtual (Zoom) meeting scheduled in between as a checkpoint.

/ Specification roadmap and discussion /

WB summarized recent work on the DSNP specification.

He mentioned that the next minor version of DSNP (1.3) was slated for updates including:

Public keys in core user data (final)
Links to profile resources in core user data (draft)
Attribute set announcements and attestation framework (draft)
Content addressable storage for user-generated content (awaiting draft)

He highlighted key talking points that the group might use in discussing the impact of these changes. These were:

Importance of direct ownership of key data items beyond identity and graph
Affordances enabling user-to-user and application-to-user trust
Options for decentralization to avoid content de-platforming and link rot

/ Governance Working Group /

WS summarized the recent work of the G-WG as follows:

Publication of the draft DSNP governance framework V.1
Several individuals have expressed their interest in participating in governance, either verbally or through email.
Creation of a DSNP Governance section in the DSNP forum

Proposed next steps were outreach to specific stakeholders to engage with the framework, and coordination among other WGs. WS noted that clarity around the question of PLI stewardship and its impact on the governance structure documents should be addressed prior to this work commencing.

/ Frequency Functional Overview, Q&A /

HE fielded questions and facilitated discussion on functional aspects of the Frequency blockchain, relative to DSNP.

The group interrogated how to distinguish DSNP and Frequency in conversations. BW noted that an analogy to TCP/IP (TCP over IP) had been used to talk about “DSNP over Frequency”.

SP asked if DSNP over Frequency incorporated concepts of value routing, as this was an active topic from a standardization point of view for the work that he and TH were engaged in. HE noted that Frequency does not currently support NFTs. The group discussed that the concept of value could be very broadly applied to social media and in particular the monetization of content within a social context, and that the intersection of this work with DSNP should be investigated.

/ Closing /

ES summarized the meeting, bringing the various agenda topics together, tied into the overall vision and strategy.

The next in-person DSNP advisory council meeting will take place on September 4, 2024 at MIT. The following in-person meeting will be held at Georgetown University on November 18, 2024, just before the next PLI Summit.

Minuted by WB

Announcing the Publication of the DSNP Governance Framework v.1

Thu, 23 May 2024 00:00:00 +0000

In the landscape of open and decentralized protocols, governance can be as important as technical choices to the success of these digital ecosystems. Good governance invites equitable stakeholder engagement and informed decision-making. Today, Project Liberty Institute is pleased to announce the publication of a draft Governance Framework (v.1) for the Decentralized Social Networking Protocol (DSNP).

Following the publication of the Mission and Principles, and the Specification Development Process, this governance framework builds a decision-making process to reinforce the fundamental principles driving the protocol.

DSNP Governance Framework consists of a Membership Agreement, DSNP Charter, and Working Group Charter. The framework’s core governance choices include:

Adoption of a Multistakeholder Governance Structure: While participants have differing interests based on their relationship to the protocol (including end users, businesses, technologists, and service providers), they all have stakes in its success. The governance model encompasses the entire project, including DSNP.
Open Membership and Participation: All individuals who align with the Mission and Principles are welcome to join and engage. There are no barriers to entry or participation fees (“no pay for play”).
Democratic Selection of the Steering Committee: The Steering Committee, responsible for governance and acting as the final point of appeal, is elected from the membership through Stakeholder Groups. These groups establish their own processes independently, free from external sponsorship influences.

You can find all relevant documents on dsnp.org, section “Governance and Evolution”, and you can be involved directly by providing feedback by email to dsnpfeedback@projectliberty.io or on the DSNP Forum.