Conversation
mikolajpp
changed the title
Previously the %contacts agent exposed the /v1/all scry that returned the collection of all merged contacts, including peers. This endpoint was never used, and a need now arises for a scry endpoint that would rather serve unmerged information. We remove the never used /v1/all endpoint, change the definition of $directory, and serve the unmerged contact directory at /v1/directory.
arthyn
left a comment
arthyn
left a comment
There was a problem hiding this comment.
This seems good, we just need a little more data on the client I think
| :: $directory: all known contacts | ||
| :: | ||
| +$ directory (map ship contact) | ||
| +$ directory (map ship page) |
There was a problem hiding this comment.
not sure about the name but I think we'll need something like this, because when the client parses the API response it won't know the difference between a peer or a contact that has no modifications.
| +$ directory (map ship page) | |
| +$ directory (map ship marked-page) | |
| +$ marked-page [contact=? page] |
There was a problem hiding this comment.
I think the client already uses the /v1/book scry to grab contact list, and /v1/directory is not meant as a replacement? Querying the book to tell that difference would be easy, but perhaps there is some context I miss here.
There was a problem hiding this comment.
We do use /v1/book right now to grab contacts. You're correct that that we could use that list to take these /v1/directory results and subtract the people from /v1/book to get the correct "complete set". We could do something similar with the existing /v1/all scry, so this wouldn't really unlock any benefit.
My understanding was the intention of /v1/directory was to serve as a single scry we could use to get all data we need — contacts and non-contacts (would replace /v1/book).
The issue with the current implementation is there's no way to distinguish between non-contact peers and contacts who have no overrides set. Both will serialize identically. That difference is meaningful and needs to be reflected somehow in the data.
|
Talking with @latter-bolden it seems like there's not a rush for this, we should maybe just PR against tloncorp/tlon-apps |
|
If we can wait that's great. I will redirect this PR to tlon-apps then. |
3 participants
Previously the %contacts agent exposed the
/v1/allscry thatreturned the collection of all merged contacts, including peers.
This endpoint was never used. A need now arises for a scry endpoint that would rather serve unmerged contacts.
We remove the never used
/v1/allendpoint, change the definition of$directory, and serve the unmerged contact directory at/v1/directory.Closes TLON-3879