I’ve been working on a very small, open video protocol called “arkA”. The idea is simple: instead of video being tied to a particular platform, account system, or backend, arkA defines a minimal JSON metadata format that points to a video stored anywhere (IPFS, S3, Arweave, Cloudflare R2, or a personal server).
This week the first end-to-end MVP went live. It demonstrates that the core idea works in practice.
No backend is involved; it’s just the browser loading the video from a decentralized gateway using the metadata.
*Why I’m building this:*
Most video systems combine storage, accounts, recommendation logic, monetization, and delivery into one large platform. arkA experiments with unbundling those pieces. If storage, metadata, and playback are separate concerns, anyone can host videos and anyone can build clients to display them.
*Current state:*
- A small static reference client (~60 lines of JavaScript)
- One example video published via IPFS/Pinata
- Basic JSON metadata
- Early schema drafts in the repo
*What I’m looking for:*
Feedback on the protocol idea, criticism of the MVP architecture, suggestions for metadata/schema versioning, and perspectives from people familiar with distributed storage systems (IPFS/IPNS/IPLD, Arweave, S3-compatible systems, etc).
This is extremely early. There’s no platform, no company, and no plans for lock-in. Just a small protocol experiment that might be useful if it grows.
I like what I see so far. I might suggest you use an Abstract Dynamic Structured Data system instead of mandating JSON. (check out https://www.ietf.org/archive/id/draft-hamrick-vwrap-type-sys... as an example.) Many (most?) of the SecondLife HTTP API endpoints could accept JSON, XML or our homebrew binary format and would automagically parse it based on the content-type of the blob that was posted. It was useful because we kept getting into arguments about whether we should use JSON or XML.
I think you may find communities out there who will insist on JSON, YAML or ProtoBufs, so specifying things in an abstract "super-class" might be able to get past the arguments of how data is represented on the wire and onto arguments about what the data represents.
I should probably go write some code to make it more obvious what I'm talking about.
With respect to schema versioning, Doug Kaye wrote a book called "Loosely Coupled" and even though it's from the 2000s when everyone thought everything was going to be Web Services everywhere, it still has a decent description of the problem. It's not so great a book as for me to recommend buying it, but it's definitely worth checking out from the library:
It was nice to see IPFS being used but very difficult to see it applied to general usage and even with browsers like Brave giving support, it never really got adopted because it simply isn't usable. Anyone installing it on a server will understand why.
What I have been seeing as alternative is Blossom from the NOSTR platform. It became the defacto decentralized distribution protocol for media. Basically delivered what IPFS was promising with quite a dazzling simplicity.
When using it, you aren't tied to servers and your connections to other relays will do their best effort to retrieve the associated files. It works OK for media, just mentioning because in case you don't see much active development on IPFS is because the cool stuff has been something else since a while.
I’ve been working on a very small, open video protocol called “arkA”. The idea is simple: instead of video being tied to a particular platform, account system, or backend, arkA defines a minimal JSON metadata format that points to a video stored anywhere (IPFS, S3, Arweave, Cloudflare R2, or a personal server).
This week the first end-to-end MVP went live. It demonstrates that the core idea works in practice.
*Live demo client (static HTML/JS on GitHub Pages):* https://baconpantsuppercut.github.io/arkA/
*Example video stored on IPFS (via Pinata):* https://cyan-hidden-marmot-465.mypinata.cloud/ipfs/bafybeigx...
No backend is involved; it’s just the browser loading the video from a decentralized gateway using the metadata.
*Why I’m building this:* Most video systems combine storage, accounts, recommendation logic, monetization, and delivery into one large platform. arkA experiments with unbundling those pieces. If storage, metadata, and playback are separate concerns, anyone can host videos and anyone can build clients to display them.
*Current state:* - A small static reference client (~60 lines of JavaScript) - One example video published via IPFS/Pinata - Basic JSON metadata - Early schema drafts in the repo
*Repo:* https://github.com/baconpantsuppercut/arkA
*What I’m looking for:* Feedback on the protocol idea, criticism of the MVP architecture, suggestions for metadata/schema versioning, and perspectives from people familiar with distributed storage systems (IPFS/IPNS/IPLD, Arweave, S3-compatible systems, etc).
This is extremely early. There’s no platform, no company, and no plans for lock-in. Just a small protocol experiment that might be useful if it grows.
Happy to answer any questions.
I like what I see so far. I might suggest you use an Abstract Dynamic Structured Data system instead of mandating JSON. (check out https://www.ietf.org/archive/id/draft-hamrick-vwrap-type-sys... as an example.) Many (most?) of the SecondLife HTTP API endpoints could accept JSON, XML or our homebrew binary format and would automagically parse it based on the content-type of the blob that was posted. It was useful because we kept getting into arguments about whether we should use JSON or XML.
I think you may find communities out there who will insist on JSON, YAML or ProtoBufs, so specifying things in an abstract "super-class" might be able to get past the arguments of how data is represented on the wire and onto arguments about what the data represents.
I should probably go write some code to make it more obvious what I'm talking about.
With respect to schema versioning, Doug Kaye wrote a book called "Loosely Coupled" and even though it's from the 2000s when everyone thought everything was going to be Web Services everywhere, it still has a decent description of the problem. It's not so great a book as for me to recommend buying it, but it's definitely worth checking out from the library:
https://search.worldcat.org/title/53154427
It was nice to see IPFS being used but very difficult to see it applied to general usage and even with browsers like Brave giving support, it never really got adopted because it simply isn't usable. Anyone installing it on a server will understand why.
What I have been seeing as alternative is Blossom from the NOSTR platform. It became the defacto decentralized distribution protocol for media. Basically delivered what IPFS was promising with quite a dazzling simplicity.
When using it, you aren't tied to servers and your connections to other relays will do their best effort to retrieve the associated files. It works OK for media, just mentioning because in case you don't see much active development on IPFS is because the cool stuff has been something else since a while.