song-search

The is a copious-transitions app that access as a sibling authorized service handling going sessions and providing pathways for WebSocket responses to sequential messages that include signed hashes of media chunks belonging to a keyed sessions.

Here is a breakdown:

• This is a server process that works along side an authorization app, taking sessions validation from their shared tables.

• This process helps a browser client establish WebSocket communication.

  During initialization, the public verification for signed data is sent to the server in order to make a session key and to save the key for later verification after the session completes.

• WebSocket messages are intended to include processed chunks of recorded streams.

• The client sends sequential messages during recording with chunks marking the progress of recording

• The messages include chained hashes of signed chunks from the stream

• Data hashes are signed by a session private key with the public provided to the server during session initialization.

• The revision updates of the media are offered up to blockchain consensus mechanisms.

Setting up WS Connection

The use of this module by a web client is intiated by a transition transaction that returns the WS URL and other parameters for operation.

The initialization transaction is an HTTPS exchange. Once the web client receives the WS URL, the client uses the WS URL to connect to the service. Once the connection is made, the client may then send WS messages.

The web client sends JSON messages away, and will not expect a response directly from the message in return. The web client may receive messages and provide a handler. If the web client requires a cause and effect relationship between sent and received message, it will provide its own implementation as far as this copious-transitions application is concerned.

There is a module for using WebSockets "message-relay-websockets" tha a web client may use if the server implements a copious-endpoint service. However, this particular application exists only to receives chunks of data along with their ownership information. This application provides oracular interface to certain blockchains where ownership will be established by concensus.

Client Side Operations

On the client side, HTML component and web workers have been made to capture recorded data and to send hashes on an ownership path and final data on a persistence path.

HTML Recording Component

Ownership Worker

Guest Presence Worker

The Guest Presence worker is a sub-worker of the Ownership worker. The Ownership worker calls up the Guest Presence workerw when a user decides to save his session. The effect of the save action is the sending of a presistence data structure to the WIP persistence path identified as "ownership".

THe Ownership worker performs very similar operations to those programmed into stream-manager dashboards, the likes of which may be found in the Svelte Blog interfaces. The Ownership worker assembles the persistence packet and then utilizes the session established by a special administrative user, a guest interactor.

Since the Ownership worker uses the existing session, it does not request it. Instead, server side operations provide session information to the Guest Presence worker. This allows the Guest Presence worker to publish persistence packets and to obtain upload tickets to the Ownership worker. The Ownership worker may then launch an uploader transition using services provided by the copious-transtions-app's mediu-up-igid service.