Could we create DRM replacing NFTs in HIVE ?

Watching the life hivefest stream yesterday, and catching up on the recordings from the first day today, I felt I needed to write a few blog posts.

• One regarding advertising. I'm not going to revive the old steemsense project, it died with the Tron takeover of STEEM, and it's staying dead, but I feel I need to re-share it's vision because I feel strongly there are discussions that the community should be having. I'll be writing a blog about that later.
• A second subject I might blog about soon is the subject of stable coin. One of the @spknetwork guys (think it was @theycallmedan, but I'm not sure about who is who) referred to the usd as the world's most stable asset, and really, it's not. It's a dangerous subject, because wars have been started for it, but stable coins pegged to fiat aren't really stable coins. More about this in a later blog.
• A thirs one, this one, about ownership vs holdership with NFT's, and the potential to create DRM replacing NFT technology that alligns closely with creative content creators.

The subject that I want to talk about in this blog is a subject that I hoped to address as one of the use cases for my slow moving coinZdense project, but as my project is moving extra slow because of my personal circumstances, and seeing what is happening with the @spknetwork network and the possible inclusion of of NFT into the layer one as presented by @trostparadox. It's a use case I've had in the back in my mind when designing the subkey management for my project. A use case that I have thought about a lot because of how I started out on the platform, writing fiction, and because of high interest in copyright and frustrations with today's DRM, especially in the ebook space.

What's wrong with (ebook) DRM?

When you buy a book, a physical one made from dead trees, you own your copy of the book. You aren't allowed to make a copy, and there are logistic issues keeping you from doing that anyway, but there is a lot of freedom with what you can do with it. You can sell it, transfer ownership, but you can also lend it to someone, keeping ownership but transferring holdership. When you've sold it, you can't access it and read it, and if you've lent it out to someone, you need to get it back from the person you've lent it out to before you can read it again.

If you buy a new book kabinet, or move to a different house, you don't need to buy a new copy of the books you already own. The very thought is just too ridiculous.

So in short, paper books make it logistically hard to create illegal copies, but make it easy to transfer either ownership or holdership, and make moving between kabinets or houses trivial.

DRM in its current form does the first. The other three features however are either not addressed or in a fairly poor way, with the sword of discontinionment always being there when it hasn't fallen yet. The companies running the DRM for books and other creative content are like the capricious gods from mythology.

Interoperable NFTs ?

Books have a globally unique id. The ISBN number. While the number is different between media (an ebook should have a different ISBN than the paper version),
an ebook on Kobo should normally have the same ISBN as that same ebook on Barnes & Noble, Google Play or Amazon. In NFT form, a copy ownership NFT for a book platform on Ether could use a similar (or potentially the same) globally unique id as a HIVE based book platform. It's not trivial, but using globally unique identifiers, that also work on storage providers like @spknetwork, NFTs could potentially be made platform agnostic.
Meaning in current platform terms that you could buy a book on Kobo, two years later buy a Kindle, cryptographically move your book ownership and holdership NFTs to your kindle, and gain access to your books on your Kindle while revoking access to your books on your old kobo reader, given that Amazon recognises Kobo as a legitimate issuer of NFTs. I'm not suggesting these big corporates would make our lives easy like that without any financial incentives, I'm suggesting that chains supporting NFTs could. Even if some of the fans want it to be that way, crypto projects tend to not lean towards making choices that try to create vendor lock in and actually tend to prefer interoperability. Interoperable NFTs are essential for moving NFTs into the creative content digit rights management space. NFTs could become a DRM killer, but interoperability will need to be part of its strength. Globally unique IDs on both the DRM and storage network level. Unique IDs like the ISBNs for books.

Holdership vs Ownership

While NFTs are perfect for transfer of ownership, in their common form they usually don't tend to distinguish between ownership and holdership. In my own project I aimed to provide facilities for this distinction using subkey management and encryption. I won't go into the details as they would only muddy the water right now. An alternative and possibly better way could be something along the lines of what @trostparadox described in his HiveFest presentation when he described an NFT being an account with a very limited on chain functionality.

I think if what @trostparadox presented is going to be implemented, the holdership vs ownership distinction should be something the implementation should strive for.

Lending! In an on-chain implementation lending could be similar to delegation as it exists on HIVE now. There is a little more to it as I'll demonstrate in the final section of this post, but lending should be considered an essential feature if NFTs are to truly make DRM in its current form obsolete, and are to create a copy ownership experience similar to that of paper books. Not quite delegation though. It should be like delegation in that the owner can revoke the delegation at any point in time. Yet it should also be like a regular NFT in that the holder can pass holdership back to the original owner, or pass it on to a third account.

Lending could be made more generic to accommodate libraries and such but also to make the NFT later more flexible. Consider the single holder NFT per owner NFT to be the default where N=1, but where the creator of the DRM NFTs might opt for a different value for N for their book (or other creative content).

Copy Logistics and transfer of ownership/holdership

Now we get to the hard part. The only real strength that today's DRM really has lies in protection from illegal copying of copyrighted material. This idea is almost the complete opposite of what Web 3.0 stands for. DRM is all about trusted software that opens up protected content and won't let it out of itself in any other way than through the device 's screen (books, artwork) or speakers (music) or both (videos).

Because open source is important, and making DRM truly secure requires techniques that many consider malicious, I'm not suggesting going full TP/rootkits on NFTs, but the idea that content shouldn't just be unencrypted in a public storage network seems a confession we should want to make to copyright holder's.

You want the content to be encrypted and the holder of the holder NFT to be able to decrypt it. Now we come to a tricky part. I've thought this out for the subkey solution I envisioned for coinZdense, but not for the NFT accounts idea or related solutions as proposed by @trostparadox, but I'll try to elaborate on it in an agnostic way. My project is all about hash based everything, so this is no different, but it tries to avoid public key encryption in an extreme way, because above all it's a quantum resistance project,so I'll try not to let that part shine through too much.

In CoinZdense, entropy is considered a resource, whenever anything is signed, an extra little piece of entropy is created as a free nonce to accommodate encrypting primitives like the one we are going to need now.

For now, think I terms of allocation. I as an author want put my book on @spknetwork, and I want to encrypt it in such away that holders of holder NFTs can decrypt it. As individual cryptographic revocation is relatively expensive,both in storage network operations and layer 1 operations.

The way the design works has some hooks to move part of the access control to the storage network using revocation lists, but let's not ahead of ourselves by being too ambitious.

A number of years ago I created an algorithm for sparse capability based authority tree decomposition, attenuation and encrypted storage with a reference implementation in python called pyrumpeltree.

This a high level post, so I won't go into the datails to deeply, but the basic design was to use the entropy seed from the involved coinZdense signing as seed for the rumpeltree, and then to create the entire tree as a large JSON file where leave nodes contain both the AES key for decrypting one of the copies of the book and

So let's say you think your book might sell up to 20,000 copies and you want to allow your copy holders to each lend out their one copy up to 64 times. You don't however want to store a million unique encrypted copies of your book.

What we do is that we create a Rumpeltree JSON file plus an encrypted copy of the book for the first 1024 owner NFTs.

The tree at level zero represents the ISBN of the book. At the next level of the rumpeltree structure we have NFT sequence numbers starting at zero.

While in the original rumpeltree protocol attenuation means read-only, in this case we define attenuation as hold only without ownership. We let the next level of the tree, the lead node level, represent an active holding NFT number. An unattenuated leaf node sparse-cap represents revocation rights for the designated holder NFT while the attenuated variant represents the holder rights themselves and through that, if it's the currently active holding cap, valid access to the encrypted data.

Accessing the leaf node itself should disclose both the URI of the encrypted book and the AES key needed to decrypt it.

It would be ideal if storage nodes could include rumpeltree functionality, but if it doesn't, a trusted ebook reader app can do the trick in a way that isn't really worse in terms of security than current DRM is.

Access to the two files will be useless without a sparse-cap pointing somewhere into the authority graph. This means that whenever an NFT is transferred between two accounts, the transaction must include a field, created by the previous holder (or owner), containing a memo-key-encrypted rumpeltree sparse-cap.

Closing

I hope this post holds some information that can be of use to both the NFT guys like @trostparadox , and to the storage network guys from @spknetwork.

I think the use case of DRM replacing NFTs is a good match for a platform that is big in creative content.

I'm sorry if this blog is still a bit tied to my post-quantum project, but I felt I needed to share it now because my project isn't going anywhere soon right now because of my private situation combined with a lack of funding. I've put a lot of thought into this use case, but my thoughts aren't yet a perfect fit for neither the current NFT efforts not the current storage network progress.

I hope my relatively high level discussion of rumpeltree is at least enough to get everybody's brain cells working and maybe start a discussion.

I'dd love to contribute more details if it's useful. I know my description of rumpeltree above is a bit limited. I can do a full blog post on the rumpeltree algorithm and how it could map for DRM NFT transfer if you guys think it can help in your projects.

Because of my private situation I don't have much space to donate my time to projects, so much so that my own projects hardly get any time, but I'm open to being contracted for shorter development and design tasks including ones that implement things discussed above at a discount if the code will be open sourced. Again, my private situation is messed up to a level where I don't dare to make commitments for more than a few weeks right now.

I think that if NFT based user centric DRM can be brought to HIVE it could become the foundation for democratised channels for creative content. HIVE could become the democratised version of KDP, and not just for books.