@gaditb did: is an IRI format which specifies a resolver (plc?) and a resource key; at:// is a protocol which takes a DID and indicates that it should be accessed using the AT protocol and then that the path should be followed (side-note: IETF does not like the name at: but has no mechanism by which to disallow it)
so this is saying
Access [PLC DID] with AT and then access the [app.bsky.feed.post] collection and then access item [ID] within it
@Lady Yeah no that's the bizarre thing I mean.
The "app.bsky.feed.post" bit, based on its contents, sure looks like IT is the "where to go for the data you don't presently have".
Whereas a did:... is an opaque identifier. It davka DOESN'T point to any further info besides itself! What does "access [PLC DID]" even mean? Access it through WHAT? Where would there be anything interpreting to be an authority defining a "app.bsky.feed.post" collection?
@gaditb see for yourself: https://plc.directory/did:plc:x4qyokjtdzgl7gmqhsw4ajqj
it's a centralized resolver service (plc.directory) that tracks a bunch of metadata about the thing in question
@gaditb the at protocol then specifies how to turn that response plus the path into something meaningful
@gaditb (DID registry is here if you are curious <https://www.w3.org/TR/did-spec-registries/#did-methods>. i think this whole thing is very silly and reinventing problems we all agreed were a bad idea like ten years ago)
@Lady I don't know what you're talking about, "silly". This is great and good: https://xn--3n8h.amy.gy/
@Lady But what is the listener you are you asking. What would the PLC be resolving to.