IPNS resolution support

b5 commented 1 year ago

Update This is only about IPNS resolution

RangerMauve commented 1 year ago

If I may, I've got some suggestions from pain points I've had in using IPNS.

Cache records as aggressively as possible
Even if a record expires, try keeping it locally while checking the network so you can at least serve something (useful for publishers going offline if it's naively configured p2p nodes)
Pubsub is nice to have to get fast updates, might lead to issues if you don't prune which pubsub topics over time especially for a gateway scenario
When publishing consider upping the TTL so that peers can be offline for longer
Have code that will republish (unexpired) records to the network can be useful when a user does a publish and then goes offline for a while
When doing lookups, the current DHT method slows stuff down a lot, so it might be good to either reduce the number of nodes you do the read from or race with pubsub and take it first.
When doing a publish the DHT also ends up being a bottleneck, it might be useful to have DHT publishing be done asynchronously of a name.publish call similar to how uploading data to IPFS lets the republishing to the DHT happen async of the file upload itself. Might be good to block on pubsub though since that's more immediate
This effort might be a good time to start talking to folks about delegated IPLD publishes so that users can use a UCAN or something similar to allow another public key to publish a record on their behalf. This is important for the case of IPNS pinning services that can keep records alive when a user doesn't go online for longer than a record's TTL. (also for multi-device updates to a key)

Not sure if any of this is actionable, but some of it could be relevant.

dignifiedquire commented 1 year ago

n0-computer / beetle