redundant data in response

[aeshna-cyanea]

sorry if this is kind of a trivial issue but it's bugging me- for the https://constellation.microcosm.blue/links endpoint it seems like the response shouldn't have a "collection" field for every item, unless i'm missing something and there's a way to specify multiple possible collections in the request. Otherwise could just limit the individual results to "did" and "rkey" fields, omitting "collection". you could instead include it at the top level (where the total response count is)

[uniphil]

No you're absolutely right. It's there because keeping the trio with did and rkey is keeping exactly what's needed to render an at-uri together, but it is redundant. (but it should be close to zero cost on the wire gzipped (untested))

I'm not committed but I think i'm moving toward returning links as at-uris instead of the did,collection,rkey triplets, in general. In a way this will have even more redundant characters but it somehow feels more defensible.

---

but taking a step back: actually yes: specifying multiple collections in the request is (eventually) coming:

• separate collection and path parameters are going to be combined in a single source parameter (so like source=app.bsky.feed.like:subject.uri)
• you'll be able to specify source multiple times to query multiple collections at once
• the results will probably be a heterogeneous list all together
• so then having the collection (at-uri or not) will no longer be redundant

(the motivating use-case for the heterogeneous response is querying for bluesky quote posts. there are two kinds of quote posts, normal ones and RecordWithMedia ones that have both a quote and an embed. the next data model will impose a global order on all links, so it will be possible to look up a query of both types mixed together, and cursor/paging is less complicated if they're in one big list).

some more here + i'm open to feedback on all of this!

---

maybe more than you asked for but that's where things are at the moment!