search

lightninglabs / taproot-assets

A layer 1 daemon, for the Taproot Assets Protocol specification, written in Go (golang)
MIT License
457 stars 110 forks source link

[feature]: UniverseRPC `ACK_ASSET` Server-Streaming RPC #833

Open Nsandomeno opened 6 months ago

Nsandomeno commented 6 months ago

Is your feature request related to a problem? Please describe. A universe can regularly sync remote federations via global configuration however a client must poll to learn of issuance or transfer updates. More specifically, I would like to proactively mitigate the possibility that user is searching for an asset my node's universe is not aware of.

Describe the solution you'd like I would like to have server streaming RPCs to be notified when a new asset is first acknowledged by any universe in the maintained federation, being updated with taprpc.GenesisInfo[]. A few cases that would trigger this notification would be:

(1) the issuance event of a new asset (2) a federation member syncing with a new universe

Describe alternatives you've considered Polling my universe at some interval greater than the interval the universe is globally configured to sync with federation members, checking for asset_id's that are foreign from the perspective of a client's database. This yields largely wasted attempts.

Additional context I understand the volume risk of notifications that could be accompanied with such a feature, but the goal is simply to be aware of any asset a user would have interest in... Would greatly appreciate other thoughts, concerns, and approaches!

guggero commented 6 months ago

Thank you for the feature request. I definitely see the need for this and fully agree with the use case.

But in terms of scalability, I'm not sure if a streaming RPC is a good solution. Because streaming means each client will hold open a long-term TCP connection, that can be a constraining factor very quickly.

I wonder if a compromise could be a specific RPC endpoint where the latest updated assets (GenesisInfo) and the update timestamp could be fetched. That endpoint would return all updates over the last Y minutes and would be refreshed every X seconds (and could be cached in-memory on the server side between updates). Then clients would still need to poll. But the response would be much quicker and the amount of data to poll potentially smaller too.

The main question here would be though: What value for X would satisfy your use case? Meaning, what kind of lag would you be okay with, given that today's automatic sync happens every 10 minutes.

Nsandomeno commented 6 months ago

I think that nails it, appreciate your thoughts. Considering further - I don't think there is that great of a need for a super small X value - 10 minutes feels fine in-practice/mainnet - and my regtest settings may have been influencing that part too much.