Create Task
Maniphest T8529

Announce enbaled plugins to remote device
Open, Needs TriagePublic
Actions

Description

From the Telegram group:

Andy Holmes:
@nicolasfella since I see you're on plugins right now, has it ever been discussed making *Capabilities in the identity packet dynamic?

Nico Fe:
You mean announcing new capabilities after pairing?

Andy Holmes:
more like 'activeCapabilites', as in I can currently handle these packets
If i recall kdeconnectd has a DBus property/method loadedPlugins, but that's for local I believe

Nico Fe:
So you would like to be able to get the capability infromation from the identity package on request?

Andy Holmes:
yeah, as an indication what plugins the remote device has enabled
there's an obvious hurdle to using that disable enabling plugins the other device hasnt enabled, but could give an indication "/!\ The remote device hasn't enabled this plugin"
just curious if that was ever proposed

Nico Fe:
AFAIK not, but I've only been around for a year or so
Let me check whether caps are re-announced when plugins get en/disabled
Okay, obviously that is not the case. What about sending an Identity package (or something containing the caps) when the enabled plugins change? Or is there a reason for plugins to have dynamic caps?

Andy Holmes:
probably not plugin (only exception I know of being sms), but it could be useful to know what plugins/capabilities a remote device has enabled
currently you can only tell what packets a device could *possibly* handle, not what it actually will if you send one

Nico Fe:
Ah, I see. I assumed that only the caps of the enabled plugins are announced, but I just saw that this isn't the case. So, how does only announcing the caps of enabled plugins in the identity package and re-announcing them when the enabled plugins change sound?

Andy Holmes:
Well, the only problem with that is it would prevent another client from loading the plugin, since it would think it just doesn't support it. So if it were phone<->phone neither could enable a plugin the other hadn't already enabled, which neither could :)

Nico Fe:
On the other hand, it would be useful to know which plugins the other device theoretically can handle though

Andy Holmes:
Yeah, I think it would have to be seperate field

Nico Fe:
So, add a list of enabled caps to the identity package and re-send when changed?

Andy Holmes:
something like incomingEnabled, outgoingEnabled
what do you think, though? Useful?

Nico Fe:
I guess

Andy Holmes:
heh, well maybe I'll bring it up on the mailinglist so everyone sees it and the idea gets some more feedback/use-cases

apol added a subscriber: apol.Apr 16 2018, 6:52 PM

Can you please distil this description into something readable?

nicolasfella updated the task description. (Show Details)Apr 16 2018, 6:56 PM
andyholmes added a subscriber: andyholmes.Apr 16 2018, 7:04 PM

Sorry, this was mostly a RFC on my part so I'll try to clear it up:

Currently devices offer a "static" list of supported capabilities via the identity packet; outgoingCapabilities and incomingCapabilities. These will only report what packets a device can *possibly* handle though, not what it *will* handle if you send a packet.

If an additional pair, say outgoingEnabled/incomingEnabled, were sent or requestable then either auto-plugin loading could be possible or even a notice such as: "/!\ The remote device does not have this plugin enabled".

I'm not sure whether "auto-plugin" loading is a good idea or security risk, but I thought I'd get some thoughts on this idea in general. Perhaps there are other use cases as well.