Open Social Network Core is the protocol foundation for Open Social Network: an open, decentralized social layer for the web where identity, audience, and content belong to people rather than platforms.
This repository contains the early protocol specification, TypeScript reference primitives, JSON schemas, and conformance-oriented tests for sovereign social pages and signed feeds.
If you want to use Open Social Network rather than implement it, start with Open Social Network Web or the CLI. They let you create a page, write posts, and host the public files anywhere static files are supported.
Open Social Network Core defines how an independent social page works.
At minimum, a profile has:
- a public identity file:
profile.json - a public feed file:
feed.json - signed posts that can be verified by any client
If you are building an aggregator, host, SDK, validator, crawler, or sovereign page generator, this repository is the starting point.
If you are a normal user, you should not need to read JSON or cryptography details to get started.
We have protocols for websites, email, domain names, payments, feeds, files, and even communication between AI systems.
- HTTP lets anyone publish a website.
- DNS lets names point across the internet.
- SMTP lets messages move between independent providers.
- RSS lets clients read feeds without owning them.
- MCP is emerging as a protocol layer for AI tools and agents.
But social identity is still mostly trapped inside platforms.
Your username, followers, posts, reputation, and reach usually belong to a company database. If the platform changes rules, disappears, bans you, locks APIs, or degrades the product, your social existence is trapped with it.
Open Social Network exists to make social identity part of the open internet itself.
The social web should not require every person to live inside a closed platform database.
Open Social Network starts from a simpler premise:
- a profile can be a page on the internet
- a feed can be a static JSON file
- a post can be verified with a public key
- an aggregator can read the network without owning the network
- followers should follow identities, not companies
The protocol is designed to use infrastructure the web already has: HTTP, DNS, static hosting, caching, CDNs, and browsers.
If Open Social Network works, a social profile becomes more like an email address or a domain name than an account inside an app.
For users:
- you can own your identity
- you can move between providers
- you can keep your audience
- you can self-host or use a host
- you can choose different clients and aggregators
- you are not forced to restart your social graph every time a platform changes
For developers:
- clients can be built without asking permission
- aggregators can compete on UX, ranking, moderation, and discovery
- apps can interoperate through files and signatures instead of private APIs
- innovation moves to the edges of the network
For hosts:
- static hosting can become social infrastructure
- providers can offer sovereign profile hosting without owning the protocol
- migration and mirroring can become first-class features
For the web:
- the social graph becomes portable
- identity becomes durable
- platforms become interfaces, not prisons
People own their identity, content, audience, and reputation. No aggregator or company should own the social graph.
Anyone should be able to host profiles, build clients, run aggregators, index pages, and create recommendation systems.
The first version avoids tokens, consensus systems, blockchains, and unnecessary distributed infrastructure. The MVP is intentionally built on signed JSON and ordinary web hosting.
Users should be able to move domains, change hosting providers, mirror their pages, or self-host without losing identity or audience.
Open Social Network belongs to nobody. The protocol should support many clients, many aggregators, many hosts, and many moderation or recommendation systems.
Future capabilities should be optional modules. Older clients should ignore unknown fields gracefully.
Open Social Network Core v0.1 defines the minimum viable social protocol:
profile.jsonidentity filesfeed.jsonpost feeds- public follow lists
- ES256 signed posts
- signed public actions for likes, dislikes, and comments
- encrypted direct-message envelopes
- canonical JSON signing payloads
- profile endpoint discovery
- chronological feed aggregation
It does not define accounts, global search, moderation policy, recommendations, or media storage. Those should remain independent layers.
open-social-network-core/
├── docs/
│ └── protocol-v0.1.md
├── schemas/
│ ├── feed.schema.json
│ ├── post.schema.json
│ ├── profile.schema.json
│ ├── action.schema.json
│ ├── action-inbox.schema.json
│ ├── direct-message.schema.json
│ └── message-inbox.schema.json
├── src/
│ ├── aggregator/
│ └── protocol/
└── README.md
Start here:
- Read docs/protocol-v0.1.md.
- Inspect schemas/profile.schema.json.
- Inspect schemas/feed.schema.json.
- Inspect schemas/action.schema.json.
- Inspect schemas/direct-message.schema.json.
- Inspect schemas/message-inbox.schema.json.
- Look at the signing tests in src/protocol/signing.test.ts, src/protocol/public-actions.test.ts, src/protocol/direct-messages.test.ts, and src/protocol/message-inbox.test.ts.
Use the reference timeline loader in src/aggregator/timeline.ts as the baseline behavior:
- load followed profile URLs from local choice or a portable follow list
- fetch profile files
- resolve feed endpoints
- verify every post signature
- fetch each loaded profile's public action log when available
- fetch advertised public action inboxes when available
- verify public actions against known actor profiles
- render only verified posts and verified actions
- report rejected posts, rejected actions, and failed feeds
Portable follow lists live at /opensocial/follows/index.json. They let a profile publish the people it follows as simple protocol data, so a user can move between aggregators without rebuilding the graph from scratch.
The reference loader reads two complementary public action sources. A profile's own /opensocial/actions/index.json is the actor-owned log of likes, dislikes, and comments that identity has published. An advertised endpoints.actions inbox is the target-owned inbox for actions delivered to that profile. The loader returns actions only when the actor profile is known, the target profile is known, and the signature verifies against the actor profile. Unknown actors, unknown targets, invalid signatures, and wrong-target inbox actions are reported in rejectedActions instead of being rendered.
Your host should be able to publish:
profile.jsonfeed.json- optionally
/.well-known/open-social-network.json
It should never publish private keys.
Public actions can live in a public action folder such as /opensocial/actions/. The actor-owned action log at /opensocial/actions/index.json lets a profile publish its own portable likes, dislikes, and comments from any static host. A profile can also advertise endpoints.actions, usually /opensocial/actions/inbox/index.json, when a compatible host accepts automatic signed action delivery for actions targeting that profile. A compatible action inbox stores actions from many actors in an owner/actions document and verifies each action against the actor profile before accepting it. That folder can also be updated by any compatible write path a host supports. GitHub Pages, Cloudflare Pages, Netlify, Vercel, S3-compatible storage, a personal server, local folder sync, and future protocol modules can all be valid approaches.
Apps should create actions through the reference helpers instead of hand-writing action JSON:
createReactionAction(actor, target, "like" | "dislike" | "none")createCommentAction(actor, target, content)signAction(unsignedAction, privateKey)verifyAction(signedAction, actorProfile)
Encrypted direct messages can live in a public message folder such as /opensocial/messages/inbox/ because the message body is ciphertext. The recommended inbox document is /opensocial/messages/inbox/index.json with an owner and a messages array of encrypted envelopes. Compatible inbox implementations should accept one signed encrypted message, verify it against the sender profile, ensure message.recipient matches owner, reject duplicate message ids, and store only the encrypted envelope. The private message key must never be published.
npm installnpm test
npm run build
npm audit{
"protocol": "open-social-network",
"version": "0.1",
"handle": "ada@example.com",
"name": "Ada Lovelace",
"publicKey": {
"alg": "ES256",
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "...",
"y": "..."
}
},
"endpoints": {
"profile": "/profile.json",
"feed": "/feed.json",
"actions": "/opensocial/actions/inbox/index.json",
"messages": "/opensocial/messages/inbox/index.json"
}
}{
"protocol": "open-social-network",
"version": "0.1",
"author": "ada@example.com",
"posts": [
{
"id": "post_001",
"author": "ada@example.com",
"createdAt": "2026-06-03T12:00:00.000Z",
"content": "Hello from a sovereign page.",
"signature": {
"alg": "ES256",
"value": "..."
}
}
]
}{
"id": "action_001",
"kind": "reaction",
"actor": "ada@example.com",
"createdAt": "2026-06-03T12:01:00.000Z",
"target": {
"type": "post",
"id": "post_001",
"author": "tommy@example.com"
},
"reaction": "like",
"signature": {
"alg": "ES256",
"value": "..."
}
}open-social-network-cli- the easiest way to create and publish a sovereign Open Social Network pageopen-social-network-web- the easiest way to read, create, post, and export a pageopen-social-network-page- a sovereign page template
If you want to create a real Open Social Network identity instead of implementing the protocol directly, start with:
npx open-social-networkThe CLI creates a signed sovereign page, validates it, previews it locally, and deploys it to a free static host.
Open Social Network is in early alpha. The goal of this repository is to make the protocol understandable, testable, and implementable before expanding the ecosystem.
The ambition is large, but the first step is deliberately small: prove that a signed, sovereign, static social feed can exist and be read by any compatible client.
Open Social Network does not claim that decentralized social media starts here.
Mastodon, ActivityPub, Nostr, Bluesky/AT Protocol, Diaspora, Matrix, and the broader fediverse have already advanced open social infrastructure in important ways. They have explored federation, portable identity, relays, moderation, community governance, and protocol-based communication at real scale.
Open Social Network exists because we believe a few hard problems still need a simpler path for mainstream adoption.
Email has protocols. DNS has protocols. The web has protocols. AI systems are beginning to use open interoperability layers. Social identity should have the same kind of open, inspectable foundation instead of living only inside applications that can change the rules, the algorithm, or the audience relationship at any time.
This Core repository is where that foundation is specified, tested, and kept small.
- Identity is often attached to infrastructure. Many systems still ask users to depend on an instance, relay, provider, app, or hosted account namespace. Open Social Network starts from a sovereign web identity: a page and key that can move across hosts and interfaces.
- The user experience is still too technical. Most people want a profile, posts, follows, reactions, comments, messages, discoverability, and portability. They should not need to understand federation, relays, static hosting, keys, or JSON to participate.
- Creator ownership remains fragile. Visibility, reputation, audiences, and social history can still become tied to one app, one server, or one algorithm. Open Social Network is designed so followers, public actions, and reputation can become portable protocol data instead of platform data.
- Core systems can become too large to explain. Open Social Network keeps the base layer small: profiles, feeds, signed posts, signed public actions, encrypted messages, and discovery. More complex systems should be optional modules, not requirements for reading a page.
- Profiles belong to users, not platforms. A profile is a sovereign web identity, closer to a website, domain, or email identity than an account rented from an app.
- Followers belong to creators. Audience, reputation, and social history should be portable protocol data, not assets trapped inside one company database.
- Profiles are independent web pages. A social identity should be able to live on static hosting, a personal server, a community host, object storage, mirrors, or future compatible storage layers.
- Aggregators are replaceable. Aggregators browse, verify, rank, moderate, and display the network. They do not own the identities underneath.
- Algorithms should compete. Recommendation systems should influence discovery, not decide whether a person effectively exists online.
- The protocol has no global ban switch. Safety and moderation are real requirements, but they should be handled by hosts, apps, communities, filters, user choice, and applicable infrastructure law rather than a central protocol owner.
- Identity must be portable. Users should be able to migrate hosts, change providers, self-host, or create mirrors without losing identity or audience.
- Self-hosting must remain possible. Hosted providers can make the network easier, but the protocol must preserve the right to fully own and host a presence independently.
- The protocol belongs to nobody. Open Social Network is open source infrastructure, not a platform controlled by one company.
- Decentralization must stay practical. Users should experience simple actions: create a page, post, follow, react, comment, message, and publish. Protocol details should support verification without becoming a daily burden.
- Evolution must protect users. The protocol should remain modular, extensible, and forward-compatible so new capabilities do not break existing identities.
v0.1 is intentionally small. It focuses on sovereign profiles, signed feeds, signed public actions, encrypted direct-message envelopes, and static web compatibility.
The goal is not to defeat every previous approach. The goal is to learn from them and test a different primitive: social identity as ordinary web infrastructure, inspectable by developers and usable by normal people.
The protocol should feel closer to HTML or RSS for social identity than to a massive distributed operating system.
Open Social Network has not solved every hard problem in decentralized social media. Spam, safety, abuse, discovery, onboarding, moderation, scaling, and creator incentives require serious work.
This project exists to make that work possible on top of a simple foundation: user-owned social identity, signed public records, portable relationships, encrypted private communication, and interfaces that ordinary people can use.
The long-term goal is not to create the dominant social platform. The goal is to make social platforms optional.