First of all, amazing work on the Open Payments Protocol @adrianhopebailie, @matdehaast, and @don (and everybody else I don’t know about)! 
After reading the write-up, I have the following questions:
[…] we have split the concept of Agreements into Invoices and Mandates […].
[…] we define Sessions which are ephemeral sub-accounts that are created to track incoming payments that are not linked to an issued Invoice.
Are Sessions a type of Agreement or are there Sessions and Agreements, and the Agreements are sub-categorized into Invoices and Mandates? From the rest of the section, it sounds like a Session is also an Agreement. If that is the case, please make that more clear in the first two paragraphs.
Invoices and Sessions can have one or more unique ILP addresses.
Why would we want that? I don’t really see the use case. Is it to split payments? And if so, why not have that for Mandates as well such that you can pull money from a set of accounts?
[…] different data may be returned when getting the state of an invoice or session.
Is that different for Mandates? Only authorized parties should be able to check how much has been pulled already.
I’m having trouble understanding the flow of ‘Tracking Spending’. This is how I understood it but please correct me if I’m wrong. It does not add up completely yet:
Bob is a vlogger and uploads a video to Cinnamon. Alice wants to watch the video. Her Coil extension creates a session with a session id and starts streaming. Cinnamon somehow (how?) learns the session id and creates POST requests against the /spend endpoint (how is it authorized to do that?). If there are not enough funds to spend, Cinnamon stops delivering content.
Finally, in the section Compatibility with SPSP, the response to the GET request contains balance instead of received and spent. Why not return received and spent since balance is currently not even in the SPSP spec?
