Get desktop application:
View/edit binary Protocol Buffers messages
Used in:
Used in:
This is a JSON object.
Used in:
,Used in:
,An augmentum event is uniquely identified by considering ALL of the 'timestamp', 'event', and 'instance_id' fields. ALL fields of the EventId message (event field) MUST be considered. An event CANNOT be identified uniquely if the instance_id is not set (see comments on field for additional details). ALL of these fields should be used when creating database primary keys. Currently (June 2016) the maximum size for an augmentum event is restricted 10k (INCLUDING fields added by the system during processing which MAY total a maximum of 2k) so ingestion endpoints and event producers should limit the maximum event size to 8k (ideally 4k). These maximums MAY be subject to increase in the future up to a hard limit of 100k per event (including a maximum of 10k added by the augmentum system). All fields are optional unless explicitly stated otherwise.
REQUIRED By convention, when an event spans a time range, this should represent the END time.
REQUIRED
NOT REQUIRED but SHOULD be set. Identifies a unique instance of an event, primarily used to de-duplicate data because of Two Generals esque problems. See the comments on the AugmentumEvent message for additional regarding how events are uniquely identified. The following guidelines apply to this field: - Setting this field is HIGHLY RECOMMENDED although not strictly required - If NOT set at the origin of the event, it SHOULD be set as early as possible in the data pipeline
The LOCAL part of a users jid.
This MUST be the UNPREFIXED device id. ie: it MUST NOT start with CIP, CAN, etc.
AKA: message id
The LOCAL part of a group jid
Username MUST be treated in a case insensitive way. Setting this field is necessary ONLY when the jid is unknown. When set, this username SHOULD represent a real kik user. DO NOT use this field when this username is known to not be a kik user or possibly not be a kik user (for example: a 'username search' event). The Augmentum/ingestion system SHOULD convert this to a user jid (if possible).
An OAuthed email address used to access a service. A typical use case includes email for an authenticated user accessing an internal tool.
REQUIRED for origin mobile, OPTIONAL for others. When a user_jid or device_id is specified, this refers to the the Kik client version being used.
REQUIRED for origin mobile, OPTIONAL for others When a user_jid or device_id is specified, this refers to the the Kik device type being used.
Common data: - Is conceptually equivalent to mixpanel super properties. - MAY be added to the event behind the scenes by the client library - SHOULD NOT be specific to a particular instance of an event. May be fairly arbitrary JSON (see AugStruct for restrictions though).
Flexible and arbitrary data associated with this specific event.
MUST NOT be set by even producers. This field is added by the Augmentum system directly.
Used in:
DEPRECATED - will be removed in the near future (injestion being an incorrect spelling) Should ONLY be used when delivering flattened events to the legacy augmentum-firehose-mobile kinesis stream.
The IP from which the event originated (may be either ipv4 or ipv6 style).
All fields should be restricted to ensure compatibility with S3 object keys http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html#object-key-guidelines-safe-characters
Used in:
REQUIRED Identifies the physical place the event was generated, specifically as it relates to control of event naming (ex: dev team or codebase) plus the security and trust context. Use the namespace field to provide additional context for where the event was generated.
HIGHLY RECOMMENDED be set Further identifies the place the event was generated within the context of the origin. It is up to the owners of the origin to determine what makes sense for setting this field. This field MUST NOT be dynamic in any way (ie. it should not be constructed from something whose output is not constant like timestamps, user input, usernames, JIDs, hostnames, IPs, URLs, etc). The following are the standards adopted by server. For an event that is not intended for tracing or logging, the source code repository name is typically used to help structure the namespace value. Parts of the repository name are used to start the namespace value, which can be optionally followed by dot delimited strings. For example, Xiphias service repositories have the form xiphias-service-{name}. In this case, the namespace would begin with {name}. For all other repositories, use the exact repository name. For larger repositories like kik-server, you may want to break the namespace based on the context of its sub projects. For example, the core server project can use the namespace kik-server.tigase, while the support site can use kik-server.support. Standards for request tracing and logging events are in the process of being finalized.
REQUIRED The name of the event. It is up to the owners of the origin to determine what makes sense for setting this field. This field MUST NOT be dynamic in any way (ie. it should not be constructed from something whose output is not constant like timestamps, user input, usernames, JIDs, hostnames, IPs, URLs, etc). For an event that is not intended for tracing or logging, this is the value of an enum. For languages that don't support enums, this can be a set of strings. Standards for request tracing and logging events are in the process of being finalized.