Document ohttp relay best practice in payjoin lib#1547
Conversation
Coverage Report for CI Build 25828093688Coverage remained the same at 85.294%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
nothingmuch
left a comment
nothingmuch
left a comment
There was a problem hiding this comment.
the explanation of the problem needs to be clarified, but also i think just the top level module docs are enough, duplicating text usually leads to inconsistencies down the line especially when that duplication is spread out
bc1cindy
force-pushed
the
docs/relay
branch
2 times, most recently
from
d9fc58f to
8ce90d4
Compare
|
added doc about the health check practice |
|
thank you guys for the review @arminsabouri @zealsham @nothingmuch got it ready for re-review |
nothingmuch
left a comment
nothingmuch
left a comment
There was a problem hiding this comment.
a potentially more privacy preserving health check would be to create a fake session:
-
use two relays to GET and shortly therafter POST a dummy request to yourself., simulating two clients that are online
-
or do a POST first, alternating with a GET for the next check, simulating sleepy clients
such checks would be less fingerprintable than the existing ones, and would confirm the directory is forwarding messages correctly.
it would mess with the statistics gathered (e.g. unique shortids, etc), but that's something we can correct for if we know that there are reasonable limits on how much clients do this
| //! ## Health checks | ||
| //! | ||
| //! Some clients call [`fetch_ohttp_keys`] periodically to verify that the | ||
| //! directory and relay infrastructure is reachable. Given the threat model |
There was a problem hiding this comment.
not related but with #1450, key consistency should be checked as well.
There was a problem hiding this comment.
ok
once key rotation lands (#1449), the same fetch_ohttp_keys response carries both reachability and freshness info (compare returned keyid to cached)
this section should expand to cover that
5 participants
adds the OHTTP relay random selection guidance to the lib API surface, where wallet developers read it
part of #1328