Proof of Access

It's day 8 of blog everyday November, things have calmed down from moving and I'm back on my grind

The Hard Part

A little while ago we posted a video of a few of us talking shop and reviewing some code. I mentioned some of the "hard part" was around the resource credit nature of BROCA tokens, and the handshake necessary to put content into the network. So here we are a few months later and a whole lot of thought, research, and prototyping later. It's time to talk through "Content Insertion."

Mitigating Abuse

Our Solution to this problem has to mitigate several abuse vectors. Let's list and explain them.

• Placing illegal content into the network
• Attributing illegal content to somebody else on the network
• Attributing false meta data to content to draw more rewards
• Doublespend

Placing Illegal Content

People are not likely to want to run infrastructure that can directly get them into trouble. The TOR network has this issue with exit nodes, as it appears illegal communications are their responsibility. It's assumed that all TOR exit nodes are operated by state actors now, which lowers the overall security of the system. For this reason attributions about content must be transparent and accurate.

Attributing Illegal Content

Much like above, attack vectors exist where infrastructure operators could intercept uploads and replace those files with bad content. Wrecking trust in the network at every layer.

False Meta Data

Saying a 5MB file is 5GB to recieve a large payout.

Doublespend vectors

A multiparty transaction must be in a defined channel or be cleared at every step. Some solutions would require additional and unwanted user interaction... but this can't come at the expense of safety.

Solutions

We have a complicated multi-party transaction which means several parties have differing incentives. Front-Ends like 3speak will want to pay for content storage up front to enable their users to use their platform free of charge. Users will want to upload videos. Validators will want to verify videos to receive payment. Storage nodes will want to be verified to receive payment as well. Additionally encorders, indexers, and possibly other services like turn servers and p2p-coordination for chat features on live streams will need effective methods of trust.

To this effect I've been building state channels for these transactions. For ease of understanding, this is like buying a bearer bond, it can be transferred, with reciepts attached... and if nobody bears the bond at it's expiration... the sale is canceled and the funds return to your account.

Chain of Custody

It's important to note that contracts have obligations for each involved party. Payment obligations, storage obligations, content obligations, and so on.

Let's go through probably the most complicated type of transaction.

3speak.tv Content Upload

A user, Alice, logs into 3speak. When the user goes to upload a file they can trigger API that causes 3speak to promise a Broca amount for the storage of user generated content. 3speak has a vote bot and will be able to cover a certain amount of broca value even by voting on different content. To this effect a tally can be maintained and a true market condition might allow the average person to upload a 1GB file. So 3speak will initiate a state channel for Alice with a promise to pay for up to 1GB of content for Alice.

SPK network API can show the valid state of this channel with a certain expiration. The nodes in SPK network will debit the appropriate resources from their account and place them into this channel. This channel will include authorized upload nodes. They can also set a few expiration times for this. For example, if json_metadata in a hive post with rewards enabled and a benificary set to 3speak doesn't occur in 24 hours the remainder of the contract can be voided, and the resources returned to 3speak to aid another user to upload their content.

As Alice is uploading her files her computer will checksum the video, and sign the state channel contract with the additional checksum, and file byte size. This will prevent the upload node, Bob, from attributing other files to Alice's contract.

As Bob insert's Alice's video into IPFS, a hash is generated and Bob can sign the state channel contract that includes the IPFS locator hash and the checksum/size as verified. Bob can hold this contract to submit it to receive the 24 hour periods Broca to cover the cost of the file upload bandwidth/processor cycles. In the future, when Alice wants to upload a video the allocation might be a little smaller, or non-existent... as Bob might actually be Alice and trying to game rewards for non-content; Or the state channel may no longer list Bob as a upload provider.

This video may include some headers to have encoder nodes handle the video for online playback. When the file is ready to be distributed these contract and it's various signatures can be included as json_metadata and reconciled in the system. Building the contracts necessary to store files in the network and have them aperiodically checked via previously discussed psuedorandom algorithms.

Finalization

I believe this will cover most attack vectors but of course I welcome discussion about further vectors. How to improve this system or any additional conversations that spring from these topics.