Extend Access Permissions for Reusable Packages so that they can be adopted by marketplace applications as an alternative to MainModules

[ForeverHD (Ben)]

Reusable Packages have the potential to be incredibly useful for marketplace applications, including existing systems like HD/Nanoblox and Adonis.

They include powerful features like versioning (while retaining a toggle to AutoUpdate) which make them an ideal replacement for MainModules (which pose their own security risks and are likely to be removed entirely in the upcoming years).

1. Enhanced Permissions

There’s one key limitation preventing many from adopting them right now: a lack of access permissions that grant anyone the ability to view and use the package without being in a specific group:

Currently you (the package creator) have to grant manual access to others, or the user has to join your group (but even then there’s no view or use-only option). This is not scalable for marketplace applications which may receive thousands of downloads in a single day.

We’d quite like to take a hybrid approach with Nanoblox (to hopefully eventually replace HD Admin) where we use a plugin to install the application into the users place, then have the bulk of the application function under a package.

This would then allow the ‘Core’ of Nanoblox to be easily updated by our users (either via AutoUpdate or manual review) when we publish new changes. These changes include security patches, bug fixes and new features.

This is contrast to MainModules where you’re forced to either fork the MainModule (and lose your ability to receive new updates), or opt-into automatic updates which is not desirable for larger games where this behaviour introduces security vulnerabilities.

Enhanced access permissions will enable us to develop powerful marketplace applications while ensuring safety and security through features such as versioning.

---

2. Immutable Packages

When you modify a package that you don’t own but have read/use-access to, nothing happens initially. However, when you come to publish the game, it will produce the following warning:

Instead can the behaviour be changed so that as soon as you attempt to modify a script/module/model/etc under a package it prevents you from doing so and instead produces a warning informing you that the package can’t be modified.

Not only will this improve user experience (as there won’t be any unexpected warnings when you attempt to publish/close your game), but it will empower developers to create high-quality applications as users will be unable to modify specific parts of their application without losing automatic updates / versioning.

@Mr_Purrsalot This could then act as more effective alternative to private modules / obfuscated code which developers previously needed or relied upon.

[tnavarts]

There’s a fundamental conflict here between immutability and updates:

You’re supposing that someone is trying to modify the package… if they’re trying to modify the package they probably have a strong reason to be doing so: Especially with the more complex packages you’re presumably talking about here it takes a lot of effort to understand how they work and begin making modifications to them.

If they have a strong reason for modifying the package, immutability isn’t going to stop them. They’re going to fork the content instead and then they definitely won’t be able to get updates because their fork won’t have a reference back to the source.

Alternatively:

Suppose that there’s a future where having packages with modifications does not block publishing. This would mean that a user can modify the module you’re distributing, and publish the place with their modifications, but still have a link back to the source package.

This would mean that they would see a notification that there’s a new version available, and be able to choose between keeping their changes or taking the update (or potentially merging the two if such a workflow exists).

What do you think of that?

[ForeverHD (Ben)]

This need to modify the package can be almost entirely overcome by providing an extensions area outside of the Core package (as seen in the 2nd image above) and intuitive and well-documented APIs within our services/controllers. This way users can still benefit from security updates, bug fixes, etc from the Package Link while extending on their own configurations.

This scenario is also beneficial for the teams creating these applications. While users will be able to modify almost anything with Nanoblox, it would enable us to lock-away essential services such as those responsible for the commercial aspect of our application (represented by MonetisationService in the image above).

The significant majority of our top users with HD Admin forked from the MainModule for concerns over dynamically loaded code which they couldn’t review before updating. This is overcome entirely with Packages with the ability to toggle AutoUpdate off. A less common reason was to redirect our donation ID to their own gamepass. This is something we want to disincentive or restrict with Nanoblox as it firstly harms players who do not receive what they thought they were buying, and secondly prevents us reinvesting that lost income back into the application.

By immutability I’m not asking for the complete application to be locked away. Users can still destroy the Package Link for instance if they truly wish to play around with the internals. We want to make it difficult for users to make malicious modifications and to disincentivise them (through a loss of updates) from forking for the reasons above.

The marketplace has suffered for the last decade because there is no commercial incentive to develop and maintain high-quality resources. Many of us want to keep the majority of our codebase open-source however we need systems to help our commercial aspects from being modified maliciously. Changes like this would hopefully provide a step in that direction and for the marketplace to thrive just like games and avatar UGC.

[tnavarts]

@ForeverHD

We want to make it difficult for users to make malicious modifications and to disincentivise them (through a loss of updates) from forking for the reasons above.

I question whether allowing packages to be immutable would really do anything in this regard. Developers know that they can delete the package link and doing so is as simple as a single keypress or click, not a complicated action.

It might have a small amount of value, but only by virtue of confusing inexperienced users who don’t know how to unlink the package, and that does not make for a very good feature. I understand the monetization concern but I don’t think this is the right angle to solve it.

[ForeverHD (Ben)]

You make great points, I agree that this is a complex challenge and there certainly may be better solutions for this particular issue.

What are your thoughts on a setting (customisable by the package owner) to completely restrict the the ability to delete the Package Link? (i.e. you can’t modify the package in anyway except deleting it entirely, but you can still read its source code). This of course doesn’t make it impossible to re-create the package but would make modifying it not worthwhile for the majority of users.

[joritochip]

@ForeverHD

What are your thoughts on a setting (customisable by the package owner) to completely restrict the the ability to delete the Package Link? (i.e. you can’t modify the package in anyway except deleting it entirely, but you can still read its source code).

Unfortunately, preventing people from modifying the source of your package in this (or any similar) way would probably not be very effective. Users who want to change the source code of your application will figure out how to do so, as they have already shown with MainModules. And, it would probably even be easier to fork a package than it would be to fork a MainModule, even with this suggested restriction in place. (all you’d have to do is re-create the package root and then copy over the children)

There are definitely other approaches to take that could help solve the issue of people changing an application’s monetization code. For example, being able to customize the percentage that a developer receives if they sell your product in their game might make developers more inclined to keep your gamepass/product IDs the same. But, I don’t want to derail the thread too much, since the thread I linked goes into more depth and this thread is mainly about access permissions for packages.