skyless/spec/v0.1.md at main · skylessdev/skyless

Skyless Federation Spec v0.1

Status: Ratified
Date: January 2026
Authority: This specification defines conformant behavior for Skyless-compatible nodes.

1. Purpose

This specification defines the minimum requirements for federated, permissionless radio broadcasting. A conformant implementation allows any party to broadcast audio, relay streams, and discover other broadcasters without requiring central coordination or platform permission.

2. Invariants

These properties MUST hold for any conformant implementation:

No single point of control - No node, including the original implementer, can prevent another conformant node from operating
Identity without accounts - Broadcasters prove identity cryptographically, not through registration. Conformant implementations MUST NOT require accounts or registration to listen to publicly announced streams.
Broadcast survives node failure - Stream availability does not depend on any single node’s uptime
Verification without trust - Any party can verify claims without trusting the claimant

2.5 Non-Accumulative Identity

This specification deliberately makes identity ephemeral and non-accumulative.

Broadcasters MAY rotate keys at any time. Key rotation is a breaking change to identity by design (see Section 5.3). There is no mechanism within this protocol for follows, reputation tracking, or identity persistence beyond the broadcast itself.

This design enables verification to scale fractally—announcements verified by relays verified by listeners—without identity accumulating power at any scale.

Skyless demonstrates that cryptographic integrity does not require identity persistence. For discussion of this property in broader coordination systems, see this paper.

3. Threat Model & Non-Goals

Defends Against

Central authority censorship or deplatforming
Silent suppression of broadcasts
Identity impersonation or hijacking
Single points of failure

Does Not Solve

Content quality or moderation
Popularity or discovery algorithms
Monetization or payment
Bandwidth costs or spam prevention

These concerns are intentionally left to higher layers or out-of-band mechanisms.

4. Core Concepts

Node

Any system that implements this specification. Nodes may broadcast, relay, or only listen.

Broadcaster

An entity that produces audio streams. Identified by a public key, not a username or account.

Stream

A live audio transmission. Identified by a content address or endpoint announced by a broadcaster.

Announcement

A signed message declaring stream availability, published by a broadcaster.

Schedule

Optional metadata describing planned broadcast times and show information.

5. Identity & Keys

5.1 Key Generation

Broadcasters MUST generate an Ed25519 key pair
The public key serves as the broadcaster’s permanent identifier
Private keys MUST remain under broadcaster control at all times

5.2 Key Format

Public keys MUST be represented as:

Base58-encoded Ed25519 public key (32 bytes)
Example: 8SDqyJ9wzQPBvGmY7JZ8mqN7fLCoXFQfnKcPJEVQKF2s

5.3 Key Rotation

Key rotation is a breaking change to broadcaster identity
If a broadcaster loses their private key, they MUST generate a new identity
There is no key recovery mechanism by design

6. Stream Announcement

6.1 Announcement Structure

Broadcasters publish signed JSON objects:

{
  "version": "skyless/0.1",
  "type": "stream_announcement",
  "broadcaster": "8SDqyJ9wzQPBvGmY7JZ8mqN7fLCoXFQfnKcPJEVQKF2s",
  "timestamp": "2024-12-16T20:30:00Z",
  "stream": {
    "url": "https://relay1.example.com/live/stream.opus",
    "format": "audio/opus",
    "bitrate": 128000
  },
  "signature": "3fK8s9dL2mP..."
}

6.2 Required Fields

version - MUST be “skyless/0.1”
type - MUST be “stream_announcement”
broadcaster - Public key of the broadcaster
timestamp - ISO 8601 UTC timestamp of announcement
stream.url - Endpoint where stream is available
stream.format - MIME type of audio stream
signature - Ed25519 signature of the canonical JSON (see 9.1)

6.3 Optional Fields

stream.bitrate - Bits per second (integer)
relay_urls - Array of alternate stream endpoints
ttl - Seconds until announcement expires (default: 3600)

6.4 Publication

Announcements MAY be published via HTTP, gossip protocols, or any transport
Nodes MAY cache announcements for the duration of their TTL
Expired announcements MUST be discarded

7. Schedule Metadata

7.1 Schedule Structure

Broadcasters MAY publish schedules:

{
  "version": "skyless/0.1",
  "type": "schedule",
  "broadcaster": "8SDqyJ9wzQPBvGmY7JZ8mqN7fLCoXFQfnKcPJEVQKF2s",
  "timestamp": "2024-12-16T20:00:00Z",
  "shows": [
    {
      "title": "Late Night Signal",
      "start": "2024-12-16T22:00:00Z",
      "end": "2024-12-17T00:00:00Z",
      "description": "Ambient explorations"
    }
  ],
  "signature": "9mK2s1dL8pQ..."
}

7.2 Required Fields

version, type, broadcaster, timestamp, signature (as above)
shows - Array of show objects
shows[].title - Human-readable show name
shows[].start - ISO 8601 UTC start time
shows[].end - ISO 8601 UTC end time

7.3 Schedule Semantics

Schedules are statements of intent, not guarantees
Actual stream availability is determined by announcements only
Schedules MAY be updated at any time by publishing a new signed schedule

8. Archive Pointer (Optional)

8.1 Archive Structure

Broadcasters MAY reference completed broadcasts:

{
  "version": "skyless/0.1",
  "type": "archive",
  "broadcaster": "8SDqyJ9wzQPBvGmY7JZ8mqN7fLCoXFQfnKcPJEVQKF2s",
  "timestamp": "2024-12-16T23:00:00Z",
  "show_title": "Late Night Signal",
  "recorded": "2024-12-16T22:00:00Z",
  "duration": 7200,
  "content": {
    "url": "ipfs://QmX8s2K9dL3pM...",
    "format": "audio/opus",
    "size": 115200000
  },
  "signature": "7jL9s3dK5mN..."
}

8.2 Archive Semantics

Archives are OPTIONAL for conformance
A node that cannot archive but can broadcast live is fully compliant
Archives SHOULD use content-addressed storage (IPFS, Arweave, etc.)
Archives MAY use traditional URLs if content-addressed storage is unavailable

8.3 Liveness Over Permanence

Live presence is the primary function. Archives exist to preserve, not replace, the live experience.

9. Verification Rules

9.1 Signature Verification

To verify any signed message:

Extract the signature field from the JSON
Construct canonical JSON by:

Removing the signature field
Sorting keys alphabetically
Using compact JSON (no whitespace)

Verify the signature against canonical JSON using the broadcaster’s public key

Example (pseudocode):

def verify(message):
    sig = message.pop('signature')
    canonical = json.dumps(message, sort_keys=True, separators=(',',':'))
    return ed25519_verify(broadcaster_pubkey, canonical.encode(), sig)

9.2 Timestamp Validation

Nodes SHOULD reject announcements with timestamps more than 5 minutes in the future
Nodes MAY reject announcements older than their TTL

9.3 Trust Model

Verification MUST NOT require contacting the broadcaster
Verification MUST NOT require querying a central authority
Any party with the public key can verify any signed message

10. Conformance

10.1 Minimal Conformant Node

A conformant node MUST:

Generate or import an Ed25519 key pair
Sign announcements as specified in section 6
Verify signatures as specified in section 9

A conformant node MAY:

Publish schedules
Publish archives
Relay streams from other broadcasters
Implement discovery mechanisms

10.2 Violation

An implementation violates this specification if:

It publishes unsigned announcements
It requires registration or accounts for broadcasting
It introduces a single point of failure for stream discovery
It cannot verify announcements without external dependencies

If the specification is ambiguous and an implementation can reasonably interpret it multiple ways, the specification MUST be revised, not the implementation.

11. Extension Points

11.1 Additional Message Types

Implementations MAY define new message types beyond stream_announcement, schedule, and archive. New types MUST:

Include version, type, broadcaster, timestamp, signature
Follow the same verification rules
Not break core conformance

11.2 Discovery Mechanisms

This specification does NOT mandate how nodes discover each other. Implementations MAY use:

DHT-based discovery
DNS records
HTTP directories
Gossip protocols
Manual peer lists

Discovery is intentionally left open to enable experimentation.

Discovery non-authoritativeness: No discovery mechanism may be required for conformance, and no single discovery mechanism may be treated as authoritative. Clients SHOULD support multiple discovery mechanisms or allow user-supplied peers.

11.3 Transport Layers

Announcements and streams MAY use any transport: HTTP, WebRTC, raw TCP, WebSockets, etc. The specification is transport-agnostic.

12. Forkability & Stewardship

12.1 Forkability

Any party may implement, fork, or extend this specification without permission, provided extensions do not break core conformance as defined in section 10.

12.2 Stewardship

Skyless Innovation LLC acts as the initial steward of this specification but holds no authority to prevent conformant implementations. If this specification becomes obsolete or abandoned, any party may create a successor specification.

Origin does not imply authority: No implementation, registry, directory, or service operated by Skyless Innovation LLC shall be considered authoritative by virtue of origin alone.

12.3 Version Evolution

Breaking changes MUST increment the version identifier
Implementations MUST declare which version they conform to
Multiple versions MAY coexist in the network

13. Reference Implementation

A reference implementation demonstrating minimal conformance will be published at skyless.network/reference within 90 days of this specification’s release.

Until then, this specification is the sole source of truth.

End of Specification

This document defines Skyless Federation v0.1. Implementations conforming to this specification are Skyless-compatible, regardless of who builds them or what additional features they include.

FilesExpand file tree

v0.1.md

Latest commit

History