Skip to content
Snippets Groups Projects
Commit 021ceb27 authored by Benjamin Wenger's avatar Benjamin Wenger
Browse files

removed cmixProto which is now unused

parent b400e24e
No related branches found
No related tags found
No related merge requests found
#!/bin/bash
protoc --go_out=. types.proto
This diff is collapsed.
////////////////////////////////////////////////////////////////////////////////
// Copyright © 2018 Privategrity Corporation /
// /
// All rights reserved. /
////////////////////////////////////////////////////////////////////////////////
// Call ./generate.sh to generate the protocol buffer code
syntax = "proto3";
package parse;
option go_package = "cmixproto";
enum Type {
// Used as a wildcard for listeners to listen to all existing types.
// Think of it as "No type in particular"
NO_TYPE = 0;
// See proto buf documentation below
TEXT_MESSAGE = 1;
// See proto buf
CHANNEL_MESSAGE = 2;
// Nickname request and response messages
NICKNAME_REQUEST = 6;
NICKNAME_RESPONSE = 7;
// None of the UDB message types are proto bufs because I haven't had time
// to migrate UDB fully to the new systems yet.
// I was considering migrating these types to proto bufs to make them more
// compact for transmission, but you would have to compress them to even
// have a chance of fitting the whole key in one Cmix message. In any case,
// I don't think the benefit is there for the time investment.
// The prefixes of the UDB response messages are made redundant by the
// message types in this very enumeration, so at some point we can remove
// them from the UDB code that generates the responses.
// The push key message includes two string fields, separated by a space.
// First field is the key fingerprint, which the UDB uses as an key into
// the map of, uhh, the keys. This can be any string that doesn't have a
// space in it.
// Second field is the key data itself. This should be 2048 bits long
// (according to the message length that our prime allows) and is
// base64-encoded.
UDB_PUSH_KEY = 10;
// The push key response message is a string. If the key push was a
// success, the UDB should respond with a message that starts with "PUSHKEY
// COMPLETE", followed by the fingerprint of the key that was pushed.
// If the response doesn't begin with "PUSHKEY COMPLETE", the message is
// an error message and should be shown to the user.
UDB_PUSH_KEY_RESPONSE = 11;
// The get key message includes a single string field with the key
// fingerprint of the key that needs gettin'. This is the same fingerprint
// you would have pushed.
UDB_GET_KEY = 12;
// The get key response message is a string. The first space-separated
// field should always be "GETKEY". The second field is the fingerprint of
// the key. The third field is "NOTFOUND" if the UDB didn't find the key,
// or the key itself, encoded in base64, otherwise.
UDB_GET_KEY_RESPONSE = 13;
// The register message is unchanged from the OG UDB code, except that
// the REGISTER command in front has been replaced with the type string
// corresponding to this entry in the enumeration.
// To wit: The first argument in the list of space-separated fields is
// the type of the registration. Currently the only allowed type is
// "EMAIL". The second argument is the value of the type you're registering
// with. In all currently acceptable registration types, this would be an
// email address. If you could register with your phone, it would be your
// phone number, and so on. Then, the key fingerprint of the user's key is
// the third argument. To register successfully, you must have already
// pushed the key with that fingerprint.
UDB_REGISTER = 14;
// The registration response is just a string. It will be either an error
// message to show to the user, or the message "REGISTRATION COMPLETE" if
// registration was successful.
UDB_REGISTER_RESPONSE = 15;
// The search message is just another space separated list. The first field
// will contain the type of registered user you're searching for, namely
// "EMAIL". The second field with contain the value of that type that
// you're searching for.
UDB_SEARCH = 16;
// The search response is a list of fields. The first is always "SEARCH".
// The second is always the value that the user searched for. The third is
// "FOUND" or "NOTFOUND" depending on whether the UDB found the user. If
// the user was FOUND, the last field will contain their key fingerprint,
// which you can use with GET_KEY to get the keys you need to talk with
// that user. Otherwise, this fourth field won't exist.
UDB_SEARCH_RESPONSE = 17;
// The client sends payment transaction messages to the payment bot to
// fund compound coins with seed coins. In the current implementation,
// there's one compound that gets funded that's from the payee. This comes
// across in a PAYMENT_INVOICE. And there's a second compound that contains
// the change from the seeds that the payer is using to fund the invoice.
// The rest are the seeds that are the source of the payment.
// All of the seeds and compounds are in an ordered list, and they get
// categorized and processed on the payment bot.
// To get a message of this type, call the methods in the wallet.
// TODO expose these methods over the API
PAYMENT_TRANSACTION = 20;
// See proto buf
PAYMENT_RESPONSE = 21;
// See proto buf
PAYMENT_INVOICE = 22;
// This message type includes only the message hash of the original
// invoice message. Since there are no fields to delimit, it's not a
// proto buffer. When the payee gets a receipt back, they know that the
// other person probably paid them, and to check the next published
// blockchain for the images of their coins to make sure.
// The wallet sends this message after receiving a PAYMENT_RESPONSE
// indicating success.
PAYMENT_RECEIPT = 23;
// End to End Rekey message types
// Trigger a rekey, this message is used locally in client only
REKEY_TRIGGER = 30;
// Rekey confirmation message. Sent by partner to confirm completion of a rekey
REKEY_CONFIRM = 31;
// These are specialized messages that convey the information that
// the UI needs to know once the wallet's finished updating. They shouldn't
// go over the network. Types 9000-9999 are reserved for messages like this.
// This message type is a single fixed-length hash of the invoice
// that the client just received. The client can look up this hash in the
// inbound transaction list to display the most recently received invoice
// in the UI.
PAYMENT_INVOICE_UI = 9000;
// This message type is a single fixed-length hash of the original invoice
// that this client sent to the paying client. The UI can look up the
// corresponding transaction in the list of completed transactions and
// display payment success on the UI. The wallet sends this message
// locally after receiving a PAYMENT_RECEIPT message.
PAYMENT_RECEIPT_UI = 9001;
}
// Use this enumeration to get specific transactions from specific transaction
// lists from the wallet
enum TransactionListTag {
// Transactions in this list are invoices this user made to another user
// Most importantly, they include the preimage that this user wants fulfilled,
// but the image of this preimage is what the client will send in the invoice.
// Transactions enter this list when this user invoices another user.
OUTBOUND_REQUESTS = 0;
// Transactions in this list are invoices that this user received from
// other users. Most importantly, this includes the image that this user
// will fund.
INBOUND_REQUESTS = 1;
// Transactions in this list are currently processing on a payment bot.
// Transactions move from INBOUND_REQUESTS to PENDING_TRANSACTIONS after
// a Pay() call.
PENDING_TRANSACTIONS = 2;
// Transactions in this list are completed transactions that increased
// the value of this user's wallet. NOTE: They correspond to transactions
// originally in the OUTBOUND_REQUESTS list that went through.
COMPLETED_INBOUND_PAYMENTS = 3;
// Transactions in this list are completed transactions that decreased
// the value of this user's wallet. NOTE: They correspond to transactions
// originally in the INBOUND_REQUESTS list that went through.
COMPLETED_OUTBOUND_PAYMENTS = 4;
}
// Use this enumeration to request different sort orders of transaction lists
// when getting all IDs in a transaction list
enum TransactionListOrder {
// Most recently initiated transaction first
TIMESTAMP_DESCENDING = 0;
// Stalest transaction first
TIMESTAMP_ASCENDING = 1;
// Biggest transaction first
VALUE_DESCENDING = 2;
// Smallest transaction first
VALUE_ASCENDING = 3;
}
// Text message types
// Is Type.TEXT_MESSAGE
// Used for conveying simple text messages between users
message TextMessage {
// Terminal text foreground color. Used by the console UI
sint32 color = 2;
// The message text itself. Varies in length
string message = 3;
// Timestamp (Unix time in seconds)
// You can use this to display the time when the other user sent the message
// TODO Remove this when all messages have timestamps
int64 time = 4;
}
// Is Type.CHANNEL_MESSAGE
// This is the type of all messages that come from the channelbot.
message ChannelMessage {
// This is the original speaker of the channel message, who sent the
// message to the channel bot.
bytes speakerID = 3;
// This is a serialized parse message under the hood. When writing a
// listener for a channel message on a client, you need to unpack the
// serialized parse message and rebroadcast it through the listeners.
bytes message = 4;
}
// Payment message types
// Is Type.PAYMENT_RESPONSE
message PaymentResponse {
// Indicates whether the payment succeeded or failed
bool success = 1;
// Response message from the payment bot. You should display this to the
// user.
string response = 2;
// TODO Is it correct to use the whole hash?
// This is the hash of the payment message that the payment bot received.
// The client uses it to remove the correct pending transaction from the
// list of pending transactions.
bytes ID = 3;
}
// Is Type.PAYMENT_INVOICE
message PaymentInvoice {
// Timestamp (Unix time in seconds)
// Not currently used but could be useful for the user to verify the
// correctness of an invoice.
int64 time = 1;
// This is a single compound coin that the invoicer wants to be funded. The
// payer should send a message to the payment bot to fund this compound, if
// they wish to pay the payee.
bytes createdCoin = 2;
// The payee should fill this out to describe what the payment is for or
// about.
string memo = 3;
}
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment