Understanding Audius: An introduction and a few words about Content Nodes and AudSP.

As time progressed, Blockchains found more use over the years, ever since the original creation of Bitcoin. One of the most recent uses for it was the distribution of data, using IPFS (InterPlanetary File System). Audius is one of them, using it to create a competitor for both Soundcloud and Spotify. Welcome to Audius.

As Audius launched, I never quite understood originally how it works. But, recently I took it to myself to actually go out and learn about it. With the "Understanding Audius"series I intent to share the knowledge I learned to you, the reader, in a far more easily digestible form. But, as a start, let's summarize Audius.

Audius, both in web and app forms, is a front-end GUI for its decentralized system of Content Nodes and Discovery Nodes that work together to bring the content others uploaded to the user, using data streaming. With it, Audius has a custom framework that is based around IPFS, a decentralized protocol for data storage on a P2P basis, and AudSP, a custom extension created by the Audius team for IPFS.

Using a such decentralized system, Audius can provide a superior service that doesnt have a single weakpoint, and could possibly allow for custom Audius clients or plugins to existing music players (*wink wink Winamp*) in order to provide decentralized music streaming for the masses, available for everyone.

And that is Audius for the most part.

Now, let's talk about how it exactly works, deep down. Let's talk Content Distribution.

Using the above picture, taken straight from the Audius whitepaper, we can visualize exactly how it works, while getting deeper into it. The start of it is at the Artist Client, or rather just the musician. As they upload audio, 2 things happen. It gets uploaded onto the Content Node, and they also register the appearance of new audio files on the Content ledger. In turn, Content Nodes also communicate with AudSP at the same time to save metadata. But, let's talk about Content Ledgers first, as they're responsible for handling the token system.

Citing the Audius whitepaper directly, a Content ledger is "the amalgamation of smart contracts on Ethereum, POA network, and other future L1 or L2 blockchain networks that host pieces of the Audius ecosystem. Different parts of the Audius protocol will continue to run on different blockchain-based platforms, or utilize off-chain scalability solutions, where scalability trilemma tradeoffs can be made on a module and subprotocol-specific basis." What does this mean exactly? Well, it means that a Content ledger is a collection of metadata assigned to the track, that keeps track of things like track content, revenue splits and content ownership structure, a registry of all Audius reachable nodes. In short, a Content Node holds only the raw audio data, while the Content ledger holds information revelant to the token and blockchain system of Audius.

Now that Content ledgers have been explained, we can talk about Content Nodes. The key to understanding them lies within IPFS, the InterPlanetary File System. It's the backbone of the Content Nodes, as it provides a protocol to handle decentralized, P2P filesharing. The data itself is stored in 6 seconds chunks on the Content nodes, allowing for a much smoother experience while listening, meaning that the listening device has to only cache 6s chunks at a time and not, for example, a whole 1h podcast. Using IPFS communication, a listener can request a track to be streamed to him in said chunks, which then get "located" within the decentralized network using the AudSP protocol.

And this seems like an ideal time to explain what AudSP does.
AudSP by design is a metadata, location and fault detection protocol, that complements IPFS within the Audius ecosystem. When someone requests a track, IPFS first handles the request by locating the chunks on nodes, gets metadata for it and sends the said information to the listener and, at the same time, handles the data transmission. But, at the same time AudSP makes sure that the data is there, and in case of a possible fault, it makes sure that data can be quickly fetched from an another node to keep the listening experience smooth, without any bumps. AudSP metadata boils down to: listening patterns, genre, mood, etc. How the said metadata gets handled later down the line and how it gets processed will be for an another article.

And, that's all for now.
Thanks for reading, if you want to support my work feel free to tip me here or send me ETH (and tokens) over to this address: 0xe200fe1caa09ec38f5dc3c8b7b298a2e99e9268d

Sources:
Audius whitepaper
IPFS documents