This commit replaces Transform message with SplitHeader in oneof definition
of Value field of Header message. The latter, unlike the first, carries
complete information about the generation of the object by splitting the
payload. As a result, the message is deleted as no longer used.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
This commit defines SplitHeader message that encapsulates data about
spawning the object through a payload splitting. Message fields contain
information about the hierarchy in the split-chain as well as information
about the origin object.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
This commit makes ObjectID field of refs.Address message to use dedicated
message for object identifier ObjectID.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
This commit defines ObjectID message in refs package. In the future, this
structure can be ported into messages in place of the object identifier
field to maintain format uniformity. Also, storing the identifier in a
dedicated message will allow, if necessary, to expand it with additional
information without losing backward compatibility within one version of the
API.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
This commit merges object system header fields ID and CID into field Address
of type refs.Address. This will allow you to reuse an already existing type
of object reference without duplication and simplify taking the address
from the object body
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
In previous version of the format Object message included moment of creation
in two epoch times: NeoFS and Unix. Since unix is not processed in the
system, this commit narrows the time point of object creation to the system
epoch number. The object.CreationPoint message has therefore been deleted
as no longer used
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
In previous version of the format Object message included two header fields:
SystemHeader and list of ExtendedHeader. Due to the fact that all headers
were not encapsulated in a single message, some messages were forced to use
Object to convey the full header of the object (e.g. object.HeadResponse).
To resolve this semantic inconsistency, this commit defines a Header
message, consisting of a system and an extended portion. As a result, the
Object now consists of two fields - Header and Payload.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
The naming Header obscures its semantic meaning precisely as a subclass of
the general object header. To clarify the layers of typing object headers,
this commit renames the message to ExtendedHeader. As a result, the Headers
field in the Object has been renamed to ExtendedHeaders.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
The name of object.UserHeader message implies its use by the user. However,
the attributes of an object can also be set internally by the system. To
generalize the intended purpose of the message, this commit renames it to an
Attribute (like container.Attribute).
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
As mentioned in #32, there is a need to remove gogoproto usage from NeoFS API
since this plugin is not cross-language. This commit removes usage from
object.Object message and all related types.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
This commit replaces Range message definition closer to where it is used. In
the future, only the types associated with the structure of the object will
be defined in types.proto file.
Signed-off-by: Leonard Lyubich <leonard@nspcc.ru>
Capacity field is obsolete and removed. Salt field renamed to
Nonce so it shows better the purpose of the field.
Remaining fields are reorded to have fixed size fields on top.
It affects stable-marshaller implementation.
Signed-off-by: Alex Vanin <alexey@nspcc.ru>
Neofs-node doesn't use these headers in any way. They are
obsolete since container API provides proxy between client
and morph chain.
Signed-off-by: Alex Vanin <alexey@nspcc.ru>
With explicit signature field, that contains signature of
stable-marshalled container message, there is no need to have
separate fields of the container in request.
Public key will be stored in neofs.id smart-contract for later
signature verifications.
Signed-off-by: Alex Vanin <alexey@nspcc.ru>
With EACLTable in requests and container id in EACLTable there
is no need in extra messages such as ExtendedACLKey and
ExtendedACLValue.
Signed-off-by: Alex Vanin <alexey@nspcc.ru>
EACLTable message and signature stored in blockchain storage.
If owner has several containers, malicious node can return
correct EACLTable of the container other than client actually
requested. With container id field in the EACLTable, this
malicious behaviour can be detected.
ContainerID has id 1, so contract can easily cut container id
from byte sequence.
Signed-off-by: Alex Vanin <alexey@nspcc.ru>
