onionoo details document deterministic output
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, if I ask two onionoo instances running the same version (as given in the header of the document) for the same details document, to what extend should they match if relays_published matches, sorting is been taken care of and lets assume that both instances use the same maxmind files and their DNS servers provide the same answers? One example: Torprojects instance says: "flags":[] cthulhu's instance says: "flags":[""] thanks, nusenu -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVN+saAAoJEFv7XvVCELh0ywEP/RNsdjuOywrJMAuaSlLLwCYs eHK0EUcmq/DDyq2OaAK9wOgAYqtusgBp5+YhiL11dBAvuW2siTZJPiKcoj8UQk84 m6xq9FCImlxLIEe52YP+wz2t8y6p42oAiSqlMLgtBVjW6QvgK3ov0e++iEhbJbvj hKLeSPsVLHz5XWtUdSjQ5fbbpsuItzTphOc9bi/nWGGYzeRzBNdtXilU5afCysi5 GvxV2SdttRrZw0IVzbLs0CjZBBwxhiuR8yemjRTaL7QDBgS2x0TMCxqhDmVXbp70 eqwGf5Rvf9AYgGu6i+3CJk9YAPh4vcLx1XS8hKxwreIXsUpWGGOfZs3VCGVFcZKe T9oQKQgy/EX0DSi5CSU5mbAUB0XT6S6gzh2Q7ZrsYfMWOaZXuawfeyBcvp3l/gSQ vkZ496ilDsc0DK+z0rrGLNbabx3CoQmHBr8kJQS9ZqAzZEMuDETXKwOBD+IVvSYh wo7nCU9o0NrzuwQCLdjGWr7WoInMLnASgySit8sGsbjzGTigwMvbg6LD4VlUQmcj NFaofSw/KcTUDf2+ZFP5TdXOizaPHeYxfyXn+B8ntqktYav86ePpaCUtq50HMEl9 6BTKvVFcCHkpUbgYTTDFW6YMM1qSvwmODiyKQbkWaB3sItdiPZaHy5ejPSEfDRCz FOY1pHCNGjCJWjrmY5o6 =YbXp -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 other examples: different views on when last_changed_address_or_port actually happened: "A4877053906D36F47F0E610DC56E95601123C02A","last_changed_address_or_port ":"2015-04-13 14:00:00" vs. "A4877053906D36F47F0E610DC56E95601123C02A","last_changed_address_or_port ":"2015-04-11 12:00:00" diff on that field: < 259D44BDF3734077902CD71606BAD95F994A606B"2015-04-13 08:00:00 - ---
259D44BDF3734077902CD71606BAD95F994A606B"2015-04-11 12:00:00
< 3737F4542BBA0C43345BCD91C4F1E194418B313F"2015-02-14 12:00:00 - ---
3737F4542BBA0C43345BCD91C4F1E194418B313F"2015-02-15 12:00:00
< 9F938AE96C6B63F726BB885E4F2D1319C84A25BB"2015-04-12 14:00:00 - ---
9F938AE96C6B63F726BB885E4F2D1319C84A25BB"2015-04-11 12:00:00
< 4E8CE6F5651E7342C1E7E5ED031E82078134FB0D"2015-01-28 11:00:00 - ---
4E8CE6F5651E7342C1E7E5ED031E82078134FB0D"2015-01-26 03:00:00
< 73AB1555F0DA2E6D6B2AB2A603A8CB34F2981B3D"2014-12-30 20:00:00 - ---
73AB1555F0DA2E6D6B2AB2A603A8CB34F2981B3D"2014-12-30 13:00:00
... -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVN/lqAAoJEFv7XvVCELh0mfoP/1BqbvHK5Wj4+kLiXKWjLsqj Wi+XCAY98iAl1sDKffDSD3Av9BgmpFyb3xDwxTcvBFGCpwxDz9D/OsxE2yFH/FyA Q8Yv2ggP0nfgsB4Ewt8AmIUgMKD86C+L7Sqx9/WL3kRHS2p+ctNBWVtyTpOErJFX ZPYTe+iSTgz+Br4KH1P2+S5pxjc2m+o/QmFW0FsVuSs82Qhcy+jbi5zbfrBc2Zzf KK6TypJGVsAxBvBfo7yURxNgqhVyqZe6TZ0isG8BbZBggrljKJ2mdStVr+FMt25t wxEmy4/sUAPksZGO9vw94kluL1xbobsEsnKvW0EexAgXtCaVxarfTRPvXGs7j+fS aQn5ppRujyDSRW4fJZ/oVrOPhGaLDCfRQRuYhfxo6Q0mqNig1GrMxcR4nzDp/q44 93LzKBdHPn/oBokmm5VFascTNd7+edI+YiIE5DVmkdTwQXLcQS7REf6w/AW7Oq62 wotm4d5MNkH8go0MHrW5JD8nNC03Qr5z+wsBvqc+vKZykbmaouUO11VeXzGQj6/L ckmig2Zo3D1ZIbfpTNXrGe8XeEpyJVvVKe7jOaKPTrF9Lz639y0jlZR3mZkcFvi/ AaBrsLkIu1eU+doFhmUifksNkBI/tti+GMaw6uDi3b8ZwpQtuJSfj1FPzEAoluVO qT9rdoH2qMNM3j0i6H+9 =4yBm -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/04/15 20:40, nusenu wrote:
if I ask two onionoo instances running the same version (as given in the header of the document) for the same details document, to what extend should they match if relays_published matches, sorting is been taken care of and lets assume that both instances use the same maxmind files and their DNS servers provide the same answers?
One example: Torprojects instance says: "flags":[] cthulhu's instance says: "flags":[""]
Interesting. These might either be bugs, or one instance was missing a descriptor or consensus that the other instance was processing. In any case, let's try to make outputs as similar as possible. Mind opening tickets for these two issues (the one above and the one you posted to this list afterwards) and provide more details if available? Thanks! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVOj/bAAoJEJD5dJfVqbCrqCoH+wZ6QXgzbe28VrVnSDs0SGDG iKNlNoEjoXpJyrYLvATQj3N1vl5iQ2CHckiAdOwXMKjFRWYF6SAII0P/Da2zrIW/ F1BVkcbP5TyPb/6DuFYQelukOxIYzNG5vE3ktA6IlPOP/EgyeuU0YmQFp//2+FJZ mj9CKyCbN3pL4v0xj6SiBakpi6y32NIhPe5AmwcxI550ihH3S+3Ek0hXSsFQUy0i j6KyQwlhheJvNuCjjjsUoMwB1SnbKgpkVp42cE/kzny+dFEn2HCcv5dXJUuKNe0X VyyZ06NCfmc+6vnQtrSHMn8+P6HuRcOV0lfrwUzlmYJWbpOgTvgYv8QFb4uKRrs= =YqVT -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Karsten Loesing:
These might either be bugs, or one instance was missing a descriptor or consensus that the other instance was processing.
I assume the instances do not process the same descriptors in every case. That would explain most of the differences. If their 'relays_published' timestamp match, they processed the same consensus, correct? -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVO3AJAAoJEFv7XvVCELh0YvoP/iO/QAVqf3i/e4ZtG6OK9+S1 B2zju2z2YG8QLZvUSui3qlAzO48KHBID5p/aG8sLxMrDP/PloNfeqdIsYEjD3IYG xTLkuq7jQWwmMqn4agjJB96czQr+gTpbF4ZkuFGJ8klG/hUm36ldk14s9OwZGZgs 6HLTB6L8TJevlmFm22mtDE0dwsVn/Sq/emTSkWXCIm+FHVF9583XU9yhdSiZoGcL aRw8zYLDGr/FyQW64IZnr1tJES7d8gJYW+DC6rqBWXslZi9PHB39p8DelHxH4SWX /yDyPg5sQ3R6pBbBKnXv/rAmIyMIcu/cyC39o8THS2ESkFcP1cm85vHzA3uWHaVh FyNY/e7gGxug/KdMF92daUiziyB4r3b5i3ZOTS+T0emLIZ8Sx+kFrNYC625E4Vnb 8LmdvFOms6n4OUd571fg/rjMtJBwDBCMwhcBQJXcOGzYZxhskKUjOIggScbn6osA uobNDvUOp8J5QdpPmJE8QccdtzjxgtI1Zq8xfrx7uyxKbRBwMk8H9ZmfBGRQXFib 9OYRboRvMTh/WDXjF04HfGktmkLjvrgvpTsqnq5h5ESHte7mFczxNECyL6JHUFge +UrEve3lovpW2lz89a5NNuK5ppVkN5SI65Ad60d5kCuPIELMO/NUHTnzxg7+Wk8b ++2CmbyL5xcitJx/xzFK =3ku8 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/04/15 12:44, nusenu wrote:
Karsten Loesing:
These might either be bugs, or one instance was missing a descriptor or consensus that the other instance was processing.
I assume the instances do not process the same descriptors in every case. That would explain most of the differences.
The two instances fetch descriptors from collector.torproject.org at :15 and :18 every hour, respectively. It might be that descriptors are written in the three minutes in between, though it's rather unlikely. But yes, it would explain some differences.
If their 'relays_published' timestamp match, they processed the same consensus, correct?
That timestamp is updated as last step of the hourly update process. The details documents that you're fetching may have been updated before. That would also explain some differences. Thanks for opening tickets for the issues you're finding. I'm going through them on Trac as time permits. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVO3G3AAoJEJD5dJfVqbCreBgH/i2TjmhiylSfJBLZI1eN4aoP UOgvIG/YiQ4oURQT2hDTWrlAOontShfYDr6C/wPQZnPSkip2XIP9PTHi6ciGBlrV +/2yrJJJd+2Pax/DDgwvMmIYlMHY35xMGSWM82kdu3s/qv566pdrr5cCyrK/9emG OZ56f7EjK9FqRuwi79fOY95Xwmg7ZYijV/Bmz8hM5b1v7JsHHymsskad4yq7wooB YTLRhIJCNm7v51ZOCHNciwo0YgcJs8TybYK8XA/tCz4y5tcSM9Dgf1p6UInoEqxC IWhctP5r7KMypxkp+T6pIzoUcN/yVKvPFNzTtrmpToAtnU2zUTrPaAoOLawtUZQ= =HKOZ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
If their 'relays_published' timestamp match, they processed the
same consensus, correct? That timestamp is updated as last step of the hourly update process. The details documents that you're fetching may have been updated before. That would also explain some differences.
Wouldn't it make sense to mention/use the timestamp of the consensus that has been used to generate the output instead then? -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVO34KAAoJEFv7XvVCELh06iEP/jjgOs6TgRhUzYeTv36Y+U3K QhOJwTSWFhEPgWxxcH2P9ZSe4pmpFaYXAiCqG6xExikY3TEUsswhZo/klHU6wFqv gDffpM42VhQTOTCqz7NR/8EJpOxtXohSSbD+sXsIbXJ8AMCcJWSj6Pg/44AMxhGp tfAzj4vVzLvk+RGDleySN9ns/vSaYrY7yfkSnYL3pkZ8OuklR6BMiLuSUyEF/OTz GjTJeL7v1+p6HRjZU+JNazWqR+9DA0gpZX0osqUe5KLPs0R861BvcaficYdmGQmT b5jH43KH0a1NTJ5JyXvHA/YQj7cGcS1iReKOf38Pdk5+izYmRc4in5SwzCT8xXXV nNLXrRFXmRvKkHsSdk0KMwKl1syhAhwZ8Y7Go0msW3YG9a1u1P7hFfy+Jsw+JhC4 DiCDApyQ8Y00C4uysI6Njn4dL/qWiNGErUIgq5F111lmNWzfH9LpyKbe6WBMOSRQ ytasrK5BcIygCdr4Q8s3rtAf818F9CS+O0h1+QbhiNJc4clElMfGo4carTQtg0hf 2tc376XOhy/ES4ESmVuEWrY+8JFUjY4dyC+ij00QwYd4rw+MTdCRZS0hjoYKYBcN O0ofU19F+ctrN8uncbh8W4EXFxAqsxWlnFbfdTZPzkcWhT4MPGtbJ2JJDGx1Tv8y ScMdgAjROtcxVfBxeoKn =cLTr -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/04/15 13:44, nusenu wrote:
If their 'relays_published' timestamp match, they processed the
same consensus, correct? That timestamp is updated as last step of the hourly update process. The details documents that you're fetching may have been updated before. That would also explain some differences.
Wouldn't it make sense to mention/use the timestamp of the consensus that has been used to generate the output instead then?
It *is* the timestamp of the consensus that has been used to generate the output. But generating the documents that go into the output is not an atomic step. It's an hourly cronjob that runs for 15--30 minutes and writes documents for all relays to disk, and only after that is done, the relays-published timestamp is updated on disk. As I'm saying on one of the tickets, one way to change this would be to use a database and update all documents in a single transaction, but that's a major change to the current design. Which doesn't mean we shouldn't do it, but it's not trivial, and maybe it's not the most pressing missing feature. Want to run your own instance of Onionoo and help develop it? If you need a host for that, we might be able to solve that somehow. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVO5ZMAAoJEJD5dJfVqbCrJpwH/i1yIhcjh+s4zc/NKrasmScH mHEPBMXJ9+EHoiOx86X1enFoafgaEmFAiR7HdelabilTh7/sKhyMpSf51/WukLti zd8+Ln200HO6nISVbV62XuLFliTOm63PvBi/mGKw/g+jIEvsxUVhwcMtYYBtBaqD W44Y0La9T6YV//AChBLVeLOYy3NKFEf2nGD8vMlZd7GvhIVfDg2v1e4K7wCQwUsb oaKI2HSxhBlqkn0EDTUyh0EH/FNMYYDeq2KbmkssCbQXfJUuJVJnwwA3JRs4vfdz CoMNz5wW87KSgrfRRd/xWFKuwFu5tZJ9AGUPOU5FM/xuFAeJaCW/D/L180FRHOA= =7Lud -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Karsten Loesing:
That timestamp is updated as last step of the hourly update
process. The details documents that you're fetching may have been updated before. That would also explain some differences.
Wouldn't it make sense to mention/use the timestamp of the consensus that has been used to generate the output instead then? It *is* the timestamp of the consensus that has been used to generate the output. But generating the documents that go into the output is not an atomic step. It's an hourly cronjob that runs for 15--30 minutes and writes documents for all relays to disk, and only after that is done, the relays-published timestamp is updated on disk. As I'm saying on one of the tickets, one way to change this would be to use a database and update all documents in a single transaction, but that's a major change to the current design. Which doesn't mean we shouldn't do it, but it's not trivial, and maybe it's not the most pressing missing feature.
Would it be a quick and dirty fix to state the timestamp for every record separately (to become "more atomic") or does that not fix anything/is not possible? (I have no onionoo insides) "fix" in terms of: a record with a given timestamp should not change over time and multiple instances would provide the same record for a given timestamp. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVO9W9AAoJEFv7XvVCELh0EscP/imDkVPdyuJ+QPcc0vdKcIcv njW2YefPmLgP3NgiSZDCjhj7V2XTf/g99XQqgRupC9i0MoTnc7P8lvbNjXy0b9NL ig8DDoX6JPp4Lx2pPKolQpI2WYPbLCzNazbsmiTGQ7TU8lC/REsvFg3Tf+I+/saq HdL8MyL9rJ55VSlIOmMW7ojx/+mz1j1tBVnOECqNTtOlOY+/5Yx0oYKf4QKDr92c rvj0dw9DPPqcKnbusKp/mosh6whbZDVS5wNv0H90v9J+FpjFIFn//jnhVNzRnj9y t8lKEio+EyhyewaU8DzL4bUkRHCMIhc/1FKfWJJOHctdLm/9/q5BcBM0Imk9x1jM MoGxipqfMgvO4j7cHjBAMtRasMcDjRD9WMNF9xyOknKG/h99v116UJBq/j4MIigs kac/LIY8rEzBz9kNC5Q/R0QaJoBordfYjga7Ky7M4H3SF2FjmL+yJsnnS5zaUwMF UE001JlkiO0slLYJwmuP/30DZm7vd4gqwJrg3Z0WwMYPEROut0gAHr31xJCkDSAQ /gq54YgBM9V57ZJJiP6LYj5/TZFp8/qRlYKm+sBL3WGXnmsuPhfRXkmTbnvGlLnX Pgg9VSJ2YBwpG5xIP4w1U/7rDjlTtsr/D6mK/f4xsuBx8xXJpp0V30HoNibaYSDR f+2pSSo1vAPZjDXTEev+ =ohOR -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/04/15 19:58, nusenu wrote:
Karsten Loesing:
That timestamp is updated as last step of the hourly update
process. The details documents that you're fetching may have been updated before. That would also explain some differences.
Wouldn't it make sense to mention/use the timestamp of the consensus that has been used to generate the output instead then? It *is* the timestamp of the consensus that has been used to generate the output. But generating the documents that go into the output is not an atomic step. It's an hourly cronjob that runs for 15--30 minutes and writes documents for all relays to disk, and only after that is done, the relays-published timestamp is updated on disk. As I'm saying on one of the tickets, one way to change this would be to use a database and update all documents in a single transaction, but that's a major change to the current design. Which doesn't mean we shouldn't do it, but it's not trivial, and maybe it's not the most pressing missing feature.
Would it be a quick and dirty fix to state the timestamp for every record separately (to become "more atomic") or does that not fix anything/is not possible? (I have no onionoo insides) "fix" in terms of: a record with a given timestamp should not change over time and multiple instances would provide the same record for a given timestamp.
You mean instead of: {"version":"2.3", "relays_published":"2015-04-25 18:00:00", "relays":[ {"n":"shadowmourne","f":"1F515F1D420B498D9687658F4A3D176F88DD4910","a":["91.219.236.218","80.255.11.213"],"r":true}, {"n":"StinTheHuman","f":"7C05C5D24577CA4C3A904470AE5526C32290FCF0","a":["108.216.89.93"],"r":true} ], "bridges_published":"2015-04-25 17:52:43", "bridges":[ ]} something like this (note the "u" field): {"version":"2.3", "relays_published":"2015-04-25 18:00:00", "relays":[ {"n":"shadowmourne","f":"1F515F1D420B498D9687658F4A3D176F88DD4910","a":["91.219.236.218","80.255.11.213"],"r":true,"u":"2014-05-25 18:39:15"}, {"n":"StinTheHuman","f":"7C05C5D24577CA4C3A904470AE5526C32290FCF0","a":["108.216.89.93"],"r":true,"u":"2014-05-25 18:32:50"} ], "bridges_published":"2015-04-25 17:52:43", "bridges":[ ]} Yes, that would be possible, but it would not fix the `If-Modified-Since` problem. However, I this is probably just a minor problem for most users. It's still a bug, but nothing too serious. (Your use case of finding differences between two Onionoo servers is probably the exception there.) All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVO+8tAAoJEJD5dJfVqbCr54kH/i7MrhlXx1xZqSG8BgAd3EG+ 5InPtXMyblDRYGh+Ded5uFbLVQRmWnQXISwwJ/IWsvMiGrepraFLoNv0ltl2hkN0 GXwemeI2ya0OKh068vCvSsf/H6EaFoukUo76Eb3IKA10bzXZnfu3hD2BUeEPj/Pv K5JC/YBBDKBCVKZaiZKPMKfX6lpRsZNoy/iSBkrQMqLZIPuKiFRJ2Qf++SgC/BE7 u52X8rDvnAz3KrrQLecMruDnXi+cIqLuMIX2dJYBtugWpOd2/WO1MxW8ufQy8K2e 7UXL8SEu8jX51EFV2Vf3byS6pVuUyFhYVMrA7+4TBdqeZf1y+ry4UxQgwiaUkXg= =QGPS -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
You mean instead of:
{"version":"2.3", "relays_published":"2015-04-25 18:00:00", "relays":[ {"n":"shadowmourne","f":"1F515F1D420B498D9687658F4A3D176F88DD4910","a" :["91.219.236.218","80.255.11.213"],"r":true},
{"n":"StinTheHuman","f":"7C05C5D24577CA4C3A904470AE5526C32290FCF0","a":[ "108.216.89.93"],"r":true}
], "bridges_published":"2015-04-25 17:52:43", "bridges":[ ]}
something like this (note the "u" field):
{"version":"2.3", "relays_published":"2015-04-25 18:00:00", "relays":[ {"n":"shadowmourne","f":"1F515F1D420B498D9687658F4A3D176F88DD4910","a" :["91.219.236.218","80.255.11.213"],"r":true,"u":"2014-05-25
18:39:15"},
{"n":"StinTheHuman","f":"7C05C5D24577CA4C3A904470AE5526C32290FCF0","a" :["108.216.89.93"],"r":true,"u":"2014-05-25
18:32:50"}
], "bridges_published":"2015-04-25 17:52:43", "bridges":[ ]}
Yes, one timestamp per record, but I'm not entirely sure what the timestamps here represent. I expected more something like 2015-04-25 XX:00:00 (one hour granularity for consensus timestamps), but not necessarily matching the one in the relays_published entry.
However, I this is probably just a minor problem for most users. It's still a bug, but nothing too serious. (Your use case of finding differences between two Onionoo servers is probably the exception there.)
My use case will be "feed details.json into a db once an hour and use relays_published as the 'consensus timestamp' from which this data comes from". But the assumption 'this comes from consensus X' is not valid in all cases as we know. So I would use the per-record-timestamp to find out on what consensus "I'm currently looking at" (in case something like this will be added). -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVO/sDAAoJEFv7XvVCELh0pRsP/iaFADcKEK791d7cfW5FW+DH hUAmwht91MUlwr1Tjj86ASjwedWexQh9w+jGlFqVi0Wm93eNxV+4XasW56OvIxs1 DlJ1Y1PtAIjqz+GxZdI8BDd6enQk6XCefoIV9FEWQrjp2qtYoVkKVDsdjR5nV7Vz Basdr357QCmAPRMArhSp4Z1DrJ4wcZ2/v/FmkE24PaEIzS9Z5Yt7Y3cgk62JKM16 L7r+Vzz7Ss9Ad2xS0ry6SP3FtHlrTQ2mIKffwaAm3+dOBgYiyPvkP1T30CsVlDvy RDB6G/iuotZGZkJIQGq4LasQhw8c4VMPK2lg1koLPJFKgGyR60DTxhP9TEObssNp iRb3PPaELuuAhj5NxyndARRVsCmr8FuXYMhHwG7YevQh1DkNdTqox4AWgvTRO6Bd Ai2fy1X8K5Xg/Rca2/Es2P7FTktHgd64wH6FnFU0NpTWRCS/VGV0SOULDr22D7OJ ytXRAa5kYvIVzi0sdXr1jmB3Don4TVyogT97hRurbYYcooWlwqTGBaB/seacT48C 4RuryUjv4bGoP6U7M9xjeENkXcjzPX1KlJ3pPHsIAgQs9YKVvarLfU9EgdUFFA8q BgKKm0q0diii0LiWW2kTEoAKzcIZZKD/9WD4BqZlWhFLg0PpvodpuhPrivbXfbZj ZaOvhS4FPq9JGgEkoHPu =Vh+R -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/04/15 22:37, nusenu wrote:
You mean instead of:
{"version":"2.3", "relays_published":"2015-04-25 18:00:00", "relays":[ {"n":"shadowmourne","f":"1F515F1D420B498D9687658F4A3D176F88DD4910","a"
:["91.219.236.218","80.255.11.213"],"r":true},
{"n":"StinTheHuman","f":"7C05C5D24577CA4C3A904470AE5526C32290FCF0","a":[
"108.216.89.93"],"r":true}
], "bridges_published":"2015-04-25 17:52:43", "bridges":[ ]}
something like this (note the "u" field):
{"version":"2.3", "relays_published":"2015-04-25 18:00:00", "relays":[ {"n":"shadowmourne","f":"1F515F1D420B498D9687658F4A3D176F88DD4910","a"
:["91.219.236.218","80.255.11.213"],"r":true,"u":"2014-05-25
18:39:15"},
{"n":"StinTheHuman","f":"7C05C5D24577CA4C3A904470AE5526C32290FCF0","a"
:["108.216.89.93"],"r":true,"u":"2014-05-25
18:32:50"}
], "bridges_published":"2015-04-25 17:52:43", "bridges":[ ]}
Yes, one timestamp per record, but I'm not entirely sure what the timestamps here represent. I expected more something like 2015-04-25 XX:00:00 (one hour granularity for consensus timestamps), but not necessarily matching the one in the relays_published entry.
However, I this is probably just a minor problem for most users. It's still a bug, but nothing too serious. (Your use case of finding differences between two Onionoo servers is probably the exception there.)
My use case will be "feed details.json into a db once an hour and use relays_published as the 'consensus timestamp' from which this data comes from". But the assumption 'this comes from consensus X' is not valid in all cases as we know. So I would use the per-record-timestamp to find out on what consensus "I'm currently looking at" (in case something like this will be added).
https://trac.torproject.org/projects/tor/ticket/15848 All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVP678AAoJEJD5dJfVqbCrGN4IAJeoYK+ltlyxCbPiXAnSJeLM RI4msUIca92MMzRQO9BFLYmfAtqj/wHFpe3SxRyIgcZPtMHuFSVBkXSC0vBgv8/z HmZeeE0dFozVJpFHGB1yiMBEYu+e3xOs2FfJnxuI8H3wT1CXnzF540Xs/KtrG2LU mrM9Aws1t6J30AVkVOslDlgEJdVRmebpz2c2AD9pbLHYb8Zmvjqpjj2DGSLrFKmX 1JyQqGKlSDSua1dcY/mTxII1uLELMgv2DZhUSEQGV38FaxK9vCgp/C2KIT2qDweo JrIFyXSNtgUIy9SdLdThUjuEwTIIkFPOBZ+24p7HVitEt8LvFt/SnuMZr2ggiAY= =Xrjn -----END PGP SIGNATURE-----
participants (2)
-
Karsten Loesing -
nusenu