The world of social video is filled with composition. There's an entire YouTube genre of "reaction videos" that are nothing more than the creator with someone else's content behind them. Twitch streamers frequently do watch parties for events. Tiktok allows users to make "duets", recording a new video alongside another users' content.

For the most part, when a user composes a new piece of content, video platforms forget about the provenance of that video. Maybe you get a link back to the original creator's video, usually not even that.

What if our social video platforms embraced this reality instead of treating every video as if it comes from a separate universe? What if you could tap a video and go back to the source? What if money you earned on your videos was automatically shared with everyone that helped create it? What if video existed outside of a single platform?

This post will focus on the technical details of Streamplace's segmentation format, but hopefully this gives some context on why we're building things this way. The goal is to build video primitives that exist outside of a given platform and can be combined, remixed, and attributed in an endless series of ways.

What would this world look like? Imagine the Sound of Settling music video, but every layer is a different user's livestream. Or a 100x100 grid of everyone playing Rocket League where you can click any user to zoom in and watch. There's a whole world of novel social video experiences that we're not getting from existing platforms.

Step 0: Invent the Universe

All decentralized social networks — all modern decentralized technology, really — uses hashing and content-addressing to ensure the integrity of content. Content identifiers (CIDs) are a concise way of identifying a piece of content in this way. The CID of my previous blog post is bafyreidehvg54k47rr2ykrrxu4btlmbehwyfstsrlmbecknjyl6ljwzk4i; change a single letter of my post and that CID will change to something else entirely. Once you have your content as a CID you can embed it in an atproto record or a nostr note or an NFT. This works well for a variety of media; text, images, and pre-recorded video can all follow this pattern.

Livestreams are harder because they haven't happened yet. You can't create a CID for the content of your livestream because you haven't created the content yet. So how are livestreams identified? If we solve this problem, that means we'll have invented decentralized livestreaming!

Streamplace takes a four-step approach to solving this problem:

1. Generate a stream key.

2. Slice up the stream into one-second MP4 files.

3. Give those segments an embedded C2PA signature.

4. Broadcast those segments all over the world.

Step 1: Generate a Stream Key

The first thing you do to stream on Streamplace is generate a stream keypair. These keys are secp256k1 keys, the same kind of keys used in Ethereum and ATProto. The public key gets posted publicly to your PDS as a place.stream.key record, formatted as a did:key.

The private key is used to authorize your broadcast; it gets pasted into your streaming software like OBS.

(If you're streaming from the Streamplace app or website, this all happens automatically behind the scenes and you don't even need to think about it!)

Step 2: Slice up your stream into one-second MP4 files

So you can model a livestream as somebody throwing a one-second video file in your face every second. In fact, for certain livestreaming protocols such as HLS and DASH, that's exactly what's happening behind the scenes: your computer is downloading a one-second video file every second and playing them back-to-back-to-back. With some cleverness around smooth, gapless playback between the files, you have no idea you're not looking a continuous livestream!

So that's what we do. As your stream comes in, we slice it up into one-second MP4 files. Later on, when the stream is played back, those MP4 files are stitched back together into a contiguous stream for you to watch, usually over WebRTC.

Again — they're literally just one-second MP4 files. If you install and stream through Streamplace locally, you can open up your data directory and see them, nothing mysterious here! Easy to understand, easy to work with, easy to integrate with other software.

Step 3: Sign

So we have a key and we have some MP4 files. How do we associate the two? Naively, we could hash the file, compute the signature, and pass around the signature along with the file.

This is how a lot of decentralized video project schemes work, and I don't care for it. The file itself is just an out-of-context MP4 file, and now you have to figure out how to package up the file and the signature separately. There's also an absence of metadata here — aside from the filename, how do we know how this livestream segment fits into the users' overall stream? Whose livestream is this, anyway? Thankfully, there's a better way.

The Coalition for Content Provenance and Authenticity (C2PA) is a video industry project spearheaded by Adobe and the BBC. More-or-less, it's the video industry's attempt to get us ready for a world full of deepfakes. In a world where anyone can generate a deepfake of whatever they like, how can anyone ever trust that the video they're watching is real? It's a hard problem, and no single technical solution can address it, but the C2PA's Content Credentials specification aims to tackle part of the problem.

There are two pieces of C2PA technology that Streamplace uses extensively: embedded manifests and composed assets.

Embedded manifests solve the problem of embedding the digital signature along with the asset. The C2PA created a novel mechanism of embedding metadata and a signature within the MP4 file itself, and this is what Streamplace makes use of. Using their c2patool command-line utility, we can look at a Streamplace segment and get lots of useful metadata:

// c2patool ./2025-07-29T02-44-13-762Z.mp4

{
  "active_manifest": "urn:uuid:a2bd4bea-7a60-4e08-9ac4-30df466a108a",
  "manifests": {
    "urn:uuid:a2bd4bea-7a60-4e08-9ac4-30df466a108a": {
      "assertions": [
        {
          "label": "place.stream.metadata",
          "data": {
            "dc:creator": "did:web:iame.li",
            "dc:date": [
              "2025-07-29T02:44:13.762Z"
            ],
            "@context": {
              "dc": "http://purl.org/dc/elements/1.1/"
            },
            "dc:title": [
              "livestream"
            ]
          }
        },
        {
          "label": "c2pa.actions",
          "data": {
            "actions": [
              {
                "action": "c2pa.created"
              },
              {
                "action": "c2pa.published"
              }
            ]
          }
        }
        // more assertions snipped
      ],
      "title": "Livestream Segment at 2025-07-29T02:44:13.762Z",
      "format": "video/mp4",
      "instance_id": "xmp:iid:3284df66-7da1-4100-ba0f-43ab1f7e002a",
      "ingredients": [],
      "signature_info": {
        "alg": "Es256k",
        "cert_serial_number": "230373535735746111442106637652378510039",
        "time": "2025-07-29T02:44:13+00:00"
      },
      "label": "urn:uuid:a2bd4bea-7a60-4e08-9ac4-30df466a108a"
    }
  }
}

Full manifest available here.

Now we're talking! Not only does this format allow us to embed the signature right alongside the broadcast, it also allows us to embed arbitrary metadata alongside the video content. In this case we're embedding the creator (did:web:iame.li) and a timestamp for the video, but we have plans to use this mechanism to embed all sorts of metadata, especially regarding user consent. Who do you allow to rebroadcast your video? Are other users allowed to remix your video, in the style of a TikTok duet? All of these sorts of things can be embedded right alongside the video in this manifest — more on these mechanisms coming soon!

Speaking of remixing — the other piece of C2PA tech that we're planning on utilizing is asset composition. This allows a new piece of media to be created that uses other segments as ingredients, such as the aforementioned Tiktok duet. This allows the provenance of the data to be related back to the original creator. In the future we'll be using this for attribution and potentially even payments and tipping!

(Editor's note: I'm referring to all of this stuff as "C2PA" signing, but unfortunately everything we do is, in fact, 0% compatible with the C2PA specification in any way whatsoever. Plausibly, Adobe could even sue me for misusing the trademark. This is because, of course, that the C2PA supports 256-bit ECDSA signing using the secp256r1 curve, and Streamplace uses 256-bit ECDSA signing using the secp256k1 curve. That may not SEEM like a meaningful distinction, but in fact... no, wait, it doesn't seem like a meaningful distinction to me, either. My efforts to get the C2PA to add K-256 support have gone nowhere. My suspicion is that someone at some level told an Adobe executive that K-256 is used for blockchain, and blockchain is bad. I dunno. In the meantime, Streamplace is maintaining a fork of the c2pa Rust library.)

Step 4: Broadcast

Let's gooooooo! Now that your video is signed, it can be sent all over the world. Other Streamplace nodes can choose to syndicate your livestream, rebroadcasting your data in a manner consistent with your wishes. Viewers can download the stream from any sketchy corner of the internet and be confident that they're looking at the right thing. We've successfully invented decentralized livestreaming!

I'm being a little hand-wavey here because we haven't built most of the functionality there. There's a very basic proof-of-concept mechanism for pushing signed Streamplace segments from one host to another — we know that it works — but it's not yet production ready. Building internet-scale low-latency data replication is a big order, so we've decided to enlist some help! I'm excited to announce two collaborations that are kicking off this week:

• The Hypha Worker Co-operative (@hypha.coop) is coming onboard to help us flesh out the details of the "Streamplace Protocol" — how exactly does a user express how they want their video to be used, and how is that displayed to the end user in the player?

• Brendan from n0.computer, creator of Iroh (@iroh.computer) is going to help us build out internet-scale replication for Streamplace segments. Iroh is a Rust library that's already in production in other contexts, doing efficient node-to-node replication of livestreaming segments.

With these collaborations, we're going to be evolving Streamplace into a project that's ready to handle the entire world's social video. Watch this space for more to come!

Thanks for reading! Streamplace is building decentralized livestreaming for decentralized social networks — if this kind of thing is exciting to you, check our Jobs page or join the Discord!