Project maintenance

[mooori]

Offline @akhi3030 and I discussed that near-plugins would ideally be maintained by those using it. They are in the best position to make decisions on the direction of the project. Additionally, following my transfer to the Contract Runtime team, maintaining near-plugins does not align very well with my other tasks anymore.

As far as we know, currently the main users of near-plugins are:

• Aurora cc @aleksuss @birchmd @vzctl
• The Bridge team cc @karim-en

This discussion is opened to explore how project maintenance can be transferred to and distributed among near-plugins users. You are welcome to share your thoughts and ideas.

It would be helpful if you could briefly describe how your team/organization is using near-plugins: Which projects depend on which of the plugins? Is functionality provided by near-plugins integral to the project or could it easily be replaced by custom code or another crate?

[vzctl]

Hey!

Currently Aurora is using near-plugins for the following projects:

• https://github.com/aurora-is-near/aurora-forwarder-contracts
• https://github.com/aurora-is-near/aurora-controller-factory

Going forward we will be utilizing a separate controller contract pattern for privileged operations (hence near-plugins) by default.

We depend heavily on AccessControllable and we are actively ingesting access lists into Backstage for introspection and alerting using this plugin:

• https://github.com/aurora-is-near/backstage-plugin-blockchainradar

We are also including near-plugins in the scope of the bug bounty on AuditOne:

• https://www.auditone.io/bug-bounty/aurora

Having a standard ABI + a reference implementation for RBAC on NEAR is very important for developer experience and safety. OpenZeppelin fills this gap on EVM chains but there is no alternative to near-plugins on NEAR.

[mooori]

Thank you for the feedback @vzctl, great to see that near-plugins is used by these projects.

We depend heavily on AccessControllable and we are actively ingesting access lists into Backstage for introspection and alerting

Introspection functionality of the ACL plugin is based on iterators. It looks like near-sdk-rs is on a path to remove(?) iterable collections other than Vec:

• The collections module has an iterable map, but the entire module is under the legacy feature flag.
• The iterable map and set from the store module have been deprecated.

The topic has also been discussed in this thread in near-plugins.

Not only for the ACL plugin, but also for smart contracts in general, iterating maps and sets seems like a common and important use case. Smart contracts can control for the cost of iterating NEAR storage, for example by pagination like we do in the ACL plugin. We might want to reach out to near-sdk-rs maintainers to find out more about the motivation of removing iterable maps/sets and to see if there is a way to keep them in the sdk.

[akhi3030]

We might want to reach out to near-sdk-rs maintainers to find out more about the motivation of removing iterable maps/sets and to see if there is a way to keep them in the sdk.

It might also be worth it to port the relevant data structures into near-plugins if the sdk is on the path of removal. That might just be the path of least resistance.

[akhi3030]

I had a chat with @karim-en about this issue and he is happy for the rainbow bridge to take ownership of this project. @karim-en: do you have thoughts on how to move forward with retaining the iterable data structures in near-plugins?

[mooori]

It might also be worth it to port the relevant data structures into near-plugins if the sdk is on the path of removal.

Overall maintaining some collections data structures in near-plugins and some in near-sdk-rs might be more workload compared to having all of them in a single repo. Overhead I can think of are maintaining duplicate testing infrastructure and docs for collections.

Also my gut feeling is that for the NEAR ecosystem as a whole, having a "complete" (including iteration) collections module in the sdk would be beneficial.