Discuss - 0014-unregistered-client-support-in-launcher about rfcs HOT 2 OPEN

• Why do we even need an explicit handshake if the anonymous-handshake is just a no-op essentially? If data for anon requests sent across the local IPC is unencrypted, why cant such apps just discover launcher and start making actual requests?
• Is there a particular reason to opt for the following with the discovery mechanism?

The broadcast shall be done every 5 seconds on port 59999.

What happens if that port isn't available? Is this discovery process based on SSDP? Want to see some input from the crust guys here in terms of suggestions/possible better approaches for local service discovery. Might help expanding the discovery protocol getting proposed here to specify details of how and why its getting proposed as is.

• Are the new getters exposed via the launcher API also available for registered clients? and if so is it a requirement that those apps need to send these requests as plain text or will the launcher be ok to use the app specific key to decrypt the request for registered clients?
• If these new endpoints are purely for anon clients / unencrypted requests, then its a bit misleading that some of the endpoints under safe-api/v1.0/dns/could be exclusive for anon/registered clients. Would it maybe help to group anon endpoints under a group indicating likewise?
• Few minor typos in the RFC. In Get file contents for a file in DNS service's home directory tree offset key is called offser, previlidge typo in "Alternative" approach section

from rfcs.

Why do we even need an explicit handshake if the anonymous-handshake is just a no-op essentially? If data for anon requests sent across the local IPC is unencrypted, why cant such apps just discover launcher and start making actual requests?

When a new process connects to Launcher, Launcher will need to know what client-engine category to allot to it. So if the requester says it requires anonymous/unregistered access to the Network, Launcher will allot it an unregistered client engine. If it claims otherwise then the usual authentication process will commence before handing it a registered client engine.

Are the new getters exposed via the launcher API also available for registered clients? and if so is it a requirement that those apps need to send these requests as plain text or will the launcher be ok to use the app specific key to decrypt the request for registered clients?
If these new endpoints are purely for anon clients / unencrypted requests, then its a bit misleading that some of the endpoints under safe-api/v1.0/dns/could be exclusive for anon/registered clients. Would it maybe help to group anon endpoints under a group indicating likewise?

All endpoints that cater to anonymous request also cater to registered clients. The differentiation itself happens in safe_core for various operations - so an error on the lines of This operation is not permitted for an unregistered client will be returned from safe_core.
As far as encryption of IPC is concerned - all communications with registered clients are encrypted sessions and with anonymous clients are unencrypted sessions. That will be automatically taken care of depending on if keys are available with SecureCommunication as hinted at the end of RFC under Implementation hints

Is there a particular reason to opt for the following with the discovery mechanism?

It's pretty simple to implement - multicast or broadcast could be switched though. Port number and intervals are arbitrary.

What happens if that port isn't available?

The discovery mechanism would fail. A UDP however should be able to broadcast to a port in all cases, not sure if availability would be a concern here as Launcher does not need to bind to that port to broadcast to it. For the client side of things, multiple UDP App's can bind to same port if address reuse is allowed - I think this is specially true for multicast and i guess equally true for broadcast, but ya better to have crust people comment.

from rfcs.