Jump to content

Dev Blog: The New DRM System


NQ-Naunet

Recommended Posts

image.png

 

Hello Noveans,

 

With release 0.23, we have introduced a long-due system to protect and manage the intellectual property rights of construct creators. This is not just a variant of the existing . Rights and Duties Management System (RDMS), which is mainly in the hands of the owner of a construct. Instead, the Digital Rights Management (DRM) system is in the hands of the creator of a construct, who might be another entity than the current owner. Let’s have a look at how it works.

 

Creators and DRM flags


When a construct is created from scratch, that is, when someone deploys a core unit, whoever deploys this core unit becomes the construct creator. This can be an organization, if the deployment is done in the name of the organization. This notion is crucial because when interacting with a construct being the creator will give you certain privileges. 

 

Note that if the creator is an organization, any legate of this organization will be considered as the creator. It’s a great way to share “creatorship” between several players and be more resilient about people not being in the game for whatever reason.

 

There are four things you might want to protect as a creator when somebody else is going to buy/use one of your constructs (with the caveat that we may add more things in the future if needed):

 

  • The creation of blueprints
  • The copying of voxel structures out of the construct
  • The edition of Lua code in Control Units
  • The edition of HTML content in Screen Units

 

However, we wanted the creator to be able to select which protection to activate or not, to give them more control, and also to allow to make a distinction between Control Units/Screen Units that might have been added after the purchase of the original construct (and which should, obviously, not be subject to any protection). So, we needed flags on elements to be able to say yes/no regarding each of the above protection abilities. That’s the purpose of  the DRM (which is a commonly used acronym for copyright protection of digital assets in the real world).

 

The DRM flag for blueprint and voxel copy protection is held by the Core Unit. Otherwise, each Control Unit and Screen Unit has its own flag.

From there, the rule for accessibility of any of the above four actions is defined by: 1. Is the player performing the action the creator? If yes, authorization is granted, if no: 2. Is the DRM flag of the corresponding element activated? If yes, authorization is NOT granted, otherwise it is.

 

Note: Historical constructs, created before the introduction of the notion of creator signature in construct (roughly around April 2020), do not have a creator. In this case, we chose to disable DRM entirely. Since there is no easy way to guess who was the creator (we can’t easily trace back the history of a construct, originating from several blueprints, etc.), we will leave it at that.


Blueprint creation and DRM management

 

How do you set the DRM flags? It is done automatically for you when you create a blueprint of the construct. By default, all DRM flags are set to “activated” on the Core Unit, all Screen Units, and all Control Units;  however, you have  a relatively hidden (because relatively dangerous) right-click menu option in “Construct/Advanced/Create Core Blueprint without right protection” that allows you to create a Core Blueprint that has no DRM flag activated, which means no protection at all. We will see below in the “use cases” section that this is not quite as useless as it sounds.

 

o8pEma6VGAgGqTooR527bFKPVBpWTuoswlyyoLIH

 

It is important to understand that the flag configuration is held by the Core Blueprint. Any construct that will be spawned from blueprints originating from the Core Blueprint will inherit the flag configuration: either all activated or all deactivated.

 

Once a construct has been created with such a blueprint (or even on the original construct if need be), the creator can still individually unflag any of the flagged elements (with the right-click menu “Advanced/Release DRM Protection”). Unflagging the Core Unit will release the DRM protection for blueprinting and voxel copying. It does not mean that anyone can now blueprint the construct, since now the owner (who is not necessarily the creator here) can use the usual RDMS restrictions on blueprint creation to define who can use this ability. In the same way, a DRM-free Control Unit is still subject to the RDMS as for who is allowed to edit the Lua inside it. But again, this is now a consideration for the owner, who is managing the RDMS, rather than the creator.

 

MX26264Q1CszVPSWywynS41OUDjU2l_bUjMI79TR

 

Once unflagged, a Core/Control/Screen Unit cannot be re-flagged by the creator. So, be careful when using this, it cannot be reversed.

 

Now, if the owner of a DRM protected construct decides to customize the construct and add some Control Units or Screen Units, these elements will be deployed without the DRM flag activated. In effect, it means that the owner will be free to edit them, as expected. There will be two types of Control/Screen Units in this construct then: those coming from the original DRM-protected blueprint, with their flag activated and therefore not editable, and those coming from the owner’s personal additions with no flag activated and full edition rights.


Use cases


Let’s be practical here and see some patterns of usage that we believe will be quite frequent.

 

1) The ship designer: This player/org typically intends for their constructs to be sold and fully protected. A Core Blueprint will be created with full DRM activation, and constructs made from the Blueprint originating from this Core Blueprint will be ready for sale and fully DRM-protected.

cFnsxpG67qKhvlPWzobE2ZUWKzA0OgTdPN4B3GGv

 

2) The org internal ships: Those ships are meant to be used by org members and should be created in the name of the org. A special blueprint without DRM would be issued to create ships for the org’s internal use. RDMS would play its role in managing internal org rights as usual.

pcygqcBGdp2AX-C9KvdTvF6SXIGUbrFsiEZsmYYh

 

3) Voxel library designer: By definition, selling or simply sharing a voxel library construct would imply the creation of a blueprint without DRM, otherwise the voxel copying will not be possible.


4) Special customer deal for a ship designer: It could be that the designer of a ship accepts to unlock some aspect of the DRM for a given customer. In this case, the creator will have to access the sold construct and operate on it to deactivate the flags wherever needed.


Still to Come

 

We are still missing some important features to fully cover the DRM mechanism. In particular:

 

  • We need to improve the way to find out who is the creator of a construct and provide an easy way to contact them. (You can currently find this info in the “Construct Information” tab of the Build Helper, but it should be easier to find.)
  • We need a way for a creator to be able to transfer their “creatorship” to another player/org.
  • We may need a way to separate DRM protection for blueprint and for voxel copy.
  • We may need a way to allow the creator to activate the DRM flag, not only to deactivate it. (This means the construct should remember what was an original Control/Screen Units in the list of elements of the construct.)

 

This will come in future updates. Until then, we hope you will enjoy this new addition to the game mechanics related to constructs and that, in particular, ship sellers will now be able to mass-produce and sell their creations without fear!

Want to discuss this? Visit the thread linked below! ?

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...