Upload tickets

This proposal has been implemented

Fetching a ticket to upload a message for sending (client->server communication):

POST /address/<hash>/ticket
{
  sender: hash
  recipient: hash
  subscription_id: <optional>
}    

Tickets fetched by user accounts are always valid. These are used for sending from client origin.

Returns ticket:

{ 
    ticket_id
    expires: 1241514
    valid: true
}

expires is the timestamp after which the ticket is not valid anymore. (TODO: can we send multiple messages to the same recipient with the same ticket?) Are ticket only used once? What if it takes longer than expiry-date to send the message? We could use check the ticket for sending the header (what about multiple headers?)

---

Fetching a ticket to send a message to another server (server->server communication):

POST /ticket/<ticket_id>
{
  sender: hash
  recipient: hash
  subscription_id: <optional>
  preference: [ pow ]
}

This will request a server-to-server ticket. Preference tells which kind of work the requester wants to do. This is just a preference list. Server ultimately decides on which worktype will be done. Currently we only support proof-of-work (pow).

Returns:

{ 
    ticket_id
    valid: false
    expires: 125321521
    worktype: "pow"
    pow: {
        bits: 22
        data: base64datatodoproofon
    }		
}

If valid is true, the ticket is valid and can be used for sending messages. When false, additional work has to be completed. The work type is defined by "worktype". Currently only "pow" exists. Inside the "worktype" section, we have specific information for the worktype. expires is a timestamp after which the ticket will be invalid. Any proof submitted afterwards will not be accepted.

---

POST /ticket/<ticket-id>

{
    pow: {
        result: 23415
    }
}

When proof-of-work has been done, the proof will be submitted to the ticket server. This will check the given result against the worktype (checked by the server, not given by the client). If the proof-of-work is correct, a valid ticket will be issued:

Returns:

{ 
    ticket_id
    valid: true
    expires: 125321521
}

or when invalid:

Returns:

{ 
    ticket_id
    valid: false
    expires: 125321521
    worktype: "pow"
    pow: {
        bits: 22
        data: anotherchallenge
    }		
}

Adding new methods

In theory, we could easily add new methods:

Client -> server:

{
    sender-hash
    recipient-hash
    subscription-id
    preference: [ math, pow ]	
}

Server -> client:

{ 
    ticket_id
    valid: false
    expires: 125321521
    worktype: "math"
    math: {
        data: "12 + 15 - 5 = ?"
    }		
}

Client -> server:

{
    math: {
        result: 22
    }
}

Server -> client:

{ 
    ticket_id
    valid: true
    expires: 125321521
}

Ideas on new methods:

• captcha
• currencies / blockchain type system