feat: client api for pkarr record republishing #79
Conversation
SHAcollision
force-pushed
the
feat/republish-api
branch
from
2a0abc5 to
4aa6572
Compare
pubky/src/native.rs
Outdated
| let max_record_age_micros = self | ||
| .max_record_age_micros | ||
| .unwrap_or(4 * 24 * 60 * 60 * 1_000_000); |
There was a problem hiding this comment.
I strongly suggest do set the default republishing interval to 1hr for the time same sake. We can still increase it in the future after research but we should aim for safe at the moment.
| let max_record_age_micros = self | |
| .max_record_age_micros | |
| .unwrap_or(4 * 24 * 60 * 60 * 1_000_000); | |
| let max_record_age_micros = self | |
| .max_record_age_micros | |
| .unwrap_or(1 * 60 * 60 * 1_000_000); |
There was a problem hiding this comment.
I agree. 4 days is extremely optimistic. They seem to last MUCH less.
pubky/src/native.rs
Outdated
| /// Maximum age in microseconds before a user record should be republished. | ||
| /// Defaults to 4 days. | ||
| max_record_age_micros: Option<u64>, |
There was a problem hiding this comment.
Why in microseconds? Sounds very excessive. What about just seconds?
There was a problem hiding this comment.
Ok, it's the standard in ntimestamp it seems so ignore me.
There was a problem hiding this comment.
Yes, this is the standard for all timming we are using. It all comes from pubky-timestamp crate https://github.com/pubky/timestamp
| @@ -85,10 +90,24 @@ impl Client { | |||
| } | |||
|
|
|||
| /// Signin to a homeserver. | |||
| /// After a successful signin, a background task is spawned to republish the user's | |||
There was a problem hiding this comment.
I don't know so I ask: Can you even sign in without an active pkarr record pointing to the homeserver?
There was a problem hiding this comment.
Exactly, you can't. You can only sign in if you can resolve the pkarr record pointing to your homeserver.
However, you most likely will get it from a pkarr relay and after signing (activity), the client pushes it to the DHT again.
|
Thanks a lot for the review @SeverinAlexB . Let's leave this PR open as WIP a few more days until we run more research on eviction and spamming and gain more confidence on the solutions ( aka |
|
Managed to fix the wasm compilation errors. Apparently Fully tested in wasm as well and to be released in #81 |
Fixes #78 .This PR implements the functionality needed to help clients ensure users' pkarr records have higher availability directly from the DHT. This PR does not add logic for the homeserver to republish its own key. This work should be done next.
Unchanged. On Signup:
The
signup()method call publishes a new pkarr record immediately. Nothing new here. This has always been the behaviour and also the only time ever a user pkarr record is published.NEW on Signin:
After signing in (i.e. after a token is successfully recovered), the client spawns a background task that republishes an existing record. It resolves the existing record once, uses the helper
extract_host_from_record(...)to determine the current homeserver host, and then callspublish_homeserver()with the conditionalIfOlderThanthan will republish a record if it's missing or older than 4 days.New Public Method to republish homeserver:
The public method
republish_homeserver(keypair, host)is now available for key management apps that know what the target homeserver should be (even if signin fails) and want to force a republishing after detecting the pkarr record is no longer available (e.g. signin failed due to unresolvable homeserver). This method allows republishing without having to trigger a full signup with the homeserver once again. It is also conservative in the use of the Dht as it will NOT publish the record if a recent (<4 days) record is found.