📅 Original date posted:2017-03-06
📝 Original message:On Monday, March 06, 2017 9:54:16 PM Tim Ruffing wrote:
> Having the rate at the time of payment is indeed very useful, yes.
> However that requires just a single value per payment, and there is no
> query that tells the server "give me the value closest to timestamp t"
> or similar.
> Of course the client can download and keep a large part of history and
> extract the information on its own but I can imagine that not every
> clients wants to do that, and also the client does not know in advance
> the bounds (from, to) that it must query.
It would be a privacy leak to request only the specific timestamps, but I
suppose many wallets lack even basic privacy to begin with.
To address the bounds issue, I have specified that when from/to don't have an
exact record, that the previous/next (respectively) is provided.
Hopefully this addresses both concerns?
> In the current draft the client or the server cannot specify
> granularity. If the clients only wants one value per day but for an
> entire year, then it has to perform many requests or download and
> process a very large response.
That's what the "timedelta" field solves, no?
If you want one value per day, you'd put 86400.
> Also, I think it's okay that the type field allows for arbitrary user-
> defined values, but it should also have some precisely defined values
> (e.g. the mentioned low/high/open/close/typical).
> For example, it's not clear currently what "low" means for a timestamp
> (as opposed to a time span). Is it the low of the entire day or the low
> since the previous record or something different?
Is it not sufficient for the server to specify this in the description of the
given currency-pair feed?
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:56:54
in reply to nevent1q…hn79
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:56:54Event JSON
{
"id": "8a43cfb9dbd6c42f60253d5003903deb16d70f8b3f1d65450ba55cd476bd60dc",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160614,
"kind": 1,
"tags": [
[
"e",
"7d71aaf3aaa91e1454a25f4f9688ba685bebb747e49a8ad14b817de1aa470d06",
"",
"root"
],
[
"e",
"2b3f76028941dedebd51d48a5d17eae51158d17ce158f6f85a5f695b752a8f79",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2017-03-06\n📝 Original message:On Monday, March 06, 2017 9:54:16 PM Tim Ruffing wrote:\n\u003e Having the rate at the time of payment is indeed very useful, yes.\n\u003e However that requires just a single value per payment, and there is no\n\u003e query that tells the server \"give me the value closest to timestamp t\"\n\u003e or similar.\n\u003e Of course the client can download and keep a large part of history and\n\u003e extract the information on its own but I can imagine that not every\n\u003e clients wants to do that, and also the client does not know in advance\n\u003e the bounds (from, to) that it must query.\n\nIt would be a privacy leak to request only the specific timestamps, but I \nsuppose many wallets lack even basic privacy to begin with.\n\nTo address the bounds issue, I have specified that when from/to don't have an \nexact record, that the previous/next (respectively) is provided.\n\nHopefully this addresses both concerns?\n\n\u003e In the current draft the client or the server cannot specify\n\u003e granularity. If the clients only wants one value per day but for an\n\u003e entire year, then it has to perform many requests or download and\n\u003e process a very large response.\n\nThat's what the \"timedelta\" field solves, no?\nIf you want one value per day, you'd put 86400.\n\n\u003e Also, I think it's okay that the type field allows for arbitrary user-\n\u003e defined values, but it should also have some precisely defined values\n\u003e (e.g. the mentioned low/high/open/close/typical).\n\u003e For example, it's not clear currently what \"low\" means for a timestamp\n\u003e (as opposed to a time span). Is it the low of the entire day or the low\n\u003e since the previous record or something different?\n\nIs it not sufficient for the server to specify this in the description of the \ngiven currency-pair feed?\n\nLuke",
"sig": "4f86f9dab79943ff7fbb0a878cb76d0664b60a7931ab110dcbfe8b0e4b7d95fd3debc9c0adf40cfe69dbeee71ee6350b569b33269a9da5d5daf34148d55d4565"
}