NFTs for Mycroft skills a good idea?

Hello, I am working on a concept for a white-label voice assistant skill shop that also contains commercial skills. One idea is to add NFTs to Mycroft Skills so that skill developers can get royalties whenever a shop instance sells a skill.

I would like to get some feedback - especially from skill developers - about this idea. Maybe someone experimented with NFTs already? Does it even work since skill code is visible in Mycroft anyways?

I’m mixed with the idea I guess, I understand the “requirement” of making money but I’m afraid about the impact it could have on the community.

What about the “fork”, what will be the protection about the skill been installed on the instance and the code pushed on GitHub (with different name, code structure, etc…)?

I would be more for a reward system, like if the skill is well rated by users or “popular” then the developer could have a compensation by the company who owns the marketplace.

This is a tricky subject :stuck_out_tongue:

1 Like

I would absolutely avoid anything using nft’s or crypto.


Do you have an argument too?

Let’s start with

You’ve managed to point out one major flaw in your idea already. Maybe you meant to propose a donation address for developers who want to get crypto for their efforts? Like patreon for crypto?

Not sure what you think NFT’s actually are, and how they’d apply here, but very curious for you to delve more deeply into that idea so I can find out what the latest…ideas…about those are. :slight_smile:

1 Like

you can send me crypto!

but you can keep your NFTs, if you want to buy some more i can spam some real quick, i promise they are worth real money and not just a link to a picture xD

1 Like

Getting a bit more serious now

Compensating skill devs is something we need, Pling does this based on donations and distributes between devs according to number of plings/downloads. a pling is essentially a upvote by people who donated money. Since donations are not direct this helps making the ecosystem healthier since every developer gets something just by being in that marketplace

As a first step i think all we need is a proper donate button in the marketplaces, devs can also add a github sponsor button

Other options like Liberapay and Patreon are all better than a NFT or a paywall to get access to the skills.

Mycroft is a FOSS community, if make your skill proprietary someone will make a FOSS version as soon as there is a need for that functionality, so it will never work out quite right. If the community was accepting of proprietary code, then they would use amazon or google since their assistant works better!

If you skill is FOSS but still behind a paywall, well, only 1 person ever needs to buy it before sharing in practice, so the paywall is just an encouragement for the donate button and not a real paywall, in that case does it even make sense to have a paywall?


I agree that the idea is to compensate skill developers/maintainers. But I do not believe that donations provide reliable income - especially in the B2B world I can imagine many free-riders. To be clear, I am not talking about skills like “turn the coffemachine on/off”. I thought about complex skills, e.g. to interact with Enterprise Resource Planning systems, or domain-specific software.

I think that a compensation model should benefit skills with open source license and those without. In B2B, there can be good reasons why skills are partially or entirely closed source. As far as I understand, Mycroft requires only the training utterances to be known by the Mycroft skill. Program code executed after intent recognition can be placed outside of a Mycroft skill and accessed via an API. Also all responses may be generated outside Mycroft. That means the current skill structure/life cycle allows developers to disclose code, I think.

Those code parts that are visible in Mycroft can still have a license that does not allow third parties to copy the code - the code can be visible but its use may be restricted. Of course, bad actors can still copy the code, distribute and use it. However, I think that in professional application areas legal actions may end up costly for the one using code without a license.

I imagine NFTs as a way to track skill licenses (e.g. in a distriubted ledger). Of course, someone might run a skill without “owning” the related NFT, so there must be some kind of programmatic enforcement (in a software) - otherwise it does not work. A customized Mycroft could enforce it by asking for a valid NFT connected to a skill. The shop could contain a function to transfer the NFT from the seller to the new owner. The NFTs make more sense though, if skills are interoperable among different assistant platforms (provided there is an interoperability solution). Then, skill “owners” could avoid vendor lockin.

And then one thought about rejecting proprietary code/skills. I believe, that proprietary code has its fair prupose - after all, when organizations spent 100s of person months on software they may want to benefit from it with a comfortable margin. However, there will be some legal and ethical requirements for transparency/explainability; and also security may benefit from making code transparent. Amazon or Google (or other large IT providers) are and may never be transparent about how their assistants work. Migrating an assistant or a skill to their platform will directly hurt privacy, confidentiality, and sovereignty (which is a thing outside the USA). In B2B, this could be a deciding factor. Finally, I haven’t seen many B2B skills for Amazon or Google yet except office management.

who is supposed to make money with your proposal?

imho if you want skills for corporate usage, you dont need a marketplace, you need to create a business around it and provide that yourself.

thats not how the average skill developer will make money, those hypothetical high value complex skills are full fledged applications requiring full teams behind them, this is not money for community devs, its money for someone making a business out of it already. Companies should hire developers directly for this magnitude of work. Either that or its probably a low value skill

i understand the argument for closed source, some medical or gov contracts might even require it in some places, in most of those cases there still is no benefit for the mycroft community at large and funding comes from very specific places already

I still fail to see how NFTs apply, either you dont know what a NFT is or i don’t.

Is your aim that only one person can have the license at the time? is that what the non-fungible-token you transfer represents?.. a NFT is a url to the text of a license, let that sink in. You want devs to sell link to licenses between each other, and the author can issue as many as it wants as its source of income. You already know the contents of the license without the NFT, who “owns” the soon-to-be-404 reference does not matter.

just close the source and license it directly as usual under a proprietary license ? works for microsoft!

tldr, the compensation for closed source code is the money you get by selling it, this problem has been solved eons ago

Maybe the NFT part requires further context :slight_smile:

NFT is not only about selling art, first of all. There are projects demonstrating how to sell software licenses via NFTs ( (outdated), Products -
Here is also a comprehensive summary concerning NFT marketplaces and licenses (though largely related to arts): Non-Fungible Token Marketplaces and License Issues

The proposal is for a large grant to build the white-label shop and products/skill-packages, and evaluate everything with businesses. My thought is that skill providers and shop operators make money by selling skill-packages + services (consulting, maintenance, hosting, etc.). Ideally, shop instances are federated to make it easy filling the “shelves” with skills and to give customers high flexibility (free choice of assistant platform and skills). Of course, one company could make corporate skills and sell them the old way, but a digital assistant’s benefits depend on the number of available skills. If one company is the only provider, it is hard to convince buying into digital assistant technology. Imagine you had only a hand full of App developers and no shared stores to distribute the software - Smartphones would have hardly gotten the utility they have now.

Corporate skills can become large indeed. That is why a “skill developer” can be a company - I understand that most Mycroft skill developers are individuals, but my ambition is to change that :slight_smile:. Using Mycroft as an assistant platform is a good idea, in my view, since the legal framework in Europe will likely be more in favor of solutions that are not centralized (“Big Five”) and fully respect ethics/privacy.

I am not against the blockchain system or the tech behind it but am not convinced about NFTs or Crypto being the best option

  • Trading in anything related to blockchain and cryptocurrencies is either banned or on the verge of getting banned in quite a few countries, its also now coming under heavy regulations where its allowed. This then becomes an unfair market where only developers and users from some countries who can legally trade in Crypto or NFTs would benefit from, blocking all other developers and users.

  • Companies wanting to invest resources and make profits can also simply use a subscription model much like other platforms like Netflix, Spotify, etc, Anything to do with Crypto / NFTs means your dealing with volatility of the crypto market, if a developer / company is paying for API access or cloud services on their behalf and expect a X amount per sale to cover the cost of paying for those, they literally could end having to pay out of their pocket if the crypto market crashes. At least with a subscription model or the fixed amount model they hold a guarantee against sudden value changes.

  • There isn’t a lack of shared stores, open source on the contrary is full of them and skill developers / companies can easily adopt one of the existing ones as a shared platform for distributing skills as packages, there might be some that even allow distribution of closed source software.

1 Like

Thanks for the response. I agree that crypto currencies are a (legal) concern for several reasons. However, using NFTs does not require customers to pay with crypto currencies (where necessary, this could be done by the shop operator in the background in a country where it is not restricted). Also developers could receive royalties directly in fiat - no need to store cryptos. Since assistants are a rather new topic still, I think its more fruitful to not burden customers/users with crypto currencies.

A subscription model is an option, but how would such a model support royalties based on re-selling (e.g. sell skills you do not need)? I mean it is probably possible with a custom solution but that creates overhead costs.
Also, working with NFTs does not require anyone to hold a bag of crypto currencies (though some NFTs can be backed with crypto currencies and possess a minimum value dependent on that currency’s price).

You are also right about the fact that there are open source shops. The plan is to extend/modify an existing one - potentially adding NFT support.

Why use NFTs or crypto when you could use a typical payment network/service like Stripe Connect?

1 Like

I think one problem is that federated shops might not track skill selling and re-selling and would need a service that can do it. These are the scenarios in my view:

  • If I have a standard shop, I can track the skill sales and compensate my customers with inbuilt or external payment services. I cannot get skills from other developers unless they make a contract with me.
  • If I have a federated shop, I could access the skills from the federated system (other federated shops) to offer more skills in my shop. I do not want to make individual contracts with these skills’ developers to keep my overhead costs low. The developers may want the same. Also, I am competing with other shops, so I do not want to share may sales data in the federated system (but I am not sure if this is always the case).

The idea is that a distributed ledger tracks skill transfers (sales, re-sale?) and automatically handles the payments via smart contracts. This process requires cryptocurrency to power the smart contract and maintain the NFTs but the developers or buyers would not necessarily see that - its an obligation of the selling shop.

The workflow could be this:

  1. A federated shop instance integrates a skill from another federated shop instance
  2. The first instance sells this skill 25 times (the second instance does not know, it only knows instance one offers the skill)
  3. The first instance generates 25 NFTs and transfers them to the mycroft instances of the buyers
  4. Each transfer triggers a smartcontract that calculates royalties and distributes them (e.g. to the providing shop instance)
  5. A currency exchange service in the shop instances could turn crypto to fiat if needed

Why not use skill metadata/readme with payment instructions?
Because developers cannot enforce the payments. There will likely be free-riders that do not pay but will use the skill.

Why not use license keys to control who can use a skill?
Because that would need a license check, probably on a trusted hosted service. Appears quite similar to the NFT idea but does not solve the payment issue directly.

A key issue are the contracts and terms too. For instance, what are the legal hurdles for corporate skill users (e.g. liability)? Or how to manage support?

I build web apps that have action tracking (logging) and payment gateway integrations and data redundancy. I’ve never understood what the actual advantage of an encrypted distributed ledger is and I’m afraid this post doesn’t clarify the need. Every time I say that, someone pro-crypto tries to explain it to me further, but they coming at it with the misunderstanding that all the features they’ve explained don’t require the solution they’ve proposed.

If you believe it has inherent value, then build it I guess. I just think you’ll have a hard time convincing developers who have known for a long time that these problems have been solved by more stable and less complex solutions.