Can generic DID tooling resolve a Solidus pod's identity yet?

No.

The check, with controls that make it mean something

$ curl -s https://dev.uniresolver.io/1.0/identifiers/did:solidus:testnet:<id>
  501  {"didDocument":null,"didResolutionMetadata":{"error":{"type":"METHOD_NOT_SUPPORTED"…}}}

$ curl -s https://dev.uniresolver.io/1.0/identifiers/did:key:z6Mkha…
  200  {"didDocument":{…}}          ← The resolver is up and resolving

Without that second line the first would prove nothing: a failure could just as easily mean the service was down. It is not. It is working, and it does not know our method.

And a correction to our own notes: we had recorded this as a 404. It is a 501 with an explicit METHOD_NOT_SUPPORTED, which is a more useful and more honest result: a 404 could be read as "that identifier does not exist", while a 501 says plainly "this resolver does not implement your method." The distinction matters and we are fixing our record rather than repeating it.

What it means in practice

Any tool that resolves DIDs generically, a wallet, an agent framework, a verifier library that takes any did: string, cannot resolve ours. It has to be taught our method specifically, by someone, in code.

That is a portability limitation and it belongs to us, not to the resolver. Their software is doing the correct thing.

The concrete cost: an integrator who wanted to accept identifiers from several methods, ours among them, cannot just point at a generic resolver. They must either use our RPC endpoint directly or write a driver. Our RPC is public and takes no credentials, so it is not a blocked path, it is a bespoke one, and bespoke is a cost we are imposing.

What is actually true on our side

Our own resolution works and anybody can call it. The same identifier that the generic resolver refuses returns a full document from our RPC, with an invented identifier returning null as the control.

And the method specification is public, linked from our registry entry, what that entry is worth, so writing a driver is unblocked work rather than a closed door. Nothing about the design prevents it. Nobody has done it, including us.

Why this is a real gap and not a technicality

The point of a DID method is that a stranger can resolve it without your cooperation. A method only a bespoke client can read has, in practice, a smaller version of the property it was created to provide.

We are not going to describe "use our endpoint" as equivalent. It is not: it puts our availability in the path of anyone resolving our identifiers, and our chain is four validators, all operated by us. A WebID has no equivalent problem, because there is nothing to support: it is an HTTP GET.

What would close it

A driver for the generic resolver, contributed and accepted. Unstarted.
A second, independent resolution endpoint run by somebody who is not us. None exists.
A published interoperability check showing a third-party client resolving our identifiers. Not run, so we claim no pass and imply no failure.