Candy Library - Try 2 - Financing Software on the IC

Happy Holidays!

TLDR: I was behind the Aramakme project, I’m reveling the library that was supposed to be ‘uncovered’ by buying NFTs, I’m handing it over to ICDevs, you can still by the NFTs for now…I might stop the sale at some point, all the proceeds for what has been sold so far will go to paying my taxes on the sales and then to an 8 year dedicated neurons benefiting ICDevs.

I’d like to open up the doors on a very poorly held “secret”. Before launching ICDevs I was working on a software funding mechanism for the IC. I had some concerns about how things would play legally, the platform was new, and I wanted to maintain some anonymity so I launched it under a pseudonym. I don’t want to say that the experiment was a total failure because it intersected with some horrible personal circumstances and I was unable to give it the time and attention(and social media professionalism that NFT projects apparently need - side note…you can’t really do twitter or telegram through TOR…another reason we need the IC). So…if not a total failure…at least a partial failure. I’ll document how it failed below in the post mortem. If I’ve communicated with you from the pseudonym or played dumb with you, my apologies, I wasn’t sure how this was going to turn out and I was advised to keep it on the down-low until I had a better idea which direction it would go.

Basically, I’m the pseudonym @armakme and the project that was launched around the NFTs was all stuff I did before launching ICDevs.

Since it is the Holidays and the architecture of the IC has changed a bit(we can hold ICP now!), I’m going to go ahead and reveal the Candy Library that was supposed to be exposed by people buying the NFTs. You can find the library here. Hopefully, it will help some folks and, hopefully, the designers of Motoko don’t throw too many tomatoes at me for my poor coding style and routes around the core tenets of the language.

In addition, I’m going to hand over all the code and containers over to ICDevs. Any more funds that come in on the NFTs(minus taxes) will go into an 8 year neuron benefiting ICDevs. If people actually start using the code, all the cycles it produces will be donated to ICDevs as well.

Hopefully, some Motoko devs find the candy library helpful. I’ve used its components quite a bit in a couple of other projects and I think some of the conversion utilities are helpful. It also has some helpful features that can be used to figure out the size of a collection and split it up if you need to send the data across the wire under the 2MB limit.

The actually aramakme licenses in their various forms are worth discussing and I’d love to continue the conversation about those. The IC has an amazing way to fund software that very few people are talking about! TLDR: You run the code, pay cycles at the beginning of each month, and then after X number of calls…so there is only an await used to send cycles on very rare instances. There are also mechanisms for forking and improving code that maintains some value for the original creators. If you have written some motoko code that might be valuable to the community, consider releasing it under the aramakme license and you may never have to buy cycles again.

There are way more details of how it all works at https://hwqwz-ryaaa-aaaai-aasoa-cai.raw.ic0.app/

Here is a brief post mortem of the experiment:

I posted the application here: https://hwqwz-ryaaa-aaaai-aasoa-cai.raw.ic0.app/

It was way to technically detailed for most of the NFT pile on crowd. I should have just put an image and a buy link and left it at that, but I do really like the funding mechanism behind all of this and it and I thought I could punch through the NFT hype with something that actually “did” something(Help distribute software and get a royalty).

The basic concepts of a distribution license came out of a lot of talks with lawyers about how one could actually build and structure a token mechanism that passed the Howey test. The main output was instead of issuing tokens, issue exclusive software distribution licenses.

Here is a number of ways the project failed:

The funding mechanism drew almost no attention. I posted a forum post here(Financing Software Built for the Internet Computer) that basically got no attention. I think everyone was pretty focused on getting canisters to hold ICP, so the concept of funding using cycles just didn’t have much attention. The fact that we don’t have a good market for cycles is probably also an issue, but perhaps once that market matures this will a more attractive funding mechanism?

I only sold about 40 NFTs. It isn’t nothing, but I was shooting for 1500+. It was a tough sell because you had to jump through some hoops to actually buy the things. Send ICP here, click a claim button…hope all the transactions clear. Hopefully, @kpeacock’s Invoice like thing will make all of this much more simple in the future.

Interoperability on the IC really let me down. Entrepôt is great and all the work Toniq is doing is awesome, but during this one period, the fact that I couldn’t get it listed really affected sales. I’ve been talking with those guys and now that we have ICP in canisters and DAB and a bunch of other stuff coming, I fully expect to be able to list these NFTs on Entrepôt soon and to be able to do so without having to give my code to someone else.

I didn’t have the social media chops to promote an NFT. This thing has become a bit of a profession. You’ve got to be able to work discord, twitter, telegram, and to do so with flair. Congrats to the folks that have made it work. It is hard.

I’ve got a discord here if you want to talk about this stuff any more: ARAMAKME

Or leave comments below and let’s talk about how we can build more tools for developers to control how they make money with their software.

From an ICDevs standpoint, we’ll just encourage conversation around this topic. If the library is useful and people use it we’ll use the cycles generated for the benefit of the community. If the licenses mature and become a standard we’ll help oversee it and organize a healthy debate about what should, shouldn’t, and needs to be in the licenses.

It was a fun project and I wish life had given me the space to lean in when all the NFT craziness was going on. AMA

14 Likes

This is pretty cool. There are so many hidden gems in the forum. I suppose that this would for rust as well…the licensing philosophy, that is.

1 Like

Yes…I’d love to have a rust version as well. It should be a fairly straightforward port…I just don’t know rust!

1 Like

I believe that cycle sharing could be a revolutionary new business model, @skilesare, myself, and others seem to all be coalescing around this idea. That being said, my first impression of the aramakme project was that it was far too complicated…hopefully we can slim things down and simplify them moving forward.

For example, Azle is using a concept I call Intellectual Property Tokens. It’s quite simple to start with, using just the MIT license without modification (or with one slight modification, depending on how you think about it). The trick is to assign copyright to the Azle token holders. See the live license here: azle/LICENSE at main · lastmjs/azle · GitHub

Adding some kind of cycle sharing on top of a license is a whole new challenge entirely. I’ll be iterating with Intellectual Property Tokens and possible cycle sharing, I hope others will continue to experiment.

2 Likes

I admit I’m not too familiar with what “cycle sharing” means, but I’m interested.

Can you explain who is sharing cycles with whom, and under what conditions?

WRT Aramakme, I guess I was confused about the part where the library code keeps track of how many times you call its functions and then automatically charges $1 in cycles after hitting a certain call threshold.

Can’t I just remove that code from the library? Library users probably don’t want to pay that. I guess that would violate the license, but who would enforce it? AFAIK open source licensing still requires enforcement in the courts (i.e. meatspace).

Personally, I think smart contracts have the potential to revolutionize open source funding without resorting to legal enforcement in meatspace. How does that look in practice? No idea, but retroactive public goods funding and decentralized crowdfunding (see Overchute) seem like important first steps to achieving that.

Sure…the original thought was that code users would pay code developers cycles for the use of the code that was developed. Take a developer that wants to build some encoding libraries that work well with the IC. They could form a company, get investment, write the code, hire salespeople, market the library, write licensing contracts on a customer by customer base…etc. Or they could publish the code with a cycle share style license and then anyone can use that codec as long as they pay the cycle cost. So if they want to charge $1 per 1000 encodings, they can do so. It is just SaaS that runs on cycles and the IC. Some people really don’t like this idea, but as a developer, it seems like a really frictionless way to get people to use my code and get compensated at the same time. They can even blackhole the cycle manager contract if people are worried about them “rug pulling” the license so that no one can ever do that.

If you are charging users for cycles then this could be calculated probabilistically, or it could be metered. With this I basically just said, at the beginning of the month send me a buck and then after every 100,000 *1.1(volume checks this month) send me a buck. Also because of the way the IC work, you can only meter update calls which is either a feature or a bug…I haven’t figured that out yet.

The even better thing with the IC is that this ‘just works’. The library owners publish the stats and config of the library and if you import it into your project it as just as if a new entry was added to the cycle use table. When your code is used, a counter ticks up and then after a threshold, the cycles are sent. There is no config or billing…just keep an ample cycle balance.

Yes…you could remove the code and break the license. If you had an open-source project and it was running on the IC then the NNS would have to be used to try to enforce the license. Would that work? No idea. But if you never published your code it would be really hard to check.

This is just the way things like twilio and AWS work. They meter your access and charge a higher rate for things that they consider their IP that add value. You use them if they fit your budget and find a different solution if they don’t.

The “who” you are paying here with this license is interesting. There is no reason it couldn’t be a DAO. If a DAO published code like this, would people be so adverse to it? The idea I had in my head was that users who had a common goal would form a DAO and raise money to get the code written. That DAO would elect to do dole out the money too and each contributor to the DAO would get tokens for the DAO. When the resulting software was published, the users would pay the pre-published rates of cycles to the DAO and they would either be released to DAO members in proportion to their holdings or reinvested into new features for the codebase.

This is just public goods funding where “value = uses”.

The core principle behind the concept of retroactive public goods funding is simple: it’s easier to agree on what was useful than what will be useful - Vitalik

What better way to determine the value of something to the public than by paying for its use as it is used? The reason this is so complicated on other chains is that you don’t have the scalability of the IC. The IC has the power to trivially keep track of what has been called and only make the Xnet call every so often.(Some people are very angry about the code that does this in the original library…and it certainly is ugly…but it is possible!..thus the example code). I tried to come up with a system where the library had to declare their rates beforehand so that users would know what they are getting into. I guess that could be managed by a DAO as well as the code likely loses some value over time.

1 Like

Thanks for taking the time to explain this in detail! Personally I think this is the exact way to market software from an individual developer’s standpoint. Additionally i believe this can be used(as I have mentioned before) in content streaming as well. No other chain provides this flexibility.

If people get angry, well, they choose what offends them.

1 Like

This is just the way things like twilio and AWS work. They meter your access and charge a higher rate for things that they consider their IP that add value. You use them if they fit your budget and find a different solution if they don’t.

I think the fundamental difference is that in the case of AWS you are using a service that is provided by code running on their servers, so they can easily gate it.

But in this case, you’re trying to gate a service that is provided by code that runs on the user’s machine. Even if that machine happens to be an IC node, I don’t know if it’s possible (or desirable) for the IC to enforce that some wasm module makes certain calls to a certain canister. If that machine is instead an end user’s mobile phone, then I don’t see any way to enforce it.

It’s definitely an interesting idea. I think open source funding as we know it today will undergo massive changes (in the direction of tokenization), but I’m not sure this is the final form it will take. Just my two cents.

EDIT: Financing static source code is one thing, but financing running software services is another. I see the latter as an area where blockchain can make a more immediate impact (e.g. SNS, public compute infrastructure, etc).

1 Like

I don’t think any economic rent should be extracted from code. This seems like an extremely regressive step.

We should be creating the building blocks of the future of the IC here, unencumbered by licensing.

2 Likes

Genuinely interested in knowing. Where do we, then, stop? Should content(video , music) also be unencumbered by licensing? Should NFTs?

How do we draw a line? Why shouldn’t all labor be rewarded in creating the eco-system AROUND IC? Why is software different?

Do you guys have vague ideas how a decentralised system could enforce the licenses instead of relying on goodwill or governments? Would be nice to brainstorm about that.

Identity seems to be the missing piece to so many use cases. Once it’s costly to create another online/on-chain identity for yourself we could start working on online reputation around the identity. Maybe you could then call out others for using the license without paying for it, which would result in some sort of reputation loss.

But of course solving identity is this huge, crucial problem that is hard to tackle. The NNS could bootstrap it by incentivising people to attend people parties but that is really not something that works now. I’m looking forward to it though.

I would say in many ways the main key advantage that governments have over blockchains is that they can clearly identify us and use punishment mechanisms to disincentivise undesirable behaviour. One form of that is to harm our reputation, in my country if you don’t pay a bill someone can publicly accuse you of not having paid. Governments can even physical punishment in the form of prison. If the government is well designed these punishment mechanisms are used for the greater good.

It’s hard to solve these problems without such punishment mechanisms…

I bought one, but lately I no longer see it in my plug wallet. I go to https://hwqwz-ryaaa-aaaai-aasoa-cai.raw.ic0.app then login and transfer to stoic, but it’s not working :slightly_smiling_face:

They should be showing up on plug. Stoic is waiting on the merge of the CAP functionality(hoping this week). In the meantime, you can transfer by logging into the main site with stoic and send it back to plug.

1 Like

I updated the Candy library to v0.1.3.

I have refactored the files into separate libraries to silo some of the functionality.

type.mo - holds most types and few conversion functions to stabilize/destabilize candy values, properties, and workspace types.

conversion.mo - holds most of the conversion functions

clone.mo - has some clone functions for deep cloning classes

properties.mo - property and class functions for updating and manipulating classes

workspace.mo - useful for keeping workable data in chunks that can be moved around canisters.

I also wired up a dfx and a test runner, although there is only one test.:flushed:

1 Like

Hey, I was trying to look at the candy library but the link you posted TLDR, says page not found. Is there another link?

The example stuff moved to here: candy_library/Example_Aramakme_License at main · aramakme/candy_library · GitHub

The main library had all the license stuff removed and changed to MIT.

1 Like