search

Near-One / near-plugins

Implementation of common patterns used for NEAR smart contracts.
Creative Commons Zero v1.0 Universal
29 stars 12 forks source link

Project maintenance #135

Open mooori opened 5 months ago

mooori commented 5 months ago

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:

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 commented 5 months ago

Hey!

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

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:

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

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 commented 5 months ago

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 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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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.