@KathyReid Could we get some feedback from the Mycroft Team on this? Would you be open to this or does it belong in a skill for now?

@DarthSpock @tsdorsey Thanks for your suggestion on this one.

Internally we've discussed implementing IFTTT support for some time. It's something we want to do longer term (18-24 months or so) but it doesn't make sense for us to do this right now for several reasons:

• There is a hefty monthly cost to providing an IFTTT channel on the platform. The size of our user base does not make this a sensible investment right now - but our user base is growing at around 1200 users per month, so over time this spend makes more sense.

• As @DarthSpock correctly points out, there is a lot of mycroft-core that would have to be written in order to implement the IFTTT protocol, and a lot of that work as you rightly state, would be in the API side of things.

• One of the _most important_ pieces we would also need to consider is non-technical. Our point of differentiation in a very crowded and fragmented IoT marketplace is the privacy premium we provide. We don't snoop on what you're saying so we can sell you ads or products. The privacy controls within the IFTTT platform would also need to be similarly rigorous so that we can protect end to end privacy. I'm not saying they're not, but it's something we would need to assure.

• We're also considering a blockchain-based ecosystem. This is another point of differentiation from IFTTT. Yeah, being totally open here, I rolled my eyes the first time we started chatting about it internally, but the more we think about it, the more it makes sense, using a proof of stake or proof of work model.

I would upvote using blockchain-based ecosystem but not sure that would invalidate getting IFTTT support. Honestly, I just want to be able to use Mycroft with Alexa, Google, Siri, and whatever other AI is out there. Since this is the only open-source AI, using it to gain control of the propiertary ones would free users to purchase whichever devices they want and still be able to centrally control it via IFTTT. And that makes sense financially about the IFTTT platform. Definantely willing to wait for it and hope it's part of the next device.

Also if you're considering considering blockchain, how deeply ingrained is Deep Learning into Mycroft core? Considering how current AI works now, this is an arena that will need improvement for some time for all current and future AI implementations (open-source or otherwise). We have a Saudi Arabian citizen robot already in existence.

So, two points here;

• To the blockchain-based ecosystem point - we would need to work out how the ecosystem would interface with IFTTT, for instance would you need a Mycroft Token to use Mycroft with Alexa, Google or Siri? Or would those services consume Mycroft Token if they were passed a request from Mycroft? Still a lot to work through there.

• To the Deep Learning point - deep learning and machine learning are not part of mycroft-core, however they're a part of several other software packages in the Mycroft ecosysem. The Precise Wake Word engine uses a neural network to distinguish between what is a Wake Word and what is not, while the Mimic 2 Text to Speech layer uses a neural network to train voice models.

I've been keeping a track of the Sophia citizen issue for a while - and what astounds me is that in a country like KSA, an AI is given citizenship, but its female population only just got the right to drive. We _also_ need to be deeply considering issues of diversity and inclusion alongside machine learning.

I've got no experience with IFTTT, could you give me some ideas on how this would be used inside mycroft-core.

Do you mean support for hitting certain webhooks on IFTTT from skills or is there more we can do like allowing IFTTT to trigger Mycroft?

I've never developed with IFTTT either but I'm thinking alittle of both. I wouldn't necessarily expect a skill developed specifically for Mycroft to work on say on an Echo Dot though that would be cool but I would expect to call the Echo Dot and all it's abilities from Mycroft via IFTTT. Actually the best comparison I can think of is the new Echo Dot Kids edition on pre-order. You should check it out, pretty cool stuff for kids. There's a video that will kinda show some of what Mycroft ought to be able to do via IFTTT.

@DarthSpock I think Mycroft could be an IFTTT trigger consumer without such profound changes, and probably within the confines of a "traditional" skill. Just for clarity, then, are you proposing that a Mycroft instance becomes a full-blown IFTTT endpoint with actions and triggers? If this is the case, I'm still not convinced building it into core is the only way (nor the best). I would propose a locally executing "bridge" that could listen for IFTTT events and then inject into the Mycroft message bus. Sort of putting these two ideas together:
https://platform.ifttt.com/docs#1-set-up-your-environment
https://community.mycroft.ai/t/can-i-have-mycroft-auto-run-a-skill/1844/5

I think it depends on what each use-case is. Some people may want full blown IFTTT endpoint while others just want some compatibility. It would help if others pitched in some input on what they'd use IFTTT for.

I, personally and professionally, would love to be able to have the ability
to communicate to-and-fro my IFTTT compatible devices and my Picroft;
especially because baby of them may only open themselves to IFTTT. I've got
several finicky "wifi" light bulbs that are 1st/2nd gen and don't handle
updates well - too cost prohibitive to replace them all because they are
all over the house and individually the bulbs are expensive due to the
features set available. In general, IFTTT seems to be more compatible in
general with the slieu of "wifi-enabled" devices In familiar with: both
old/new and large/little.

Not to mention that the protocol itself is more widely known compared to
the alternatives amongst the lay but tech friendly masses looking to build
their own SMART-home little-by-little, so that means future devices are
often setup to take advantage of that when devs are forced to pick 1
standard/protocol to spend time + money + other-resources on in development.

I would love to be able to converse back and forth or setup a poll or to
full on client-host relationship between my devices such that the
Picroft/Mycroft could be the central hub: it would enable quicker
SMART-home implementation across all the devices instead of the causing a
huge fragmentation and complex backing whereby I have to create multiple
HUBs that communicate with the [My|Py]croft and my other IFTTT devices and
non IFTTT devices.

However, if forced to choose between getting my cake tomorrow (Client+Host
[ie Full] implementation in a year or 2) or eating it today (Client
implementation only to give us something to work with until the team has
time/resources for the full deal or some other implementation), I'd be
content with eating it today. Having something to work with sooner versus
waiting for a later date that might not even be what we expect/need today
means we don't have to sit idly by on our thumbs. It would open the door
for even more seemingly impossible/complex solutions that could make this
product desirable in even more homes across the world.

Thanks,
SeriousSoft

Websites, Apps, and Consultation:
ASP.NET, C#, VB.NET, PHP, Ruby, and C++ Developer
http://Seriussoft.com
nathan.[email protected]