-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build Guide: querying source chains #535
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The query and validation lookups look good. I'm suggesting keeping coordinator agent activity as a separate topic
} | ||
``` | ||
|
||
## Query another agent's source chain |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a really different topic. You don't get back their source chain in the same way you do locally and it's for quite different purposes.
There's a huge downside, in that you have to fetch and cache their entire chain to do this. Plus it's really for examining an agent's state, not the content of their chain. You see what valid/invalid data they have, the top of their chain, any warrants etc. That's not the same as retrieving your own source chain. I think this would be better saved until we're dealing with warrants and blocking.
This function was actually flagged to be renamed in the run-up to the Holo launch to make it clearer what it does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed in f71509a
let chain_with_entries = activity.valid_activity | ||
.iter() | ||
.map(|a| { | ||
let maybe_record = get(a.1, GetOptions::network())?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could issue thousands of get
s and cause them all to be cached. This is so expensive, I'd call it an antipattern. Data that this agent intended to share should be discovered through the DHT with links and the like, ideally not via their chain unless you have a really good reason to audit their activity or something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you suggest a legit but simple use case? The only ones I can think of involve transactions, which are a rabbit hole in the extreme.
Or asked a different way, what would you have called get_agent_activity
to make it clearer what it does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed in f71509a
|
||
### Get source chain status summary | ||
|
||
`get_agent_activity` is for more than just querying an agent's source chain. It also returns the _status of the agent's source chain_, which includes evidence of [source chain forks](/resources/glossary/#fork-source-chain) and invalid actions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the primary intention of the function, and why I think it's probably not meant for this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed in f71509a ; created an issue for documenting get_agent_activity
|
||
Validation imposes an extra constraint on source chain queries. A source chain can grow over time, including branching or forking. That means a source chain, when retrieved by agent public key alone, is a non-deterministic source of data, which you can't use in validation<!-- TODO: link to validation page -->. Instead, you can use [`must_get_agent_activity`](https://docs.rs/hdi/latest/hdi/chain/fn.must_get_agent_activity.html), whose [filter struct](https://docs.rs/holochain_integrity_types/latest/holochain_integrity_types/chain/struct.ChainFilter.html) and return value remove non-determinism. | ||
|
||
`must_get_agent_activity` only allows you to select a contiguous, bounded slice of a source chain, and doesn't return any information about the validity of the actions in that slice or the chain as a whole. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here would be a good place to suggest that this is only used within RegisterAgentActivity validation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: mattyg <[email protected]>
…docs-pages into feat/guide/source-chain-query
cda0dcf
to
f71509a
Compare
Closes #474 . Talks about it from the perspective of oneself (
query
), another agent (get_agent_activity
), and validation (must_get_agent_activity
).