Discovery of which domain has a portal

[robinlindh]

In the ConjureKit, when an app scans a portal it can ask the DDS to list what domain(s) contain that portal (if the app doesn't have some other way of first selecting the domain in a menu).

What is the equivalent of this in the new discovery service? Will the discovery service have a similar mapping that each domain manager informs it of? Or could we treat it as something more generic baked into the capability string? E.g. the app could ask the discovery service for all nodes offering the '/landmark/portal/QIXUACOKWPJ' for example?

Do we have any specific reasons that we would prefer handling portals as something more specific (e.g. tokenomics, implementation complexity)?. Long-term making it easier to "scan into a domain" by other means will mean not having the portal IDs as too much of a first-class citizen.

@omusil24 how is it right now in your implementation?

[omusil24]

It will be pretty much the same as the current way - the Discovery Service will have /api/v2/portals/{portalID}/domains endpoint with similar functionality like the current /api/v1/lighthouses/{lighthouseID}/domains endpoint.

Capabilities (should) have nothing to do with specific portals or landmarks. They are meant to convey that some specific functionality is available... not serve as a link to a domain.