SPK Network File Storage

Reviews are starting to come in for the test SPK network. We are taking this time to respond to the feedback and put forth our proposal to include some quality of life changes. SPK Network is of course decentralized, and much like Hive with its various front ends, data can be displayed in a multitude of ways. So before we get the network in the wild, we thought we'd put fourth a proposed standard for meta data and inclusions.

Meta data is one string in a contract, this is transferred in the customJson and is limited to 8Kb currently by Hive.

Auto-Renew

First up is Auto-Renew. This will allow a user to set it and forget it. When a contract is up for expiration the smart contract will check if the Auto-Renew bit is set to true, then will use up to half of their available Broca to extend the contract for a month. Users will no longer have to babysit their files to make sure they are stored, only that they have enough SPK powered up to match their use.

The first character of the metadata string will contain contract level flags like AutoRenew. Currently there is only the 1; leaving 5 bit flags unused.

Psuedo-code:

if ( metadata[0] & 1 ) renew()

Encryption and Sharing

Following the first character of the metadata string is optional contract level encryption keys. This is one AES key encoded as following. 1#encrypted@toaccount;#encrypted@toaccount,... This will allow authorized accounts to see they can decrypt the file, decrypt the message to them, and use the key to decrypt the files with out making changes to the file. This does mean that once a key is shared it can only be psuedo revoked, as the customJson will live with its data on the blockchain, but changing these keys in the future will allow you to add accounts to the scheme fairly easily.

File Names

Following the contract level first string in the metadata, each file will have 4 slots on comma separated values. There is full unicode support here, and slot one in the file name. 1,name1,,,,name2,,,,name3,,, This will allow a user to find their files with relative ease.

File Types

Next is allowing front-ends to handle files based on file type. Image files, video files, audio files etc etc all require different handling. To accomplish this the 2nd of each files slows is reserved for an extension. 1,name1,mp3,,,name2,jpeg,,,name3,txt,,

Thumbnails

The next slot is reserved for a thumbnail, which can be in the form of a IPFS CID or a full resource link. At dlux we are piping the files extension into an SVG which allows us to render a preview for any file type if no thumbnail is provided. But if a thumbnail is here we will respect it and show it to the end user. Maybe...

Security and Visibility

The last slot in each file if for file level bit flags. All characters in this section are base64 numbers. These are:

• 1 Is the file encrypted
• 2 Is the file a thumbnail
• 4 Is the file NSFW
• 8 Is the file executable
• 16 Unused
• 32 Unused

1,cool,jpg,,6- Would flag this as a NSFW Thumbnail

The front ends can hide thumbnails from the file viewer by default, and use them to preview larger files, or obscure files if they are marked NSFW. Additional useful flag suggestions are welcome.

Licensing

Creative Commons has a few license types that we will support out of the box:

1. CC BY: Creative Commons Attribution License
2. CC BY-SA: Creative Commons Share Alike License
3. CC BY-ND: Creative Commons No Derivatives License
4. CC BY-NC-ND: Creative Commons Non-Commercial No Derivatives License
5. CC BY-NC: Creative Commons Non-Commercial License
6. CC BY-NC-SA: Creative Commons Non-Commercial Share Alike License
7. CC0: Grant to Public Domain

Due to the nature of the blockchain, you can prove fair use in the future even if the author changed it's license level after your fair use. There can be a near infinite number of licenses, to include Stock license, and Hive Beneficiary... They only need to be written and agreed upon.

1,cool,jpg,,A-7 Would CCO/Grant to Public Domain this JPEG.

Labels

After any license the user can select some label to better organize their files, as there are no folders in the SPK network. This is our list. For any additional uses the user may use a color which could have a personal significance.

• 0 - Miscellaneous
• 1 - Important
• 2 - Favorite
• 3 - Random
• 4 - Red
• 5 - Orange
• 6 - Yellow
• 7 - Green
• 8 - Blue
• 9 - Purple
• A - Grey
• B - Work
• C - Personal
• D - Family
• E - Friends
• F - Projects
• G - Finance
• H - Health
• I - Education
• J - Travel
• K - Events
• L - Photography
• M - Gaming
• N - Sports
• O - Blogging
• P - Meme
• Q - Music
• R - Video
• S - Audio
• T - News
• U - Development
• V - Fashion
• W - Food
• X - Cooking
• Y - DIY
• Z - Art
• a - Design
• b - Technology
• c - Religion
• d - Government
• e - Politics
• f - Science
• g - Research
• h - Receipts
• i - Correspondence
• j - Templates
• k - Resources
• l - Reference
• m - Backups
• n - Archive
• o - Drafts
• p - Finished
• q - Sent
• r - Pending
• s - Approved
• t - Rejected
• u - Ideas
• v - Goals
• w - Tasks
• x - Legal
• y - Networking
• z - Feedback
• + - Surveys
• = - Classified

1#encKey@username,obscured,xxx,,1--15u Would be an encrypted file, with an obscured name, a hidden extension, no thumbnail, with an encryption flag, no license, and labeled as an Important Orange Idea

Ease of Use

All this data, if agreed upon by the front ends supporting SPK, can make the user experience much more intuitive and friendly. Searching through files by name and filtering files by flag and labels is the ultimate goal. With an easy way to build upon the works of others, properly credit their origin, and potentially share rewards.

We are looking for all comments and feedback, there are unused flags at both the contract and file level, as well as more space behind the labels for any additional ideas.