1 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
2 // Use of this source code is governed by a BSD-style license that can be
3 // found in the LICENSE file.
5 // Sync protocol for communication between sync client and server.
7 // Update proto_value_conversions{.h,.cc,_unittest.cc} if you change
8 // any fields in this file.
12 option optimize_for = LITE_RUNTIME;
13 option retain_unknown_fields = true;
17 import "app_list_specifics.proto";
18 import "app_notification_specifics.proto";
19 import "app_setting_specifics.proto";
20 import "app_specifics.proto";
21 import "article_specifics.proto";
22 import "attachments.proto";
23 import "autofill_specifics.proto";
24 import "bookmark_specifics.proto";
25 import "client_commands.proto";
26 import "client_debug_info.proto";
27 import "device_info_specifics.proto";
28 import "dictionary_specifics.proto";
29 import "encryption.proto";
30 import "experiments_specifics.proto";
31 import "extension_setting_specifics.proto";
32 import "extension_specifics.proto";
33 import "favicon_image_specifics.proto";
34 import "favicon_tracking_specifics.proto";
35 import "get_updates_caller_info.proto";
36 import "history_delete_directive_specifics.proto";
37 import "nigori_specifics.proto";
38 import "managed_user_setting_specifics.proto";
39 import "managed_user_shared_setting_specifics.proto";
40 import "managed_user_specifics.proto";
41 import "managed_user_whitelist_specifics.proto";
42 import "password_specifics.proto";
43 import "preference_specifics.proto";
44 import "priority_preference_specifics.proto";
45 import "search_engine_specifics.proto";
46 import "session_specifics.proto";
47 import "sync_enums.proto";
48 import "synced_notification_app_info_specifics.proto";
49 import "synced_notification_specifics.proto";
50 import "theme_specifics.proto";
51 import "typed_url_specifics.proto";
52 import "unique_position.proto";
53 import "wifi_credential_specifics.proto";
55 // Used for inspecting how long we spent performing operations in different
56 // backends. All times must be in millis.
57 message ProfilingData {
58 optional int64 meta_data_write_time = 1;
59 optional int64 file_data_write_time = 2;
60 optional int64 user_lookup_time = 3;
61 optional int64 meta_data_read_time = 4;
62 optional int64 file_data_read_time = 5;
63 optional int64 total_request_time = 6;
66 message EntitySpecifics {
67 // If a datatype is encrypted, this field will contain the encrypted
68 // original EntitySpecifics. The extension for the datatype will continue
69 // to exist, but contain only the default values.
70 // Note that currently passwords employ their own legacy encryption scheme and
71 // do not use this field.
72 optional EncryptedData encrypted = 1;
74 // To add new datatype-specific fields to the protocol, extend
75 // EntitySpecifics. First, pick a non-colliding tag number by
76 // picking a revision number of one of your past commits
77 // to src.chromium.org. Then, in a different protocol buffer
78 // definition, define your message type, and add an optional field
79 // to the list below using the unique tag value you selected.
81 // optional MyDatatypeSpecifics my_datatype = 32222;
84 // - 32222 is the non-colliding tag number you picked earlier.
85 // - MyDatatypeSpecifics is the type (probably a message type defined
86 // in your new .proto file) that you want to associate with each
87 // object of the new datatype.
88 // - my_datatype is the field identifier you'll use to access the
89 // datatype specifics from the code.
91 // Server implementations are obligated to preserve the contents of
92 // EntitySpecifics when it contains unrecognized fields. In this
93 // way, it is possible to add new datatype fields without having
94 // to update the server.
96 // Note: The tag selection process is based on legacy versions of the
97 // protocol which used protobuf extensions. We have kept the process
98 // consistent as the old values cannot change. The 5+ digit nature of the
99 // tags also makes them recognizable (individually and collectively) from
100 // noise in logs and debugging contexts, and creating a divergent subset of
101 // tags would only make things a bit more confusing.
103 optional AutofillSpecifics autofill = 31729;
104 optional BookmarkSpecifics bookmark = 32904;
105 optional PreferenceSpecifics preference = 37702;
106 optional TypedUrlSpecifics typed_url = 40781;
107 optional ThemeSpecifics theme = 41210;
108 optional AppNotification app_notification = 45184;
109 optional PasswordSpecifics password = 45873;
110 optional NigoriSpecifics nigori = 47745;
111 optional ExtensionSpecifics extension = 48119;
112 optional AppSpecifics app = 48364;
113 optional SessionSpecifics session = 50119;
114 optional AutofillProfileSpecifics autofill_profile = 63951;
115 optional SearchEngineSpecifics search_engine = 88610;
116 optional ExtensionSettingSpecifics extension_setting = 96159;
117 optional AppSettingSpecifics app_setting = 103656;
118 optional HistoryDeleteDirectiveSpecifics history_delete_directive = 150251;
119 optional SyncedNotificationSpecifics synced_notification = 153108;
120 optional SyncedNotificationAppInfoSpecifics synced_notification_app_info = 235816;
121 optional DeviceInfoSpecifics device_info = 154522;
122 optional ExperimentsSpecifics experiments = 161496;
123 optional PriorityPreferenceSpecifics priority_preference = 163425;
124 optional DictionarySpecifics dictionary = 170540;
125 optional FaviconTrackingSpecifics favicon_tracking = 181534;
126 optional FaviconImageSpecifics favicon_image = 182019;
127 optional ManagedUserSettingSpecifics managed_user_setting = 186662;
128 optional ManagedUserSpecifics managed_user = 194582;
129 optional ManagedUserSharedSettingSpecifics managed_user_shared_setting =
131 optional ManagedUserWhitelistSpecifics managed_user_whitelist = 306060;
132 optional ArticleSpecifics article = 223759;
133 optional AppListSpecifics app_list = 229170;
134 optional WifiCredentialSpecifics wifi_credential = 218175;
135 optional AutofillWalletSpecifics autofill_wallet = 306270;
139 // This item's identifier. In a commit of a new item, this will be a
140 // client-generated ID. If the commit succeeds, the server will generate
141 // a globally unique ID and return it to the committing client in the
142 // CommitResponse.EntryResponse. In the context of a GetUpdatesResponse,
143 // |id_string| is always the server generated ID. The original
144 // client-generated ID is preserved in the |originator_client_id| field.
145 // Present in both GetUpdatesResponse and CommitMessage.
146 optional string id_string = 1;
148 // An id referencing this item's parent in the hierarchy. In a
149 // CommitMessage, it is accepted for this to be a client-generated temporary
150 // ID if there was a new created item with that ID appearing earlier
151 // in the message. In all other situations, it is a server ID.
152 // Present in both GetUpdatesResponse and CommitMessage.
153 optional string parent_id_string = 2;
155 // old_parent_id is only set in commits and indicates the old server
156 // parent(s) to remove. When omitted, the old parent is the same as
158 // Present only in CommitMessage.
159 optional string old_parent_id = 3;
161 // The version of this item -- a monotonically increasing value that is
162 // maintained by for each item. If zero in a CommitMessage, the server
163 // will interpret this entity as a newly-created item and generate a
164 // new server ID and an initial version number. If nonzero in a
165 // CommitMessage, this item is treated as an update to an existing item, and
166 // the server will use |id_string| to locate the item. Then, if the item's
167 // current version on the server does not match |version|, the commit will
168 // fail for that item. The server will not update it, and will return
169 // a result code of CONFLICT. In a GetUpdatesResponse, |version| is
170 // always positive and indentifies the revision of the item data being sent
172 // Present in both GetUpdatesResponse and CommitMessage.
173 required int64 version = 4;
175 // Last modification time (in java time milliseconds)
176 // Present in both GetUpdatesResponse and CommitMessage.
177 optional int64 mtime = 5;
180 // Present in both GetUpdatesResponse and CommitMessage.
181 optional int64 ctime = 6;
183 // The name of this item.
185 // Since November 2010, this value is no different from non_unique_name.
186 // Before then, server implementations would maintain a unique-within-parent
187 // value separate from its base, "non-unique" value. Clients had not
188 // depended on the uniqueness of the property since November 2009; it was
189 // removed from Chromium by http://codereview.chromium.org/371029 .
190 // Present in both GetUpdatesResponse and CommitMessage.
191 required string name = 7;
193 // The name of this item. Same as |name|.
194 // |non_unique_name| should take precedence over the |name| value if both
195 // are supplied. For efficiency, clients and servers should avoid setting
196 // this redundant value.
197 // Present in both GetUpdatesResponse and CommitMessage.
198 optional string non_unique_name = 8;
200 // A value from a monotonically increasing sequence that indicates when
201 // this item was last updated on the server. This is now equivalent
202 // to version. This is now deprecated in favor of version.
203 // Present only in GetUpdatesResponse.
204 optional int64 sync_timestamp = 9;
206 // If present, this tag identifies this item as being a uniquely
207 // instanced item. The server ensures that there is never more
208 // than one entity in a user's store with the same tag value.
209 // This value is used to identify and find e.g. the "Google Chrome" settings
210 // folder without relying on it existing at a particular path, or having
211 // a particular name, in the data store.
213 // This variant of the tag is created by the server, so clients can't create
214 // an item with a tag using this field.
216 // Use client_defined_unique_tag if you want to create one from the client.
218 // An item can't have both a client_defined_unique_tag and
219 // a server_defined_unique_tag.
221 // Present only in GetUpdatesResponse.
222 optional string server_defined_unique_tag = 10;
224 // If this group is present, it implies that this SyncEntity corresponds to
225 // a bookmark or a bookmark folder.
227 // This group is deprecated; clients should use the bookmark EntitySpecifics
228 // protocol buffer extension instead.
229 optional group BookmarkData = 11 {
230 // We use a required field to differentiate between a bookmark and a
232 // Present in both GetUpdatesMessage and CommitMessage.
233 required bool bookmark_folder = 12;
235 // For bookmark objects, contains the bookmark's URL.
236 // Present in both GetUpdatesResponse and CommitMessage.
237 optional string bookmark_url = 13;
239 // For bookmark objects, contains the bookmark's favicon. The favicon is
240 // represented as a 16X16 PNG image.
241 // Present in both GetUpdatesResponse and CommitMessage.
242 optional bytes bookmark_favicon = 14;
245 // Supplies a numeric position for this item, relative to other items with the
246 // same parent. Deprecated in M26, though clients are still required to set
249 // Present in both GetUpdatesResponse and CommitMessage.
251 // At one point this was used as an alternative / supplement to
252 // the deprecated |insert_after_item_id|, but now it, too, has been
255 // In order to maintain compatibility with older clients, newer clients should
256 // still set this field. Its value should be based on the first 8 bytes of
257 // this item's |unique_position|.
259 // Nerwer clients must also support the receipt of items that contain
260 // |position_in_parent| but no |unique_position|. They should locally convert
261 // the given int64 position to a UniquePosition.
263 // The conversion from int64 to UniquePosition is as follows:
264 // The int64 value will have its sign bit flipped then placed in big endian
265 // order as the first 8 bytes of the UniquePosition. The subsequent bytes of
266 // the UniquePosition will consist of the item's unique suffix.
268 // Conversion from UniquePosition to int64 reverses this process: the first 8
269 // bytes of the position are to be interpreted as a big endian int64 value
270 // with its sign bit flipped.
271 optional int64 position_in_parent = 15;
273 // Contains the ID of the element (under the same parent) after which this
274 // element resides. An empty string indicates that the element is the first
275 // element in the parent. This value is used during commits to specify
276 // a relative position for a position change. In the context of
277 // a GetUpdatesMessage, |position_in_parent| is used instead to
278 // communicate position.
280 // Present only in CommitMessage.
282 // This is deprecated. Clients are allowed to omit this as long as they
283 // include |position_in_parent| instead.
284 optional string insert_after_item_id = 16;
286 // Arbitrary key/value pairs associated with this item.
287 // Present in both GetUpdatesResponse and CommitMessage.
289 // optional ExtendedAttributes extended_attributes = 17;
291 // If true, indicates that this item has been (or should be) deleted.
292 // Present in both GetUpdatesResponse and CommitMessage.
293 optional bool deleted = 18 [default = false];
295 // A GUID that identifies the the sync client who initially committed
296 // this entity. This value corresponds to |cache_guid| in CommitMessage.
297 // This field, along with |originator_client_item_id|, can be used to
298 // reunite the original with its official committed version in the case
299 // where a client does not receive or process the commit response for
302 // Present only in GetUpdatesResponse.
304 // This field is also used in determining the unique identifier used in
305 // bookmarks' unique_position field.
306 optional string originator_cache_guid = 19;
308 // The local item id of this entry from the client that initially
309 // committed this entity. Typically a negative integer.
310 // Present only in GetUpdatesResponse.
312 // This field is also used in determinging the unique identifier used in
313 // bookmarks' unique_position field.
314 optional string originator_client_item_id = 20;
316 // Extensible container for datatype-specific data.
317 // This became available in version 23 of the protocol.
318 optional EntitySpecifics specifics = 21;
320 // Indicate whether this is a folder or not. Available in version 23+.
321 optional bool folder = 22 [default = false];
323 // A client defined unique hash for this entity.
324 // Similar to server_defined_unique_tag.
326 // When initially committing an entity, a client can request that the entity
327 // is unique per that account. To do so, the client should specify a
328 // client_defined_unique_tag. At most one entity per tag value may exist.
329 // per account. The server will enforce uniqueness on this tag
330 // and fail attempts to create duplicates of this tag.
331 // Will be returned in any updates for this entity.
333 // The difference between server_defined_unique_tag and
334 // client_defined_unique_tag is the creator of the entity. Server defined
335 // tags are entities created by the server at account creation,
336 // while client defined tags are entities created by the client at any time.
338 // During GetUpdates, a sync entity update will come back with ONE of:
339 // a) Originator and cache id - If client committed the item as non "unique"
340 // b) Server tag - If server committed the item as unique
341 // c) Client tag - If client committed the item as unique
343 // May be present in CommitMessages for the initial creation of an entity.
344 // If present in Commit updates for the entity, it will be ignored.
346 // Available in version 24+.
348 // May be returned in GetUpdatesMessage and sent up in CommitMessage.
350 optional string client_defined_unique_tag = 23;
352 // This positioning system had a relatively short life. It was made obsolete
353 // by |unique_position| before either the client or server made much of an
354 // attempt to support it. In fact, no client ever read or set this field.
356 // Deprecated in M26.
357 optional bytes ordinal_in_parent = 24;
359 // This is the fourth attempt at positioning.
361 // This field is present in both GetUpdatesResponse and CommitMessage, if the
362 // item's type requires it and the client that wrote the item supports it (M26
363 // or higher). Clients must also be prepared to handle updates from clients
364 // that do not set this field. See the comments on
365 // |server_position_in_parent| for more information on how this is handled.
367 // This field will not be set for items whose type ignores positioning.
368 // Clients should not attempt to read this field on the receipt of an item of
369 // a type that ignores positioning.
371 // Refer to its definition in unique_position.proto for more information about
372 // its internal representation.
373 optional UniquePosition unique_position = 25;
375 // Attachment ids of attachments associated with this SyncEntity.
376 repeated AttachmentIdProto attachment_id = 26;
379 // This message contains diagnostic information used to correlate
380 // commit-related traffic with extensions-related mutations to the
381 // data models in chromium. It plays no functional role in
382 // processing this CommitMessage.
383 message ChromiumExtensionsActivity {
384 // The human-readable ID identifying the extension responsible
385 // for the traffic reported in this ChromiumExtensionsActivity.
386 optional string extension_id = 1;
388 // How many times the extension successfully invoked a write
389 // operation through the bookmarks API since the last CommitMessage.
390 optional uint32 bookmark_writes_since_last_commit = 2;
393 // Client specific configuration information.
394 message ClientConfigParams {
395 // The set of data types this client has enabled. Note that this does not
396 // include proxy types, as they do not have protocol field numbers and are
397 // placeholder types that implicitly enable protocol types.
398 repeated int32 enabled_type_ids = 1;
400 // Whether the PROXY_TABS proxy datatype is enabled on this client.
401 optional bool tabs_datatype_enabled = 2;
404 message CommitMessage {
405 repeated SyncEntity entries = 1;
407 // A GUID that identifies the committing sync client. This value will be
408 // returned as originator_cache_guid for any new items.
409 optional string cache_guid = 2;
411 repeated ChromiumExtensionsActivity extensions_activity = 3;
413 // The configuration of this client at commit time. Used by the server to
414 // make commit-time decisions about how to process datatypes that might
415 // involve server-side interaction, and e.g require explicit user intent for
416 // syncing a particular data type regardless of whether a commit for that
417 // datatype is currently being sent up.
418 optional ClientConfigParams config_params = 4;
420 // Set of optional per-client datatype contexts.
421 repeated DataTypeContext client_contexts = 5;
424 // This message communicates additional per-type information related to
425 // requests with origin GU_TRIGGER. This message is not relevant when any
426 // other origin value is used.
427 // Introduced in M29.
428 message GetUpdateTriggers {
429 // An opaque-to-the-client string of bytes, received through a notification,
430 // that the server may interpret as a hint about the location of the latest
431 // version of the data for this type.
433 // Note that this will eventually replace the 'optional' field of the same
434 // name defined in the progress marker, but the client and server should
435 // support both until it's safe to deprecate the old one.
437 // This field was introduced in M29.
438 repeated string notification_hint = 1;
440 // This flag is set if the client was forced to drop hints because the number
441 // of queued hints exceeded its limit. The oldest hints will be discarded
442 // first. Introduced in M29.
443 optional bool client_dropped_hints = 2;
445 // This flag is set when the client suspects that its list of invalidation
446 // hints may be incomplete. This may be the case if:
447 // - The client is syncing for the first time.
448 // - The client has just restarted and it was unable to keep track of
449 // invalidations that were received prior to the restart.
450 // - The client's connection to the invalidation server is currently or
451 // was recently broken.
453 // It's difficult to provide more details here. This is implemented by
454 // setting the flag to false whenever anything that might adversely affect
455 // notifications happens (eg. a crash, restart on a platform that doesn't
456 // support invalidation ack-tracking, transient invalidation error) and is
457 // unset only after we've experienced one successful sync cycle while
458 // notifications were enabled.
460 // This flag was introduced in M29.
461 optional bool invalidations_out_of_sync = 3;
463 // This counts the number of times the syncer has been asked to commit
464 // changes for this type since the last successful sync cycle. The number of
465 // nudges may not be related to the actual number of items modified. It
466 // often correlates with the number of user actions, but that's not always
468 // Introduced in M29.
469 optional int64 local_modification_nudges = 4;
471 // This counts the number of times the syncer has been explicitly asked to
472 // fetch updates for this type since the last successful sync cycle. These
473 // explicit refresh requests should be relatively rare on most platforms, and
474 // associated with user actions. For example, at the time of this writing
475 // the most common (only?) source of refresh requests is when a user opens
476 // the new tab page on a platform that does not support sessions
478 // Introduced in M29.
479 optional int64 datatype_refresh_nudges = 5;
481 // This flag is set if the invalidation server reports that it may have
482 // dropped some invalidations at some point. Introduced in M33.
483 optional bool server_dropped_hints = 6;
485 // This flag is set if this GetUpdate request is due at least in part due
486 // to the fact that this type has not finished initial sync yet, and the
487 // client would like to initialize itself with the server data.
489 // Only some types support performing an initial sync as part of a normal
490 // GetUpdate request. Many types must be in configure mode when fetching
491 // initial sync data.
493 // Introduced in M38.
494 optional bool initial_sync_in_progress = 7;
497 message GarbageCollectionDirective {
500 VERSION_WATERMARK = 1;
505 optional Type type = 1 [default = UNKNOWN];
507 // This field specifies the watermark for the versions which should get
508 // garbage collected. The client should purge all sync entities with a
509 // version smaller than version_watermark locally.
510 optional int64 version_watermark = 2;
512 // This field specifies the watermark in terms of age in days. The client
513 // should purge all sync entities which are older than this specific value
514 // based on last modified time.
515 optional int32 age_watermark_in_days = 3;
517 // This field specifies the max number of items that the client should keep
518 // for a specific datatype. If the number of items exceeds this limit, the
519 // client should purge the extra sync entities based on the LRU rule.
520 optional int32 max_number_of_items = 4;
523 message DataTypeProgressMarker {
524 // An integer identifying the data type whose progress is tracked by this
525 // marker. The legitimate values of this field correspond to the protobuf
526 // field numbers of all EntitySpecifics fields supported by the server.
527 // These values are externally declared in per-datatype .proto files.
528 optional int32 data_type_id = 1;
530 // An opaque-to-the-client sequence of bytes that the server may interpret
531 // as an indicator of the client's knowledge state. If this is empty or
532 // omitted by the client, it indicates that the client is initiating a
533 // a first-time sync of this datatype. Otherwise, clients must supply a
534 // value previously returned by the server in an earlier GetUpdatesResponse.
535 // These values are not comparable or generable on the client.
537 // The opaque semantics of this field are to afford server implementations
538 // some flexibility in implementing progress tracking. For instance,
539 // a server implementation built on top of a distributed storage service --
540 // or multiple heterogenous such services -- might need to supply a vector
541 // of totally ordered monotonic update timestamps, rather than a single
542 // monotonically increasing value. Other optimizations may also be
543 // possible if the server is allowed to embed arbitrary information in
544 // the progress token.
546 // Server implementations should keep the size of these tokens relatively
547 // small, on the order of tens of bytes, and they should remain small
548 // regardless of the number of items synchronized. (A possible bad server
549 // implementation would be for progress_token to contain a list of all the
550 // items ever sent to the client. Servers shouldn't do this.)
551 optional bytes token = 2;
553 // Clients that previously downloaded updates synced using the timestamp based
554 // progress tracking mechanism, but which wish to switch over to the opaque
555 // token mechanism can set this field in a GetUpdatesMessage. The server
556 // will perform a get updates operation as normal from the indicated
557 // timestamp, and return only an opaque progress token.
558 optional int64 timestamp_token_for_migration = 3;
560 // An opaque-to-the-client string of bytes, received through a notification,
561 // that the server may interpret as a hint about the location of the latest
562 // version of the data for this type.
564 // Deprecated in M29. We should use the repeated field version in the
565 // PerClientTypeState instead.
566 optional string notification_hint = 4;
568 // This field will be included only in GetUpdates with origin GU_TRIGGER.
569 optional GetUpdateTriggers get_update_triggers = 5;
571 // The garbage collection directive for this data type. The client should
572 // purge items locally based on this directive. Since this directive is
573 // designed to be sent from server only, the client should persist it locally
574 // as needed and avoid sending it to the server.
575 optional GarbageCollectionDirective gc_directive = 6;
578 message GetUpdatesMessage {
579 // Indicates the client's current progress in downloading updates. A
580 // from_timestamp value of zero means that the client is requesting a first-
581 // time sync. After that point, clients should fill in this value with the
582 // value returned in the last-seen GetUpdatesResponse.new_timestamp.
584 // from_timestamp has been deprecated; clients should use
585 // |from_progress_marker| instead, which allows more flexibility.
586 optional int64 from_timestamp = 1;
588 // Indicates the reason for the GetUpdatesMessage.
589 // Deprecated in M29. We should eventually rely on GetUpdatesOrigin instead.
590 // Newer clients will support both systems during the transition period.
591 optional GetUpdatesCallerInfo caller_info = 2;
593 // Indicates whether related folders should be fetched.
594 optional bool fetch_folders = 3 [default = true];
596 // The presence of an individual EntitySpecifics field indicates that the
597 // client requests sync object types associated with that field. This
598 // determination depends only on the presence of the field, not its
599 // contents -- thus clients should send empty messages as the field value.
600 // For backwards compatibility only bookmark objects will be sent to the
601 // client should requested_types not be present.
603 // requested_types may contain multiple EntitySpecifics fields -- in this
604 // event, the server will return items of all the indicated types.
606 // requested_types has been deprecated; clients should use
607 // |from_progress_marker| instead, which allows more flexibility.
608 optional EntitySpecifics requested_types = 4;
610 // Client-requested limit on the maximum number of updates to return at once.
611 // The server may opt to return fewer updates than this amount, but it should
613 optional int32 batch_size = 5;
615 // Per-datatype progress marker. If present, the server will ignore
616 // the values of requested_types and from_timestamp, using this instead.
618 // With the exception of certain configuration or initial sync requests, the
619 // client should include one instance of this field for each enabled data
621 repeated DataTypeProgressMarker from_progress_marker = 6;
623 // Indicates whether the response should be sent in chunks. This may be
624 // needed for devices with limited memory resources. If true, the response
625 // will include one or more ClientToServerResponses, with the frist one
626 // containing GetUpdatesMetadataResponse, and the remaining ones, if any,
627 // containing GetUpdatesStreamingResponse. These ClientToServerResponses are
628 // delimited by a length prefix, which is encoded as a varint.
629 optional bool streaming = 7 [default = false];
631 // Whether the client needs the server to provide an encryption key for this
633 // Note: this should typically only be set on the first GetUpdates a client
634 // requests. Clients are expected to persist the encryption key from then on.
635 // The allowed frequency for requesting encryption keys is much lower than
636 // other datatypes, so repeated usage will likely result in throttling.
637 optional bool need_encryption_key = 8 [default = false];
639 // Whether to create the mobile bookmarks folder if it's not
640 // already created. Should be set to true only by mobile clients.
641 optional bool create_mobile_bookmarks_folder = 1000 [default = false];
643 // This value is an updated version of the GetUpdatesCallerInfo's
644 // GetUpdatesSource. It describes the reason for the GetUpdate request.
645 // Introduced in M29.
646 optional SyncEnums.GetUpdatesOrigin get_updates_origin = 9;
648 // Whether this GU also serves as a retry GU. Any GU that happens after
649 // retry timer timeout is a retry GU effectively.
650 optional bool is_retry = 10 [default = false];
652 // Set of optional per-client datatype contexts.
653 repeated DataTypeContext client_contexts = 11;
656 message AuthenticateMessage {
657 required string auth_token = 1;
660 message ClearUserDataMessage {
663 message ClearUserDataResponse {
666 // The client must preserve, store, and resend the chip bag with
667 // every request. The server depends on the chip bag in order
668 // to precisely choreograph a client-server state machines.
670 // Because the client stores and sends this data on every request,
671 // the contents of the chip bag should be kept relatively small.
673 // If the server does not return a chip bag, the client must assume
674 // that there has been no change to the chip bag. The client must
675 // resend the bag of chips it had prior on the next request.
677 // The client must make the chip bag durable if and only if it
678 // processes the response from the server.
680 // Server chips are deliberately oqaque, allowing the server
681 // to encapsulate its state machine logic.
682 optional bytes server_chips = 1;
685 // Information about the syncer's state.
686 message ClientStatus {
687 // Flag to indicate if the client has detected hierarchy conflcits. The flag
688 // is left unset if update application has not been attempted yet.
690 // The server should attempt to resolve any hierarchy conflicts when this flag
691 // is set. The client may not assume that any particular action will be
692 // taken. There is no guarantee the problem will be addressed in a reasonable
694 optional bool hierarchy_conflict_detected = 1;
697 // A single datatype's sync context. Allows the datatype to pass along
698 // datatype specific information with its own server backend.
699 message DataTypeContext {
700 // The type this context is associated with.
701 optional int32 data_type_id = 1;
702 // The context for the datatype.
703 optional bytes context = 2;
704 // The version of the context.
705 optional int64 version = 3;
708 message ClientToServerMessage {
709 required string share = 1;
710 optional int32 protocol_version = 2 [default = 34];
718 required Contents message_contents = 3;
719 optional CommitMessage commit = 4;
720 optional GetUpdatesMessage get_updates = 5;
721 optional AuthenticateMessage authenticate = 6;
723 // Request to clear all Chromium data from the server.
724 optional ClearUserDataMessage clear_user_data = 9;
726 optional string store_birthday = 7; // Opaque store ID; if it changes, duck!
727 // The client sets this if it detects a sync issue. The server will tell it
728 // if it should perform a refresh.
729 optional bool sync_problem_detected = 8 [default = false];
731 // Client side state information for debugging purpose.
732 // This is only sent on the first getupdates of every sync cycle,
733 // as an optimization to save bandwidth.
734 optional DebugInfo debug_info = 10;
736 // Per-client state for use by the server. Sent with every message sent to the
738 optional ChipBag bag_of_chips = 11;
741 optional string api_key = 12;
743 // Client's self-reported state.
744 // The client should set this on every message sent to the server, though its
745 // member fields may often be unset.
746 optional ClientStatus client_status = 13;
748 // The ID that our invalidation client used to identify itself to the server.
749 // Sending the ID here allows the server to not send notifications of our own
750 // changes to our invalidator.
751 optional string invalidator_client_id = 14;
754 // This request allows the client to convert a specific crash identifier
755 // into more general information (e.g. hash of the crashing call stack)
756 // suitable for upload in an (authenticated) DebugInfo event.
757 message GetCrashInfoRequest {
758 // Id of the uploaded crash.
759 optional string crash_id = 1;
761 // Time that the crash occurred.
762 optional int64 crash_time_millis = 2;
765 // Proto to be written in its entirety to the debug info log.
766 message GetCrashInfoResponse {
767 // Hash of the crashing call stack.
768 optional string stack_id = 1;
770 // Time of the crash, potentially rounded to remove
772 optional int64 crash_time_millis = 2;
775 message CommitResponse {
778 CONFLICT = 2; // You're out of date; update and check your data
779 // TODO(ncarter): What's the difference between RETRY and TRANSIENT_ERROR?
780 RETRY = 3; // Someone has a conflicting, non-expired session open
781 INVALID_MESSAGE = 4; // What the client sent was invalid, and trying again
783 OVER_QUOTA = 5; // This operation would put you, or you are, over quota
784 TRANSIENT_ERROR = 6; // Something went wrong; try again in a bit
786 repeated group EntryResponse = 1 {
787 required ResponseType response_type = 2;
789 // Sync servers may also return a new ID for an existing item, indicating
790 // a new entry's been created to hold the data the client's sending up.
791 optional string id_string = 3;
793 // should be filled if our parent was assigned a new ID.
794 optional string parent_id_string = 4;
796 // This value is the same as the position_in_parent value returned within
797 // the SyncEntity message in GetUpdatesResponse. There was a time when the
798 // client would attempt to honor this position, but nowadays the server
799 // should ensure it is no different from the position_in_parent sent up in
800 // the commit request and the client should not read it.
801 optional int64 position_in_parent = 5;
803 // The item's current version.
804 optional int64 version = 6;
806 // Allows the server to move-aside an entry as it's being committed.
807 // This name is the same as the name field returned within the SyncEntity
808 // message in GetUpdatesResponse.
809 optional string name = 7;
811 // This name is the same as the non_unique_name field returned within the
812 // SyncEntity message in GetUpdatesResponse.
813 optional string non_unique_name = 8;
815 optional string error_message = 9;
817 // Last modification time (in java time milliseconds). Allows the server
818 // to override the client-supplied mtime during a commit operation.
819 optional int64 mtime = 10;
823 message GetUpdatesResponse {
824 // New sync entries that the client should apply.
825 repeated SyncEntity entries = 1;
827 // If there are more changes on the server that weren't processed during this
828 // GetUpdates request, the client should send another GetUpdates request and
829 // use new_timestamp as the from_timestamp value within GetUpdatesMessage.
831 // This field has been deprecated and will be returned only to clients
832 // that set the also-deprecated |from_timestamp| field in the update request.
833 // Clients should use |from_progress_marker| and |new_progress_marker|
835 optional int64 new_timestamp = 2;
837 // DEPRECATED FIELD - server does not set this anymore.
838 optional int64 deprecated_newest_timestamp = 3;
840 // Approximate count of changes remaining - use this for UI feedback.
841 // If present and zero, this estimate is firm: the server has no changes
842 // after the current batch.
843 optional int64 changes_remaining = 4;
845 // Opaque, per-datatype timestamp-like tokens. A client should use this
846 // field in lieu of new_timestamp, which is deprecated in newer versions
847 // of the protocol. Clients should retain and persist the values returned
848 // in this field, and present them back to the server to indicate the
849 // starting point for future update requests.
851 // This will be sent only if the client provided |from_progress_marker|
852 // in the update request.
854 // The server may provide a new progress marker even if this is the end of
855 // the batch, or if there were no new updates on the server; and the client
856 // must save these. If the server does not provide a |new_progress_marker|
857 // value for a particular datatype, when the request provided a
858 // |from_progress_marker| value for that datatype, the client should
859 // interpret this to mean "no change from the previous state" and retain its
860 // previous progress-marker value for that datatype.
862 // Progress markers in the context of a response will never have the
863 // |timestamp_token_for_migration| field set.
864 repeated DataTypeProgressMarker new_progress_marker = 5;
866 // The current encryption keys associated with this account. Will be set if
867 // the GetUpdatesMessage in the request had need_encryption_key == true or
868 // the server has updated the set of encryption keys (e.g. due to a key
870 repeated bytes encryption_keys = 6;
872 // Set of optional datatype contexts server mutations.
873 repeated DataTypeContext context_mutations = 7;
876 // The metadata response for GetUpdatesMessage. This response is sent when
877 // streaming is set to true in the request. It is prefixed with a length
878 // delimiter, which is encoded in varint.
879 message GetUpdatesMetadataResponse {
880 // Approximate count of changes remaining. Detailed comment is available in
881 // GetUpdatesResponse.
882 optional int64 changes_remaining = 1;
884 // Opaque, per-datatype timestamp-like tokens. Detailed comment is available
885 // in GetUpdatesResponse.
886 repeated DataTypeProgressMarker new_progress_marker = 2;
889 // The streaming response message for GetUpdatesMessage. This message is sent
890 // when streaming is set to true in the request. There may be multiple
891 // GetUpdatesStreamingResponse messages in a response. This type of messages
892 // is preceded by GetUpdatesMetadataResponse. It is prefixed with a length
893 // delimiter, which is encoded in varint.
894 message GetUpdatesStreamingResponse {
895 // New sync entries that the client should apply.
896 repeated SyncEntity entries = 1;
899 // A user-identifying struct. For a given Google account the email and display
900 // name can change, but obfuscated_id should be constant.
901 // The obfuscated id is optional because at least one planned use of the proto
902 // (sharing) does not require it.
903 message UserIdentification {
904 required string email = 1; // the user's full primary email address.
905 optional string display_name = 2; // the user's display name.
906 optional string obfuscated_id = 3; // an obfuscated, opaque user id.
909 message AuthenticateResponse {
910 // Optional only for backward compatibility.
911 optional UserIdentification user = 1;
914 message ThrottleParameters {
915 // Deprecated. Remove this from the server side.
916 required int32 min_measure_payload_size = 1;
917 required double target_utilization = 2;
918 required double measure_interval_max = 3;
919 required double measure_interval_min = 4;
920 required double observation_window = 5;
923 message ClientToServerResponse {
924 optional CommitResponse commit = 1;
925 optional GetUpdatesResponse get_updates = 2;
926 optional AuthenticateResponse authenticate = 3;
928 // Up until protocol_version 24, the default was SUCCESS which made it
929 // impossible to add new enum values since older clients would parse any
930 // out-of-range value as SUCCESS. Starting with 25, unless explicitly set,
931 // the error_code will be UNKNOWN so that clients know when they're
932 // out-of-date. Note also that when using protocol_version < 25,
933 // TRANSIENT_ERROR is not supported. Instead, the server sends back a HTTP
934 // 400 error code. This is deprecated now.
935 optional SyncEnums.ErrorType error_code = 4 [default = UNKNOWN];
936 optional string error_message = 5;
938 // Opaque store ID; if it changes, the contents of the client's cache
939 // is meaningless to this server. This happens most typically when
940 // you switch from one storage backend instance (say, a test instance)
941 // to another (say, the official instance).
942 optional string store_birthday = 6;
944 optional ClientCommand client_command = 7;
945 optional ProfilingData profiling_data = 8;
946 optional ClearUserDataResponse clear_user_data = 9;
947 optional GetUpdatesMetadataResponse stream_metadata = 10;
948 // If GetUpdatesStreamingResponse is contained in the ClientToServerResponse,
949 // none of the other fields (error_code and etc) will be set.
950 optional GetUpdatesStreamingResponse stream_data = 11;
952 // The data types whose storage has been migrated. Present when the value of
953 // error_code is MIGRATION_DONE.
954 repeated int32 migrated_data_type_id = 12;
957 optional SyncEnums.ErrorType error_type = 1 [default = UNKNOWN];
958 optional string error_description = 2;
959 optional string url = 3;
960 optional SyncEnums.Action action = 4 [default = UNKNOWN_ACTION];
962 // Currently only meaningful if |error_type| is throttled. If this field
963 // is absent then the whole client (all datatypes) is throttled.
964 repeated int32 error_data_type_ids = 5;
966 optional Error error = 13;
968 // The new per-client state for this client. If set, should be persisted and
969 // sent with any subsequent ClientToServerMessages.
970 optional ChipBag new_bag_of_chips = 14;