search

nspcc-dev / neofs-api

NeoFS API documentation and proto files declaration
Apache License 2.0
11 stars 15 forks source link

Account-based EACL targets #278

Closed roman-khimov closed 2 months ago

roman-khimov commented 10 months ago

Is your feature request related to a problem? Please describe.

I'm always frustrated when I see public keys in the protocol used instead of accounts. Account is a very powerful abstraction that is not limited to a single key. Current EACL target requirement to have public keys leads to problems in the service layer like nspcc-dev/neofs-s3-gw#861 and while workarounds are possible the root cause of the issue is the requirement to have public keys in targets, they should not be needed to process EACL.

Describe the solution you'd like

Extend target definition with a list of accounts. Deprecate key usage.

Describe alternatives you've considered

Reusing the same field is technically possible (it's just bytes). Not sure it's any better, but you can try convincing me.

cthulhu-rider commented 7 months ago

but you can try convincing me

how about: LEN=33 => key, otherwise account?

roman-khimov commented 7 months ago

Huh. That'd be similar to CheckWitness accepting keys or accounts. But it can be done.

cthulhu-rider commented 7 months ago

But it can be done

good. My main question is - can account be 33B in theory?

roman-khimov commented 7 months ago

To me they all 20 bytes (unfortunately, 25 in real life). If for whatever reason we need some new kind of account and it's 33 bytes originally, we can just add a prefix to distinguish it.

cthulhu-rider commented 7 months ago

then i think we can just shift existing field to accounts with the ability to use keys of length 33. Same message format, easier implementation