EPIC: Integrate the new sound protocol contracts

[TimDaub]

• Sound released a new protocol update: https://sound.mirror.xyz/t7GDH8RF6XbHLwbHb_R6QLnDTaln0KdGhExBgul6OXY
• roundpotatocat reported that hence artists that upgraded don't yet show up in music os: https://github.com/neume-network/data/issues/55
• e.g. here's a new song contract by latasha for "SHOWTIME" that isn't showing in the feed of music os for now:
  • https://etherscan.io/tx/0xa09cce4737eaab8b5724fb2c85439d4725cca51cdae994f675155a319889c4f4
  • https://www.sound.xyz/callmelatasha/joyride-ii-showtime
• Here's what we should do
  • for all new soundxyz music NFTs, parse their contracts in a strategy
  • integrate them into music-os accumulator
  • in the process, make sure that there is no name collision between the "old" sound strategy naming and the new "sound protocol" naming

[TimDaub]

An overview of the sound-protocol's new components:

• First of all: Here's the new sound-protocol's GitHub repository: https://github.com/soundxyz/sound-protocol
• Here's the old repository that's now a public archive: https://github.com/soundxyz/protocol
• Sound-protocol compatibility breaks the old sound contracts. We should not try to upgrade the existing sound strategies but rather create new ones that create compatibility with the new implementation

Description:

• sound-protocol implements a central contract for minting new songs. It deploys a new EIP-721 NFT collection called SoundEditionV1 per song: https://etherscan.io/address/0xaef3e8c8723d9c31863be8de54df2668ef7c4b89
• A SoundEditionCreation is emitted per NFT collection creation, topic1 is the NFT collection address, here's an example of a SoundEditionV1: https://etherscan.io/address/0x845b54af697604e43f8361762729112b58c6bfbf
• SoundEditionV1 implements a non-standardized but potentially useful interface for contract metadata: https://docs.opensea.io/docs/contract-level-metadata
• For a SoundEditionV1 NFT collection, when no NFTs/editions have been minted yet and function tokenURI is called with e.g. tokenId: 0, it throws an error
• All SoundEditionV1s use a so-called Metadata module that can generate a tokenURI: https://etherscan.io/address/0x3ca50e8da8c3d359fc934aea0161f5346ccb62a1#code
• For this SoundEditionV1 NFT collection: https://etherscan.io/address/0xf95f9728d730bac1d4dac32508b5a0db9d994a41#readContract tokenIds start at 1 (not zero)
• tokenURIs resolve to arweave, e.g. ar://zUTuV0VL7w1z5cuGkBs2b-O3DRY2O2qA_ifSQqjLnzA/1 where /1 is the tokenId

[TimDaub]

Re-assigned this to me as it's an EPIC and not a directly actionable issue. Here are the TODOs:

• https://github.com/neume-network/extraction-worker/issues/52
• https://github.com/neume-network/strategies/issues/295

[il3ven]

@TimDaub, @Kunkka0822 wanted to work more on this epic and has asked me to open new issues. What do you think about the following approach?

• Create a strategy to track Transfer events on all the sound edition contracts we found in #295. Instead of simply tracking Transfer event we should track Transfer events where tokenId is 1. Since all the other tokenIds will be editions.
• Have a sound-protocol-call-tokenuri like strategy to get the tokenUri for the tokenId retrieved in the previous step. We will get something like ar://zUTuV0VL7w1z5cuGkBs2b-O3DRY2O2qA_ifSQqjLnzA/1
• Have a sound-protocol-get-tokenuri like strategy to get the Arweave URI.

[TimDaub]

• Create a strategy to track Transfer events on all the sound edition contracts we found in #295. Instead of simply tracking Transfer event we should track Transfer events where tokenId is 1. Since all the other tokenIds will be editions.

In a Telegram channel and by reading @gigamesh, I've heard that a SoundEditionV1 contract can indeed have two or more different songs and so it may not be sufficient to just track tokenId=1.

Anyways, with the rest of the proposed tasks, I agree.

[gigamesh]

Hello! Cool to see yall building on our contracts. :D

To clarify, each instance of SoundEditionV1 only corresponds to a single edition (in most cases, a song).

We haven't announced our docs yet, but we have lots of info here: https://docs.sound.xyz/

[TimDaub]

To clarify, each instance of SoundEditionV1 only corresponds to a single edition (in most cases, a song).

@gigamesh: So say we do as @il3ven suggested and just call the first tokenId of each SoundEditionV1, will we eventually get the metadata of all songs published on the sound-protocol? Because e.g. in the "Editions Working Group Telegram Channel" @musnit pointed out that a SoundEditionV1 can have the metadata of more than one song.

[gigamesh]

Oh I see, I misunderstood the earlier discussion.

Normally you could just get it from the first token, but for Reo Cragun's Frameworks album we deployed it as an edition with all the songs represented via the metadata folder.

The easiest way to get the data would be our API, but if you don't want that dependency and make it future-proof, you'd need to scrape all the tokenIds. It's not likely we're going to do more releases like Reo's but its def not a guarantee.

Reo examples: https://7gznwfqpv3obvwsj53uehxiinvw7vu3qxnkcjjclqlujt4kr4voq.arweave.net/-bLbFg-u3BraSe7oQ90IbW3603C7VCSkS4LomfFR5V0/1 https://7gznwfqpv3obvwsj53uehxiinvw7vu3qxnkcjjclqlujt4kr4voq.arweave.net/-bLbFg-u3BraSe7oQ90IbW3603C7VCSkS4LomfFR5V0/333

[TimDaub]

OK, thanks for the prompt response.

• We're generally against using APIs and instead heavily prefer on-chain immutable data sources.
• We'd encourage you to enforce stricter rules that make it easier for others to integrate. E.g. one of exception for Reo may be user-friendly, but for us it creates considerably more work. Respectfully, but a "protocol" should prioritize consistency over user-friendliness as otherwise, re-implementation is ultra complex having to know all context (e.g. Reo special release).

There are now two possibilities with varying degrees of complexity:

(1) Ignore Reo release and just crawl all SoundEditionV1s with the first tokenId (2) Crawl all tokenURIs and then try to determine which editions equate to a new song

For (2), I'm still in the dark about how that'd work consistently. Is there any smart contract function @gigamesh that helps us understand if two editions are for a different song?

[gigamesh]

Good points! Unfortunately there is no function that publishes that info, but its definitely something we could consider adding for future editions. Let me talk to the rest of the team and circle back.

[TimDaub]

What if for each token's metadata we compared the losslessaudio file? Would that allow us to determine the number of unique songs?

[vigneshka]

@TimDaub , +1 on using onchain source of truth.

I would recommend option 2: Crawl all tokenURIs.

The metadata for each song has a unique title and track number within the contract. This is consistent across editions that are a single song and the album case.

e.g. for Reo Craguns's Frameworks project (album case): https://etherscan.io/token/0xf0701a661363f463c8de5bd6b009c0e9ceaba51a#readContract

https://7gznwfqpv3obvwsj53uehxiinvw7vu3qxnkcjjclqlujt4kr4voq.arweave.net/-bLbFg-u3BraSe7oQ90IbW3603C7VCSkS4LomfFR5V0/1

https://7gznwfqpv3obvwsj53uehxiinvw7vu3qxnkcjjclqlujt4kr4voq.arweave.net/-bLbFg-u3BraSe7oQ90IbW3603C7VCSkS4LomfFR5V0/2

[TimDaub]

Hey @vigneshka, thanks, that's helpful. So just to make sure I understood you correctly, this means that for an artist that uses 1 SoundEditionV1 contract for 1 song, for all tokenURIs e.g. ar://zUTuV0VL7w1z5cuGkBs2b-O3DRY2O2qA_ifSQqjLnzA/[1-N], we'd always find trackNumber===1, right?

And the only exception would for now be Reo where the trackNumber increases, but that allows us to understand unique songs contained in the SoundEditionv1. If so, I think that's a nice structure that we can implement, please let me know!

[vigneshka]

Yup, exactly!

[TimDaub]

@gigamesh and @vigneshka heads up this entire epic is now available as an outcome of the crawl strategy of neume, in this data set and soon probably also in music-os https://github.com/neume-network/data/blob/main/results/music-os-accumulator-extraction