muzikie / streamer-archived Goto Github PK

We need to add the following endpoints to retrieve collections stored.

• Collection
  • /:id - GET - Get a single collection.
  • /:id - DELETE - Remove/delete a single collection.
  • /:id - PATCH - Update a single collection.
  • / - GET - Get an all collections.
  • / - POST - Create a single collection.

Streamer should be able to check presence of the stream transactions corresponding to the stream event in progress.

We should be able to stream songs using their ID.
Before starting the stream, we should validate the user subscription as explained in #3 . We should also validate the API call as explained in #2 .
We won't implement the stream transaction validation as explained in #5 , this feature is postponed to v0.2.0.

Streamer should enable the player applications to access indexed data of the blockchain. Meaning, it should expose expose endpoints to store values and returned the list of entities. We'll replace this functionality with Lisk Service once it's stable enough.
Therefore the following endpoints are required:

• Collection
  • getAll
    • Method: GET
    • Params: limit, offset.
    • Description: List of all collections in the system including the details of their Audios.
  • getByAddress
    • Method: GET
    • Params: address, limit, offset.
    • Description: List of all collections of a given account including the details of their Audios.
• Subscription
  • getTypes
    • Method: GET
    • Params: none.
    • Description: List of all subscriptions types and 10 available IDs for each type

The event manager must be able to update the NFT values according to the new transactions in the blockchain. At the moment it fails when encountered with unsupported transactions.
Since we're going to adapt Lisk Service, this could be a temporary solution.

Each audio should include collection details to display in client. At the moment we only return collection ID. We should add an object that includes collection details.
The response of the audio endpoints should include the corresponding collection information. And the response of the collections endpoints, should include the list of audios as audio objects.

Here is a sample response of the audios endpoints:

{
  "status": "success",
  "data": [
    {
      "genre": [
        22
      ],
      "createdAt": "2023-01-24T00:11:31.796Z",
      "_id": "63cf23365a766d197410519c",
      "name": "La Bella",
      "releaseYear": 2023,
      "fit": [],
      "collectionID": "477569746172697374614d7220536d697468",
      "collection": {
        // "audios": [], // Remember, this should not be returned
        "createdAt": "2023-01-23T23:30:25.201Z",
        "_id": "63cf1bcb6b4ee3104c53b1c3",
        "name": "Guitarista",
        "releaseYear": 2022,
        "collectionType": 1,
        "coverSignature": "0775fac6aab1aa04047e48dda43953238dd8fb97ccd9cdda63517d0a145abfa6a5306bf22157d4e9189222d82162fbf5cbf72e06f615a276bf1ceee4efe44505",
        "coverHash": "9b93181a4ee02d618c1e1861fa2acfad",
        "creatorAddress": "lskhqy429nwm2tew3j5j29ef6pguyynf6jxcmgrh2",
        "collectionID": "477569746172697374614d7220536d697468",
        "__v": 0
      },
      "audioSignature": "84ad10615c485b4eeac51761e9040f2e867cd47be98758b121ec12cc3e70521c7060e3f83ad8e638935e8ff2fc67342f038872f1f37fa98473f6dd477b3c8604",
      "audioHash": "431d7f2536d7d3fa5cc6507227a444b5",
      "creatorAddress": "lskhqy429nwm2tew3j5j29ef6pguyynf6jxcmgrh2",
      "audioID": "4c612042656c6c614d7220536d697468",
      "__v": 0
    }
  ]
}

Sample response of the collections endpoint:

{
  "status": "success",
  "data": [
    {
      "audios": [{
        "genre": [
          22
        ],
        "createdAt": "2023-01-24T00:11:31.796Z",
        "_id": "63cf23365a766d197410519c",
        "name": "La Bella",
        "releaseYear": 2023,
        "fit": [],
        "audioSignature": "84ad10615c485b4eeac51761e9040f2e867cd47be98758b121ec12cc3e70521c7060e3f83ad8e638935e8ff2fc67342f038872f1f37fa98473f6dd477b3c8604",
        "audioHash": "431d7f2536d7d3fa5cc6507227a444b5",
        "creatorAddress": "lskhqy429nwm2tew3j5j29ef6pguyynf6jxcmgrh2",
        "audioID": "4c612042656c6c614d7220536d697468",
        "__v": 0
      }],
      "createdAt": "2023-01-23T23:30:25.201Z",
      "_id": "63cf1bcb6b4ee3104c53b1c3",
      "name": "Guitarista",
      "releaseYear": 2022,
      "collectionType": 1,
      "coverSignature": "0775fac6aab1aa04047e48dda43953238dd8fb97ccd9cdda63517d0a145abfa6a5306bf22157d4e9189222d82162fbf5cbf72e06f615a276bf1ceee4efe44505",
      "coverHash": "9b93181a4ee02d618c1e1861fa2acfad",
      "creatorAddress": "lskhqy429nwm2tew3j5j29ef6pguyynf6jxcmgrh2",
      "collectionID": "477569746172697374614d7220536d697468",
      "__v": 0
    }
  ]
}

Collections (or albums) are entities that store related audio files information and metadata.
This allows fast music discovery and search, statistics, etc.
Creating a schema for the collection here in streamer app allows us to quickly handle player app requests and then refer to blockchain app for transactions.
Collection schema is more likely to the collection type defined in blockchain project.
main fields are as below:
name
release Year
artist Name
co-artists
collection Type
audios
hash
meta
creator Address

Based on the discussion in the blockchain project, we should adapt the streamer to the new data schema.
This means, we should

• Remove the artist name from collection and audio
• Remove coArtist from colleciotn
• Add fit to audio
  Additionally we should incorporate reference data for ease of use in the client.

We should use a unique ID across projects and since blockchain should be the reference, we should use audioID and collectionID from blockchain to retrieve information of a single collection or audio via Streamer.

In order to achieve the following goals we need to index the successful transactions of the chain:

• #7
• #18

The goal is to subscribe to the relevant events from the chain, receive new transactions and determine their success / failure status.

For more context, we can subscribe to chain_newBlock event. And receive the transactions data using chain_getTransactionsByHeight endpoint. We'll also need to hit the chain_getEvents endpoint. We can use these vents to determine the status of each transaction.

This ticket doesn't aim to process the transactions. It only returns the list of successfully executed transactions.

Due to restrictions in the client app, we should change stream endpoint to read the address from cookies instead of headers.

Create api features for:
1.filter
2.sort
3. limit
4. pagination

When a collection is created, there's no audio assigned to it. Once new audios are created, we should fine their parent collection, and add their ID to them.

Users must have a valid subscription to stream a song. Any user with a valid subscription should be able to start streaming. They should be able to continue to stream content, and later submit the corresponding stream tx.

Handle unhandled routes in app

when a user start to listen to a song, streamer must send a transaction on blockchain within 40 seconds. otherwise it will stop stream to the user and show an appropriate message to inform user about the error.

At the moment we do not validate the stream request parameters. We should ensure

• The song exists
• The ID is valid
• The user public key is valid
• The user has a valid subscription

Tickets

• #6
• #7

Following #22 we should update the schema of Audio to match that of blockchain. Also we should add a Collection entity.

Streamer should expose an endpoint to return meta information including:/

• Storage path and extension of audio files
• Storage path and extension of collection covers

The appears that the repurposes of the stream endpoint is fragile and due to a miscommunication between Streamer and Web Player, the play buttons doesn't work from time to time./
We should review the stream endpoint and ensure that the Player is able to stream audios at all times.

Muzikie Blockchain endpoints return address in stringified buffer. Although we should use addresses in Lisk32 format in client. Since this is the recommended format.
Therefore we should store and retrieve account addresses in Lisk32 format in Streamer.
At the moment the blockchain endpoint convert buffer to string as

address.toString('hex')

The correct approach is

cryptography.address.getLisk32AddressFromAddress(Buffer.from(address, 'hex'))

As a schema check,

• audioID should be a hex string with length 64.
• User publicKey should be a hex string with length 64.

If these criteria are not met, the API should return the following errors:

• If the key is not one of the above:

{
  "error": true,
  "message": `Unknown input parameter(s): ${parameterName}`
}

• If the value doesn't match the above criteria:

{
  "error": true,
  "message": `Specified key `${value} does not exist`
}

We should store and return the duration of audio to be used by the client apps. The data should be returned as duration in seconds.

Only the following endpoints are used by the client as should refrain from exposing endpoints that not used:

• Audio
  • get
  • getAll
  • stream
• collection
  • get
  • getAll
• profile
  • get
  • getAll
• transaction
  • create

We want to store the entities created on the blockchain in a dedicated indexed DB so we can retrieve lists of Audios and Collections as per client request. Said endpoints serve the purpose of returning rich set of information to the client applications and play a role of middleman between our player apps and the blockchain.

To ensure our syntax conventions are followed, we should run eslsint using Github actions for each PR.

Streamer can easily be abused for pirating content, in particular copyrighted music.
a very basic, yet quite effective method is to encrypt the sensitive assets.
we can encrypt the mp3 contents server-side using some key, send it to the client, and let the client's js code decrypt and play it.
the client can still download the encrypted mp3 file, but without the proper decryption algorithm it's a useless file.

Rationale
We should rely on the blockchain for updating entities. This helps in many ways:

• The client should make less API calls, hence lower chance of failure.
• There is only one source of validation, which is the blockchain.
• The data is alway in sync with blockchain and there's less chance of failure and running out of sync.
• The client doesn't have to wait for the transaction to go through before the process is marked successful.

Entities
We need a new entity called Transaction. This entity holds:

• TransactionID
• Files
• module
• command

The transaction entity should be created before the actual transaction is broadcasted to blockchain. This way we can make sure the indexer receives it on time.

We have created a basic test suit.To ensure maximum productivity, we should extend to the test suit and create a test guideline.

Audio and Collection NFT tokens include audio and images files respectively. We should upload the files and store them to be served per request.
Before storing the files, we should validate the hashes to ensure the genuine file was uploaded. We should also make sure the NFT is unique.

We have implemented the Profile module and Streamer should

• Rename the User model to Profile
• Adapt the schema to that of Blockchain.

The README file must include

• Prerequisites
• Development scripts and their usages
• Production scripts and their usages
• Configurations files