forked from laantungir/super_ball
Created kind 12222
This commit is contained in:
Your Name
140
SUPs.md
140
SUPs.md
@@ -1,33 +1,19 @@
|
||||
# SUPs - Superball Upgrade Possibilities
|
||||
|
||||
SUPs (Superball Upgrade Possibilities) describe standards for the Superball anonymity protocol, including core protocol rules, daemon behavior specifications, routing algorithms, and security mechanisms.
|
||||
SUPs (Superball Upgrade Possibilities) describe standards for the Superball anonymity protocol, including core protocol rules, Thrower behavior specifications, routing algorithms, and security mechanisms.
|
||||
|
||||
## SUP Types
|
||||
## Terminology
|
||||
- **Superball**: A wrapped nostr event (like a TOR onion packet) that bounces between relays and Throwers
|
||||
- **Thrower**: A nostr-capable daemon that monitors nostr nodes, looks for superballs posted for them, grabs them, cryptographically unwraps them, rewraps them potentially with padding, then throws the superball to relay(s) when instructed
|
||||
|
||||
- **Standards Track**: SUPs that affect protocol compatibility
|
||||
- **Informational**: General guidelines and information
|
||||
- **Process**: Procedures and governance for the SUP process
|
||||
|
||||
## SUP Status
|
||||
|
||||
- **Draft**: Initial specification under development
|
||||
- **Proposed**: Ready for community review
|
||||
- **Final**: Accepted and implemented
|
||||
- **Replaced**: Superseded by newer SUP
|
||||
- **Withdrawn**: No longer pursued
|
||||
|
||||
---
|
||||
|
||||
## SUP-1: Core Protocol Specification
|
||||
|
||||
**Type**: Standards Track
|
||||
**Status**: Final
|
||||
**Author**: Alice & Contributors
|
||||
**Created**: 2024-01-17
|
||||
|
||||
### Abstract
|
||||
|
||||
This SUP defines the core Superball protocol for providing location privacy in Nostr through encrypted event routing via daemon nodes. Users can post content under their real identity while completely hiding their network location.
|
||||
This SUP defines the core Superball protocol for providing location privacy in Nostr through encrypted event routing via Thrower nodes. Users can post content under their real identity while completely hiding their network location.
|
||||
|
||||
### Motivation
|
||||
|
||||
@@ -45,7 +31,7 @@ Current Nostr implementations reveal users' network locations through direct rel
|
||||
"pubkey": "<ephemeral_key>",
|
||||
"content": "<nip44_encrypted_payload>",
|
||||
"tags": [
|
||||
["p", "<superball_pubkey>"],
|
||||
["p", "<thrower_pubkey>"],
|
||||
["p", "<audit_pubkey>"],
|
||||
["padding", "<random_data>"]
|
||||
],
|
||||
@@ -63,7 +49,7 @@ Current Nostr implementations reveal users' network locations through direct rel
|
||||
"relays": ["wss://relay1.com", "wss://relay2.com"],
|
||||
"delay": 30,
|
||||
"padding": "+150",
|
||||
"p": "next_superball_pubkey", // Optional
|
||||
"p": "next_thrower_pubkey", // Optional
|
||||
"audit": "audit_verification_pubkey", // Required
|
||||
"payment": "ecash_token" // Optional
|
||||
}
|
||||
@@ -85,18 +71,13 @@ The protocol uses NIP-44 encryption for simplicity over NIP-59 gift wrapping, in
|
||||
|
||||
## SUP-2: Audit Security Mechanism
|
||||
|
||||
**Type**: Standards Track
|
||||
**Status**: Final
|
||||
**Author**: Alice & Contributors
|
||||
**Created**: 2024-01-17
|
||||
|
||||
### Abstract
|
||||
|
||||
This SUP defines the audit mechanism that allows users to detect malicious Superballs through cryptographic verification of proper event forwarding.
|
||||
This SUP defines the audit mechanism that allows users to detect malicious Throwers through cryptographic verification of proper event forwarding.
|
||||
|
||||
### Motivation
|
||||
|
||||
Users need the ability to verify that Superballs are honestly forwarding events according to instructions, including proper delays, padding operations, and relay posting.
|
||||
Users need the ability to verify that Throwers are honestly forwarding Superballs according to instructions, including proper delays, padding operations, and relay posting.
|
||||
|
||||
### Specification
|
||||
|
||||
@@ -111,7 +92,7 @@ Users need the ability to verify that Superballs are honestly forwarding events
|
||||
2. Monitor specified relays for audit tag appearance
|
||||
3. Verify timing matches delay instructions
|
||||
4. Verify event size matches padding operations
|
||||
5. Build reputation scores for Superballs based on compliance
|
||||
5. Build reputation scores for Throwers based on compliance
|
||||
|
||||
#### Privacy Properties
|
||||
- Audit tags indistinguishable from real next-hop pubkeys
|
||||
@@ -140,7 +121,7 @@ const monitorAudit = async (relay, auditTag, expectedDelay, expectedSize) => {
|
||||
const delayCompliant = Math.abs(actualDelay - expectedDelay) < TOLERANCE;
|
||||
const sizeCompliant = Math.abs(actualSize - expectedSize) < PADDING_TOLERANCE;
|
||||
|
||||
recordSuperballReputation(event.pubkey, delayCompliant && sizeCompliant);
|
||||
recordThrowerReputation(event.pubkey, delayCompliant && sizeCompliant);
|
||||
}
|
||||
});
|
||||
};
|
||||
@@ -150,14 +131,9 @@ const monitorAudit = async (relay, auditTag, expectedDelay, expectedSize) => {
|
||||
|
||||
## SUP-3: Daemon Operational Rules
|
||||
|
||||
**Type**: Informational
|
||||
**Status**: Final
|
||||
**Author**: Superball Operators
|
||||
**Created**: 2024-01-17
|
||||
|
||||
### Abstract
|
||||
|
||||
This SUP provides operational guidelines for Superball daemon operators, including security practices, resource management, and privacy protection protocols.
|
||||
This SUP provides operational guidelines for Thrower operators, including security practices, resource management, and privacy protection protocols.
|
||||
|
||||
### Security Rules
|
||||
1. **Never log sensitive data** - Don't store decrypted content or routing information
|
||||
@@ -182,18 +158,13 @@ This SUP provides operational guidelines for Superball daemon operators, includi
|
||||
|
||||
## SUP-4: Multi-Path Routing Enhancement
|
||||
|
||||
**Type**: Standards Track
|
||||
**Status**: Draft
|
||||
**Author**: Security Researchers
|
||||
**Created**: 2024-01-17
|
||||
|
||||
### Abstract
|
||||
|
||||
This SUP proposes an enhancement allowing users to send the same event through multiple independent Superball chains simultaneously for increased security against coordinated attacks.
|
||||
This SUP proposes an enhancement allowing users to send the same event through multiple independent Thrower chains simultaneously for increased security against coordinated attacks.
|
||||
|
||||
### Motivation
|
||||
|
||||
Single routing chains are vulnerable to adversaries who control multiple nodes in the path. Multi-path routing increases security by requiring adversaries to control nodes across multiple independent chains.
|
||||
Single routing chains are vulnerable to adversaries who control multiple Throwers in the path. Multi-path routing increases security by requiring adversaries to control Throwers across multiple independent chains.
|
||||
|
||||
### Specification
|
||||
|
||||
@@ -207,7 +178,7 @@ Single routing chains are vulnerable to adversaries who control multiple nodes i
|
||||
},
|
||||
{
|
||||
"chain_id": "random_identifier_2",
|
||||
"routing": { /* Different Superballs and relays */ }
|
||||
"routing": { /* Different Throwers and relays */ }
|
||||
}
|
||||
],
|
||||
"threshold": 1 // Minimum successful deliveries required
|
||||
@@ -215,7 +186,7 @@ Single routing chains are vulnerable to adversaries who control multiple nodes i
|
||||
```
|
||||
|
||||
#### Implementation Requirements
|
||||
- Generate independent routing chains with no overlapping Superballs
|
||||
- Generate independent routing chains with no overlapping Throwers
|
||||
- Use different target relays for each path
|
||||
- Include chain_id in audit mechanism for path-specific monitoring
|
||||
- Consider delivery successful when threshold number of paths complete
|
||||
@@ -231,14 +202,9 @@ Single routing chains are vulnerable to adversaries who control multiple nodes i
|
||||
|
||||
## SUP-5: Payment Integration Specification
|
||||
|
||||
**Type**: Standards Track
|
||||
**Status**: Proposed
|
||||
**Author**: Economic Protocol Designers
|
||||
**Created**: 2024-01-17
|
||||
|
||||
### Abstract
|
||||
|
||||
This SUP defines the integration of eCash payment tokens for monetized Superball services, enabling sustainable economic models for privacy infrastructure.
|
||||
This SUP defines the integration of eCash payment tokens for monetized Thrower services, enabling sustainable economic models for privacy infrastructure.
|
||||
|
||||
### Specification
|
||||
|
||||
@@ -268,14 +234,76 @@ This SUP defines the integration of eCash payment tokens for monetized Superball
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## SUP-6: Thrower Information Document
|
||||
|
||||
### Abstract
|
||||
|
||||
This SUP defines a standardized announcement mechanism for Throwers to advertise their services and signal their online status through replaceable events.
|
||||
|
||||
### Motivation
|
||||
|
||||
Users need a reliable way to discover available Throwers and verify their operational status. This SUP provides a standardized format for Throwers to announce their services and capabilities. By specifying a refresh rate, one can see if the document has been created within that refresh rate, and if so, you know that the Thrower is online.
|
||||
|
||||
### Specification
|
||||
|
||||
#### Event Kind
|
||||
- **Kind 12222**: Thrower Information Document (Replaceable Event)
|
||||
|
||||
#### Event Structure
|
||||
```json
|
||||
{
|
||||
"id": "<32-bytes lowercase hex-encoded sha256 of the serialized event data>",
|
||||
"pubkey": "<32-bytes lowercase hex-encoded public key of the Thrower>",
|
||||
"created_at": "<unix timestamp in seconds>",
|
||||
"kind": 12222,
|
||||
"tags": [
|
||||
["name", "<string identifying Thrower>"],
|
||||
["description", "<string with detailed information>"],
|
||||
["banner", "<a link to an image (e.g. in .jpg, or .png format)>"],
|
||||
["icon", "<a link to an icon (e.g. in .jpg, or .png format>)"],
|
||||
["pubkey", "<administrative contact pubkey>"],
|
||||
["contact", "<administrative alternate contact>"],
|
||||
["supported_sups", "<a list of SUP numbers supported by the Thrower>"],
|
||||
["software", "<string identifying Thrower software URL>"],
|
||||
["version", "<string version identifier>"],
|
||||
["privacy_policy", "<a link to a text file describing the Thrower's privacy policy>"],
|
||||
["terms_of_service", "<a link to a text file describing the Thrower's terms of service>"],
|
||||
["refresh_rate", "<if the Thrower is online, it will refresh this document within this many seconds>"]
|
||||
],
|
||||
"content": "<arbitrary string>",
|
||||
"sig": "<64-bytes lowercase hex of the signature>"
|
||||
}
|
||||
```
|
||||
|
||||
#### Operational Requirements
|
||||
|
||||
1. **Service Announcement**: Inform users on a relay of the Thrower's presence
|
||||
2. **Liveness Signal**: By updating the document within its refresh rate, signals that the Thrower is currently online
|
||||
3. **Discovery**: Enable automated discovery of available Throwers by clients
|
||||
|
||||
#### Implementation Guidelines
|
||||
|
||||
- Update frequency should indicate operational status
|
||||
- Include comprehensive service information in tags
|
||||
- Use standard URLs for policy documents
|
||||
- Maintain consistent pubkey identity across announcements
|
||||
|
||||
### Rationale
|
||||
|
||||
Standardized service announcements enable better user experience through automated Thrower discovery and verification of operational status through regular updates.
|
||||
|
||||
---
|
||||
|
||||
## Future SUP Topics
|
||||
|
||||
### Proposed Enhancements
|
||||
- **SUP-6**: Zero-Knowledge Proof Integration for Verifiable Delays
|
||||
- **SUP-7**: Decentralized Superball Discovery Protocol
|
||||
- **SUP-8**: Quantum-Resistant Encryption Migration
|
||||
- **SUP-9**: Mobile Client Optimizations
|
||||
- **SUP-10**: Governance and Protocol Upgrade Mechanisms
|
||||
- **SUP-7**: Zero-Knowledge Proof Integration for Verifiable Delays
|
||||
- **SUP-8**: Decentralized Thrower Discovery Protocol Enhancement
|
||||
- **SUP-9**: Quantum-Resistant Encryption Migration
|
||||
- **SUP-10**: Mobile Client Optimizations
|
||||
- **SUP-11**: Governance and Protocol Upgrade Mechanisms
|
||||
|
||||
### Research Areas
|
||||
- Traffic analysis resistance measurements
|
||||
|
||||
Reference in New Issue
Block a user