What is Audius?

Audius claims to be a decentralized music-streaming platform that uses cryptocurrency to power its platform. While Audius is still in its creation and awaiting user adoption, it lacks FEATURES which may or may not be implemented into the base GUI. Audius proclaims itself as a competitor of SoundCloud and Spotify, so many users request features from each music platform.

The Goal of Audius Enhanced

Audius Enhanced is a set of tools for the Audius Platform with the goal of providing the tools you need to attain an edge as an artist or improve your listening experience as a fan. 

This involves the creation a website with 4 features:

1. Audius Algorithm Calculator for Trending
2. Audius Metrics
3. Audius Account OAUTH for Audius Enhanced Accounts
4. Audius UI Integration with Enhanced Tools

What is the Audius Enhanced Trending Calculator?

Audius uses an algorithm — which is simply a calculation — to rank tracks over weekly, monthly, and all-time periods. The Audius Enhanced Trending Calculator allows you to view your tracks' (karma) scores that influence their trending rank. You can read the following document for more information: The Audius Algorithm Explained.

What is Audius Enhanced Metrics?

The Audius Enhanced Metrics Platform allows you to view day-by-day statistics for users, tracks, and playlists with Audius Enhanced Metrics.

How is the Website Engineered?

The project uses a client-server architecture model to maintain a Frontend Javascript Client(s) that would interact with a PostgreSQL Database (server) via a NodeJS API (server). A personal server is also used to test changes before pushing to a Continuous Integration/Continuous Deployment Process(CI/CD) via Github Actions using Docker.

The backend is composed of four modules. The external module deals with external data calls, such as the Audius API, which a JavaScript wrapper was created for. The use of a blockchain (by Audius) makes their API somewhat awkward to use and more complicated to scale. However, we solved most of these issues using a proprietary HostManager, which allows us to handle more than 15M requests per month.

The core (calculator, metrics) and database modules were developed to handle the scale we needed to qualify for AUDIO Rewards. This was accomplished by using eventual consistency for aggregate data (total streams, total favorites, etc) to retrieve all necessary data required for the calculation and metrics of a user’s future requests over 5 minutes every 24 hours. SQL-batching optimizes this process, resulting in faster load times for user-requests within a 24-hour period, except for Karma, which requires real-time variables.

If this seems complicated, here is a simpler explanation:

1. At 0:00, all static data for a 24-hour period is logged (i.e metrics).
2. At 10:00 (or any other time), a user may request their metrics (composed of static data).
   • This request is cached on the frontend for a quicker load within the 24-hour period.
3. At 10:01 (or any other time), a user requests their karma score for a track.
   • This request combines uses the static data we already collected within the 24-hour period.
   • Unfortunately, real-time data must be fetched from (slow and unsupported) Audius API calls, along with intensive calculations.

The frontend client utilizes NextJS to provide server-side rendering using React. ChartJS is used to display graphs. Fastify bridges authorized frontend clients to backend services using a secure key. The server uses a custom cache for simplicity and to meet the previous funding deadline.

Project Timeline

The project initially began on March 25th, 2021 between 3 members (SwitchUpCB, Subrift, Tobro) with the goal of providing an Audius Messaging Platform. However, we realized that this would require heavy integration with the main Audius Team to be effective, along with its main functionality failing to qualify AUDIO REWARDS funding requirements (due to how a messaging system works). Instead of taking the gamble to monetize over the long term (a functionality Audius has yet to implement), we pursued Audius Enhanced.

Meetings were held bi-weekly until April. SwitchUpCB (backend) and Subrift (frontend) started work on the project until June 3rd. On June 9th, Tobro agreed to be removed due to a lack of time and contribution to the project. On June 17th, we added Daniel to the project. By this point, the backend technology stack was selected, with the external and core modules for the calculator being complete. However, the Frontend was developing slowly with only a wireframe completed. Daniel accelerated this process significantly, so on June 23rd, Subrift opted to step down from a compensatory role to learn more.

We continued to work until June 30th, when the Audius Trending Calculator was released to meet the Audius Grant Committee deadline. Luckily, this only required one rather stressful call involving a business argument over the UI, which was solved. The result was a website accessible by any Audius user. The project didn’t qualify for AUDIO Developer Rewards until a month later, and we had to hound an Audius co-founder for a month to receive it. As a result, we did not work on the project — which experienced no issues — until July 22nd.

On August 1st, we resumed work on the project to add the Audius Metrics that we promised in our Audius Grant Application (on the condition that it was accepted). Unfortunately, we ran into an issue with the current Audio Grant Committee, which was eventually solved after 44 days (on August 13th). As a result, the Audius Metrics Alpha was released on August 17th. I do not have images from this period because we planned to update the metrics platform over the following weeks (once Audius officially approved us).

On August 29th, we received a message from an Audius co-founder stating that we would no longer be eligible for the promised monthly AUDIO REWARDS because we used server-side rendering, and they wanted applications to use client-side rendering. There are many reasons not to use client-side rendering, especially for our application.

1. Client-side calls are run from the user which is less secure.
2. Client-side calls are run from the user which is less performant (more calls).
3. A metrics feature that uses client-side API requires the client to run them.
   • This means that a user has to login EVERY DAY to update their metrics. This is not user-friendly or efficient.
   • Using client-side calls relies on the user's resources which may be limited (i.e mobile data)… 
   • The way Audius manages hosts means users can reach hosts that are down or far away.
   • Using server-side calls allows us to manage these issues ourselves, which improves user experience.

Audius lacks metrics functionality compared to its competitors (Spotify, Soundcloud, Apple Music). A metrics feature equivalent to or better than Spotify for Artists benefits artists and establishes legitimacy for the platform. These features are necessary for long-term growth, and Audius saves resources by not requiring in-house development. Unfortunately, Audius does not care.

The Shutdown

Audius opts to use client-side calls because they collect IP data for each call. Having third-party applications run client-side allows them to juice up their monthly user statistics, which is why they “incentivize” applications with a high number of API calls per month. Not to mention the millions of dollars in venture capital that has been provided to Audius for these statistics. We did not approve of these decisions and decided to pause the project.

Outcome

Using $170 in expenses, provided product credits, and personal labor gained us $7,240 after fees (split among contributors). To put this in perspective, the Audius Team will vest 400M tokens over 3 years while failing to implement 6 of 6 promises in their whitepaper. In this context, we were underpaid for the labor that we did, in addition to the failure of the Audius Team to uphold their promise of monthly rewards.

We stopped maintaining Audius Enhanced because there is no longer an incentive to work on it. The Javascript Wrapper for Audius is a product of Audius Enhanced, which we've proposed to share with the world to give other developers an easier time developing scalable Audius Applications. However, that application wasn't accepted by the Audius Grant Committee because:

1. “The Wrapper is already completed.”
2. “Github is free.”
3. “We should work with Audius on it.”

The State of Audius

The most important takeaway from this project is the importance of marketing. Academic competitions require you to provide what you market. However, in the “real world”, people buy products based on promises. Unfortunately, Audius has failed to fulfill theirs. A number of documents have been created assessing the state of Audius over time: An Analysis on the Decentralized Blockchain Music Platform Audius aggregates these and showcases how Audius does not benefit its users, creators, or external developers.

My experience with Audius has been dishonest. Ironically, a platform focused on artist ownership provides no way for an artist to gain ownership beyond direct investment. So artists will never “own the platform” due to its Tokenomics. Unlike Audius’ competitors, artists are not paid. Copyright is not upheld. There is no incentive for an artist to use Audius, which ruins its user experience.

Audius is solely speculative — perhaps a scam — until monetization occurs. Even so, Audius has promised the feature for 2 years while rejecting requests for a roadmap. Their new TikTok “deal” has been a feature many distributors have had for a while: A decentralized distributor requires a solution to the Blockchain Oracle Problem that Audius has yet to solve. This opens the platform (or more so its operators) to legal liabilities since the platform operates under U.S law. So Audius provides no edge to listeners, artists, or miners who use the platform.

The Community

One other aspect of Audius' failure is how it handles its community. Channels are heavily moderated and any criticism is removed, contrary to a platform built on decentralization. Decisions are made based on the concerns of a few people. Audius doesn't embrace external applications, cemented by breaking their promises of rewards. This ruins the infrastructure Audius needs to grow as a platform.

Certain users may claim the Audius Grant Committee to be a valid method of earning ownership. However, Audius has claimed to be unaffiliated with its Grant Committee (despite its affiliation at creation). The grant system itself is a marketing effort focused on distribution to many people rather than direct value. As a result, the program incentivizes low effort events that will only impact Audius in the short term (if at all). Grants don't operate conditionally so there is no incentive to do more; if you even get accepted for work you've already done.

The Audius Grant Committee Exposed document explains many issues with the committee’s founding. While many of these issues have been fixed, the committee still remains under moderation by many of the existing members who fail to hit distribution targets (while being paid). When it's time for re-election, new rules are proposed to limit who can apply, and the amount of time — often a week — one has to apply. In addition, voters are only given a few days to vote for a 3-month appointment.

Audius needs people like us to support their platform because we are invested in what we do. Unfortunately, we've been driven to critique it to no end. So I can not put any more effort into the ecosystem until Audius fixes its issues.