A step-by-step walkthrough of the protocol. From a simple JSON file to a fully encrypted, signed social profile.
Eight building blocks, each adding a layer. Start simple, go deep.
At its core, an SPXP profile is a simple JSON file served via HTTP. Any web server will do. There's no special software required — just a static file host and a URL, called the Profile URI.
You can fetch any SPXP profile with curl. It's just an HTTP GET request.
{
"ver": "0.3",
"name": "Crypto Alice",
"shortInfo": "I love cryptography.",
"gender": "female",
"email": "cryptoalice@example.com"
}Profiles are identified by a unique Profile Key — an Ed25519 public key embedded in the profile JSON. This key is what makes your identity portable and verifiable.
The key uses the JWK (JSON Web Key) format. The kid is a unique identifier, crv: "Ed25519" specifies the curve, and x is the base64url-encoded public key bytes.
{
"ver": "0.3",
"name": "Crypto Alice",
"shortInfo": "I love cryptography.",
"publicKey": {
"kid": "C8xSIBPKRTcXxFqnvVe4TCVUpuibuFFEqhE98Hfc9Vk",
"kty": "OKP",
"crv": "Ed25519",
"x": "skpRppgAopeYo9MWRdExl26rGA_z701tMoiuJ-jIjU8"
}
}The profile is authenticated by a digital signature. The profile owner signs the content with their private key. Clients can verify this signature using the public key embedded in the profile.
This means nobody can forge your profile or tamper with its content. If the signature doesn't verify, the client knows the data is compromised.
{
"ver": "0.3",
"name": "Crypto Alice",
"shortInfo": "I love cryptography.",
"publicKey": {
"kid": "C8xSIBPKRTcXxFqnvVe4TCVUpuibuFFEqhE98Hfc9Vk",
"kty": "OKP",
"crv": "Ed25519",
"x": "skpRppgAopeYo9MWRdExl26rGA_z701tMoiuJ-jIjU8"
},
"signature": {
"key": "C8xSIBPKRTcXxFqnvVe4TCVUpuibuFFEqhE98Hfc9Vk",
"sig": "sRBHqhqGBnTWLbGzHLCNrVGKB9RIjVEfMXrLbS..."
}
}Profiles can verifiably reference other profiles. For example, linking to your hometown or employer. The reference includes both a URI and the expected public key of the referenced profile.
A client can fetch the referenced profile, verify that its key matches the embedded publicKey, and confirm the reference is authentic. This builds a cryptographically verifiable web of trust.
{
"ver": "0.3",
"name": "Crypto Alice",
"hometown": {
"uri": "https://example.com/spxp/Munich",
"publicKey": {
"kid": "ZKL...abc",
"kty": "OKP",
"crv": "Ed25519",
"x": "abc123..."
}
},
"signature": {
"key": "C8xSIBPKRTcXxFqnvVe4TCVUpuibuFFEqhE98Hfc9Vk",
"sig": "sRBHqhqGBnTWLbGzHLC..."
}
}
For private content, SPXP uses JWE (JSON Web Encryption). The private array contains JWE tokens — encrypted blobs that only authorized recipients can decrypt.
The server stores and serves these encrypted tokens without ever being able to read them. Even the fact that specific content exists can be hidden from the server.
{
"ver": "0.3",
"name": "Crypto Alice",
"private": [
"eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2Q0JDLUhTNTEyIn0...",
"eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2Q0JDLUhTNTEyIn0..."
],
"signature": {
"key": "C8xSIBPKRTcXxFqnvVe4TCVUpuibuFFEqhE98Hfc9Vk",
"sig": "sRBHqhqGBnTWLbGzHLC..."
}
}A profile can link to additional endpoints. The friends endpoint provides a paginated list of friend profiles (also encrypted with JWE). The posts endpoint provides a time series of posts.
These endpoints can be on the same server or on entirely different servers. The architecture is flexible by design.
{
"ver": "0.3",
"name": "Crypto Alice",
"publicKey": { ... },
"friendsEndpoint": "https://example.com/spxp/alice/friends",
"postsEndpoint": "https://example.com/spxp/alice/posts",
"signature": {
"key": "C8xSIBPKRTcXxFqnvVe4TCVUpuibuFFEqhE98Hfc9Vk",
"sig": "sRBHqhqGBnTWLbGzHLC..."
}
}
The posts endpoint returns a time-ordered series of posts. Each post has a sequence timestamp (seqts), a type, content, and its own signature.
Posts can be text, links, images, and more. Each is individually signed, so tampering with any post is cryptographically detectable. Private posts in the feed are encrypted with JWE.
{
"data": [
{
"seqts": "2018-09-17T14:04:27.373",
"type": "text",
"message": "Hello, world!",
"signature": {
"key": "C8xSIBPKRTcXxFqnvVe4TCVUpuibuFFEqhE98Hfc9Vk",
"sig": "sRBHq..."
}
},
{
"seqts": "2018-09-15T12:35:47.735",
"type": "web",
"message": "Interesting read...",
"link": "https://example.com/article",
"signature": { ... }
}
],
"more": true
}SPXP doesn't invent custom cryptography. It uses proven, battle-tested internet standards with decades of scrutiny. This means the security properties are well-understood and the implementations are widely available.
"Don't roll your own crypto" is a cardinal rule in security engineering. SPXP follows it.
SPXP's topology is more like the World Wide Web than a traditional social network.
+-------------------------------------------+
| SPXP Network |
| |
| +----------+ +----------+ |
| | Server | | Server | |
| | (Alice) | | (Bob) | |
| +----+-----+ +----+-----+ |
| | | |
| | HTTP/JSON | |
| v v |
| +-----------------------------+ |
| | Client App | |
| | (fetch, verify, display) | |
| +-----------------------------+ |
| |
| * No central server |
| * Client controls the experience |
| * Servers are just file hosts |
+-------------------------------------------+
All clients connect to one central server. The platform controls all data, all feeds, all moderation. A single outage or policy change affects everyone. Your data lives on their servers, at their discretion.
Each profile lives on its own server. Clients fetch profiles directly over HTTP. There's no single point of failure and no single point of control. Like the WWW: resilient, distributed, and open.
The protocol defines how profiles and posts are structured. The client decides how to present them. Feed ranking, notifications, UI/UX — all in the hands of the app developer and, ultimately, the user.
SPXP uses well-established standards. No custom crypto, no surprises.
Ed25519 (RFC 8032) is a modern, fast, and secure signature scheme based on the Edwards curve over the prime field defined by 2²⁵⁵ − 19. It's used by TLS, SSH, and many other security-critical protocols.
Every profile and every post is signed with Ed25519. This ensures authenticity — clients can verify that the content hasn't been tampered with.
JWE (JSON Web Encryption, RFC 7516) is the IETF standard for representing encrypted content using JSON. It supports multiple algorithms and is widely used in OAuth 2.0 and OpenID Connect.
SPXP uses JWE to encrypt private posts and sections of the friend list. The server stores opaque encrypted blobs and can serve them without knowing their content.
Curve25519 (RFC 7748) is a Diffie-Hellman key exchange function. X25519 (the DH function using Curve25519) is used for encrypted connections between profile owners.
When two users connect privately, X25519 is used to establish a shared secret that can be used to derive encryption keys. This is the "E2E" part of end-to-end encryption.
"Don't roll your own crypto" is a fundamental rule in security engineering. Custom cryptographic schemes haven't been peer-reviewed. They may look strong but have subtle flaws that attackers can exploit.
By using RFC-standardized algorithms, SPXP benefits from decades of cryptanalysis. Any weakness would have been found by the global security research community already.
Every standard used in SPXP is an IETF RFC with a public specification.
| Standard | RFC | Used For | Link |
|---|---|---|---|
| HTTP | RFC 7230 | Transport protocol | tools.ietf.org → |
| JSON | RFC 8259 | Data format | tools.ietf.org → |
| JWE | RFC 7516 | Encryption (private posts) | tools.ietf.org → |
| JWK | RFC 7517 | Key representation | tools.ietf.org → |
| Ed25519 | RFC 8032 | Digital signatures | tools.ietf.org → |
| X25519 | RFC 7748 | Key exchange (E2E) | tools.ietf.org → |
| OKP JWK | RFC 8037 | OKP key representation | tools.ietf.org → |
The full protocol specification and a quickstart guide are available on GitHub.