[HN Gopher] ArkA - A minimal open video protocol (first MVP demo)
       ___________________________________________________________________
        
       ArkA - A minimal open video protocol (first MVP demo)
        
       Author : moshebenpeshe
       Score  : 6 points
       Date   : 2025-11-20 21:30 UTC (1 hours ago)
        
 (HTM) web link (baconpantsuppercut.github.io)
 (TXT) w3m dump (baconpantsuppercut.github.io)
        
       | moshebenpeshe wrote:
       | 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.
        
         | OhMeadhbh wrote:
         | 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
        
         | nunobrito wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2025-11-20 23:00 UTC)