about summary refs log tree commit diff
path: root/tvix/castore/protos/rpc_blobstore.proto
blob: 93c02d397c44156a9e882db955b4e6945f4df712 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
// SPDX-License-Identifier: MIT
// Copyright © 2022 The Tvix Authors
syntax = "proto3";

package tvix.castore.v1;

option go_package = "code.tvl.fyi/tvix/castore-go;castorev1";

// BlobService allows reading (or uploading) content-addressed blobs of data.
// BLAKE3 is used as a hashing function for the data. Uploading a blob will
// return the BLAKE3 digest of it, and that's the identifier used to Read/Stat
// them too.
service BlobService {
    // Stat can be used to check for the existence of a blob, as well as
    // gathering more data about it, like more granular chunking information
    // or baos.
    // Server implementations are not required to provide more granular chunking
    // information, especially if the digest specified in [StatBlobRequest] is
    // already a chunk of a blob.
    rpc Stat(StatBlobRequest) returns (StatBlobResponse);

    // Read allows reading (all) data of a blob/chunk by the BLAKE3 digest of
    // its contents.
    // If the backend communicated more granular chunks in the `Stat` request,
    // this can also be used to read chunks.
    // This request returns a stream of BlobChunk, which is just a container for
    // a stream of bytes.
    // The server may decide on whatever chunking it may seem fit as a size for
    // the individual BlobChunk sent in the response stream, this is mostly to
    // keep individual messages at a manageable size.
    rpc Read(ReadBlobRequest) returns (stream BlobChunk);

    // Put uploads a Blob, by reading a stream of bytes.
    //
    // The way the data is chunked up in individual BlobChunk messages sent in
    // the stream has no effect on how the server ends up chunking blobs up, if
    // it does at all.
    rpc Put(stream BlobChunk) returns (PutBlobResponse);
}

message StatBlobRequest {
    // The blake3 digest of the blob requested
    bytes digest = 1;

    // Whether the server should reply with a list of more granular chunks.
    bool send_chunks = 2;

    // Whether the server should reply with a bao.
    bool send_bao = 3;
}

message StatBlobResponse {
    // If `send_chunks` was set to true, this MAY contain a list of more
    // granular chunks, which then may be read individually via the `Read`
    // method.
    repeated ChunkMeta chunks = 2;

    message ChunkMeta {
        // Digest of that specific chunk
        bytes digest = 1;

        // Length of that chunk, in bytes.
        uint64 size = 2;
    }

    // If `send_bao` was set to true, this MAY contain a outboard bao.
    // The exact format and message types here will still be fleshed out.
    bytes bao = 3;
}

message ReadBlobRequest {
    // The blake3 digest of the blob or chunk requested
    bytes digest = 1;
}

// This represents some bytes of a blob.
// Blobs are sent in smaller chunks to keep message sizes manageable.
message BlobChunk {
    bytes data = 1;
}

message PutBlobResponse {
    // The blake3 digest of the data that was sent.
    bytes digest = 1;
}