If the chunk already has a content and we try to upload it again, we
assume the previous content was correct and this one is the same
(chunks are immutable). We can't actually ensure they are the same due
to the encryption, though they should be.
If a chunk is being uploaded for the first time and doesn't have a
content, throw a validation error rather than throwing an ugly error.
Hard-coding the serialization encoding in the serializers is wrong.
This fix now enables us to change to easily change to msgpack as the
transport layer.
It's not actually used by clients but it's there and can be used. It
works for receiving msgpack messages, but doesn't yet work for sending
because some of the types will be converted to base64.
Collections still have a unique encryption key (their collection key), and items
just have a unique key per item in a collection that's derived from the main key
and if we ever want to share items across collections or do something fancy like
that we can just add an encrypted key in there.
The done implementation wasn't great because it would indicate we are
not done even when we are when the last chunk returned is exactly the
size of limit.
The done implementation wasn't great because it would indicate we are
not done even when we are when the last chunk returned is exactly the
size of limit.
This used to be the default, so it still is.
It only affects the list endpoint, the rest all support withCollection
anyway, because IDs are passed directly.
Each collection now has an item and the item's UID is the collections
UID. This lets us manipulate collections just like items, and as part of
transactions. This is significant because it lets us change them as part
of transactions!
Without this, it would be sufficient to steal an auth token to render the account
unusable because it would be possible to just reset the encrypted content
of the account. With this change we require the user to actually know
the account password in order to do it.
Tom Hacohen