DeskConn is a daemon for the Linux desktop that lets one control many features of the desktop remotely. For mobile phones (or other clients) on the local network to be able to “discover” the service, we need to be able to “announce” the service. For that I am using avahi-publish command (maybe I should use the dbus interface instead.)
Please grant the auto-connect of avahi for snap deskconn
The snap is currently using:
plugs:
avahi:
interface: avahi-control
...
apps:
deskconn:
plugs:
- avahi
slots:
- avahi-control
Which says that your snap is providing the avahi server to other snaps to be able to control. Why not simply plugs: [ avahi-control ]?
I think it will make sense for my snap to auto connect to the services-content interface on the avahi snap provided by @ondra – @jdstrand do you think it would make sense to re-purpose this request for that ?
It might make sense, but I’d like to hear from @ondra on the intent of the interface. I think the idea is for gadget snaps to auto-connect to it, but IIRC your snap is primarily a classic snap?
Depending on @ondra’s answer and if he as publisher agrees that this is the intended usage and gives his blessing for you to auto-connect, I would be in favor of it provided there is some guarantee that it will continue to work (ie, there is a reason content interfaces only auto-connect for the publisher by default: he shouldn’t break you and you shouldn’t break him).
Sorry, I see it now in the original request. Thanks!
@jdstrand sorry for delay I have missed this ping
from avahi side I do not see problem with auto connection for deskconn
@om26er I did install deskconn, but I do not see any avahi interface there. Are you planning to use avahi-observe or avahi-control ?
Mind also that now PR to enable avahi snap on classic landed, giving you option to install avahi as snap on classic systems.
I only need to use avahi-control as I want to “announce” my service on the local network.
Also, I have been following your snapd PR and eagerly wait for a new stable release of snapd. Till that happens, I have temporarily disabled the use of avahi.
my snapcraft.yaml still has a plug for your snap https://github.com/deskconn/deskconn-server/blob/master/snap/snapcraft.yaml#L78, do I also need to add avahi-control as a separate plug or will depending on your snap automatically achieve that for me ?
@om26er PR landed, so that should be in next stable. Mind this is only addressing avahi to be installed on classic as snap.
avahi-control is in fact avahi-observe + control so there is no need to have observe if you need control
request for auto connection should not be related to PR anyway, and your use case is valid so +1 from me to have it auto connected
@jdstrand Can you tell that once my snap is allowed to auto-connect to @ondra’s snap, will it need to add the plug avahi-control or is that going to be automatically covered ?
Also if this by any chance gets approved before EOW, I’d be able to experiment a lot more (not pushing) 
Just to be clear: my snap needs auto connection to
Ok, now that all the information on how the existing avahi snap is meant to be used, I’ll ask the more standard questions related to auto-connection.
AIUI, deskconn is meant to control the system it is installed on. It lets other systems on the network know that deskconn is available to control the system via avahi. It makes perfect sense that the snap would want to use avahi. That said, if someone installs deskconn on the system, what authorization/authentication mechanisms are in place for allowing a remote client to control the system via deskconn?
Sorry, I have been working to implement an authentication mechanism for this but got side tracked. I wanted to reply once I had something in place.
Currently there is no authentication mechanism but I am working on a public-private key based solution, where a barcode can be scanned from the desktop terminal for mobile phone to pair with the laptop.
I am assuming till that mechanism is in place my auto-connection request isn’t getting approved 
Thanks @om26er for the information. Based on this, -1 to auto-connect avahi-control at this time. If the authentication/authorization mechanisms are improved, we could revisit.
@reviewers - can some of your vote on this?