Before you dismiss CryptOrchids as not technically interesting, please believe that’s how I feel about most projects in the NFT space, and I set out to create something unique, clever and only possible because of blockchain technology.
NFTs got a lot of mainstream attention recently and I couldn’t get excited about the space, despite feeling like collectibles are right up my alley. So I did a deep dive, started playing around with Solidity, and came up with CryptOrchids as a fun, small project I could build to learn more.
CryptOrchids are flowers that grow on the ethereum blockchain as ERC721 tokens or NFTs. When a CryptOrchid token is minted, it starts off as a seed.
A seed owner can germinate their seed, which calls a function on the CryptOrchids smart contract that makes a request to Chainlink VRF, a service that provides verifiably random numbers. The contract uses that random number to determine the species of the flower according to an n per 10k scale for each of the 10 species in the CryptOrchids genum - the Shenzen Nongke orchid is the most sought after species, germinating at a 1 in 10k seeds rate.
Germinating a seed starts the game - CryptOrchids are extremely sensitive and must be watered exactly every 7 days, within a 3 hour window.
All of the gameplay mechanics are stored on chain - when a seed is germinated, the contract stores the block timestamp as the plantedAt for the token. Each token also has a waterLevel integer, and we can then do math to determine if a particular plant is alive or dead.
A plant will be considered alive if it’s water level is equal to the number of complete growth cycles the plant has been alive, which looks something like this:
To give players a bit of slack time to water their flower, we provide a 3 hour watering window. So we can express that this way, where if the watering level is 1 less than fill cycles, but the modulo is within the watering window, the plant is still alive:
The result is a very simplified way to express the essence of a plant on the ethereum blockchain. Of course real world plants also need sunlight, and nutrients, and they grow different sizes and have things like reproductive cycles.
But from an ontological standpoint, I’m trying to move beyond 2D posters and more towards metaverse objects that behave like their real world counterparts. The contract also stores latin species names on chain, and the species are all real species found in the natural physical world.
Where I’d really like to take this project is to metaverses as 3d objects that owners can water inside the metaverse. I’ve started playing with the Decentraland SDK. It’s not much, it’s not earth or metaverse shattering stuff, but that’s the direction this is all going, and I’m super excited to be trying to make this happen. I can’t wait to be able to own a digital car, to race it in a racing universe, to use it for transportation in an RPG metaverse, or to auction it at a Mecum auto show in a metaverse. But cars are a lot more complex than plants, so I started here.
There’s a great little community popping up around the project, and there’s a lot of interesting social and gaming dynamics that are coming to the fore as people start to engage with the idea. Some have compared the game to Tomagotchis, which feels like a really nice compliment.
It’s been a really fun intro to Solidity, Ethereum and NFTs, but to be clear this is experimental and I while I wrote tests and QAed on Rinkeby extensively, I’m sure there are things that I don’t understand about Ethereum that may cause things to break down over time, so I’m very open to learning what naive mistakes I may have made here!
The other industries you mention have gone through similar changes though haven't they? Not long ago, "idiot", "imbecile" and "moron" were all terms with strict definitions in the field of medicine. Languages, terms that are strictly defined, even terms that are particular to a science or industry, evolve over time.
Thanks, we'll review this and other folks' comments and see if we can make a change that works for us and maintains an OSS ethos. This is our first launch FWIW, we're appreciative of the feedback but clearly seemed to have ruffled some feathers
We don't have definite plans to build a full-featured IDP, but we did build a Mock IDP we use in CI, QA and demos that could possibly be a starting point for your purposes? Other OSS IDPs include Keycloak and Gluu Server if you wanted to check those out!
Frankly we're using existing open source to handle this - we use ruby-saml which is maintained by OneLogin for the SAML parsing, but we also wrote a little ts parser for federated metadata files - https://github.com/enterprise-oss/osso-react/blob/main/src/u...
Thanks so much! We're super confident in the 6 IDPs we've built first class support for. But we also know that there are sure to be edge cases we haven't totally caught, we're still a bit early. But at least we can catch those across our customer base, as opposed to you finding them ll in your one-off SAML integration.
We have to really manually test real IDPs, and we do whenever we release new software, but we also run e2e cypress tests against a Mock IDP we built, so SP -> Osso -> Mock IDP -> Osso -> SP, you can see these in our Buildkite CI - https://buildkite.com/enterpriseoss/osso
Certainly a fair critique, and one we can admit we saw coming.
We currently use the BSL license, created by MariaDB and used by companies like Sentry. We do think Osso is open source by common understanding and view the BSL as a fair model that places no restrictions on good actors - the license is intended to protect us from copycats profiting off our work, while allowing anyone that needs to integrate SAML into an app they’re building free reign. You’re free to use Osso as a widget, but you can’t use it to start a widget factory.
"Source available" seems like a fair compromise, thanks for the suggestion.
> "We do think Osso is open source by common understanding and view the BSL as a fair model that places no restrictions on good actors - the license is intended to protect us from copycats profiting off our work, while allowing anyone that needs to integrate SAML into an app they’re building free reign."
The common understanding of open source is that source code is available, redistribution free, and derivative works are allowed.
MariaDB specifically states that BSL isn't open source:
> "We have not certified BSL as complying to the Open Source Definition by the Open Source Initiative (OSI). However, all source code is available from the start and most of the OSI criteria are met. As long as the software is used within the usage limitations, it’s free to use at no cost."
As I've mentioned or alluded to in other comments, I think "open source" as you describe it is broken and unsustainable, and we're happy to have a constructive conversation about commercially viable open source. But if we can't agree that the definition of "open source", like any word or phrase, can change over time, then I don't think there's much of a constructive conversation to be had. Would you suggest we remove any mention of "open source" from our documentation etc.?
> I think "open source" as you describe it is broken and unsustainable,
Then dont claim to use an open source license. Its just recently people have felt foss is commercially viable. For most of its history people believed that foss was not commercially viable. That's why it was considered a radical view.
You want to have the cake and eat it too. You're trying to ride the wave of goodwill that open source provides without paying your dues. Yes open source makes it harder to be commercially viable. If it didn't, if it only provided benefits, everything would be open source.
> But if we can't agree that the definition of "open source", like any word or phrase, can change over time
If i sold nut free chocolate bars, and then someone died of alergic reaction, to which i responded by saying, definitions change over time peanuts arent included in nut-free, would you accept that?
Yes, words can in principle change over time - but you can't just change meanings unilateral, especially not as part of a false advertising campaign to mislead users into thinking you are something that you are not.
I don't think I've changed the meaning unilaterally, others here seem to agree that the meaning is evolving.
I can concede that we are guilty of wanting the wave of goodwill, but I have a hard time agreeing that this is a bait and switch. And I certainly hope nobody is going to die because we use "open source" instead of "source available".
The part of this conversation that leaves me wanting is that it all seems so positive rather than normative, and doesn't consider the benefits of choosing this license over a closed source product.
Our goals here are to make SAML SSO more accessible and run a business that helps some good customers use the software we've created. There's a lot of net positives in that IMO, and this whole "but it's not ACTUALLY open source" is a distraction borne of inflexibility and a lack of creativity.
So how do we as an industry move forward in a way that allows individual use of source available software, but prevents companies from unfairly profiting off of that? Is that desirable? What do we call that? Maybe business source, maybe source available is fine. That's a lot more interesting of a conversation to me. If you won't have that conversation until we strike open source from our website I understand.
> There's a lot of net positives in that IMO, and this whole "but it's not ACTUALLY open source" is a distraction borne of inflexibility and a lack of creativity.
Being "flexible" and "creative" with the truth is just a fancy way of saying lying.
Are you seriously arguing the ends justify the means, where the end is some cloud saml business and the means is misrepresenting the licensing terms of your product? That's probably the lowest stakes ends justify the means argument i have ever heard and is pretty rediculous.
At the end of the day, if you can't operate your business ethically and with integrity, then no, its not a net positive. This is true for pretty much any business venture, but its especially true for some random cloud offering competiting in a market with many other competitors doing roughly the same thing. The way you talk about this stuff you would think you were trying to solve world hunger.
> If you won't have that conversation until we strike open source from our website I understand.
Why do you think i'm interested in that conversation at all? I have no stake in your company, i don't care how you structure your IP, if you succeed as a company or if you fail. I do however have a stake in the open source movement and care deeply when parasites try to profit off it without fulfilling their obligations to the movement.
> Certainly a fair critique, and one we can admit we saw coming.
So you intentionally made false statements about your product, which you knew ahead of time were false and if believed might conceivably make people more likely to buy it? That's normally called fraud.
The long winded justification doesn't matter. You're under no moral obligation to make your product open source. You are under a moral (and probably legal but ianal) not to do bait and switches.
I don't think we've intentionally made false statements nor committed any fraud. But we appreciate the feedback, we'll review as a team and see what sort of decision we can make that will maintain source availability without upsetting folks who allow OSI to define "open source". We made some mistakes, we're very early, and we were hoping to have a (constructive) conversation around licensing and sustainable open source.
Right on. This kind of thing keeps happening. Fortunately, HN and other communities have a surprisingly sharp eye for these lies and can generally be relied upon to call them out, but people still try it on.
You are absolutely free to use Osso's source to onboard and authenticate your own customers without paying us! The goal of the license is to prevent someone from creating their own SAAS offering that competes with ours. Using Osso for your own app is within rights granted by the license.
But to your point, we also offer a demo instance that you can use in order to build out your integration, and then when a customer comes along, start paying us and swap out some ENV variables and you're ready to go!
A useful framework for thinking about SAML vs OAuth from an engineer's perspective is to think of OAuth as class based, while SAML is instance based.
When you set up a new OAuth provider such as Github you typically grab a Client ID and Secret, specify your redirect URIs, and once your integration is complete any Github user can sign in with a Sign in with Github button.
But with SAML, you need to perform configuration with each customer's Identity Provider instance. As you pull on this thread you start to see where the challenge with SAML lies. SAML as a protocol isn't super complicated, and tons of OSS already exists to perform authentication. But you need to create and persist configuration data for each of your customers, which suggests needing a UI to perform this onboarding. You need to help your customer configure your app in their IDP, so you'll want to create documentation. And you need to adjust your sign in flow - you can't just stick a Sign in With Okta button, you need to ascertain from the user which IDP they use for authentication.
Osso though handles all of the "instance based" challenges, and allows your app to use OAuth to communicate with your Osso instance.
NFTs got a lot of mainstream attention recently and I couldn’t get excited about the space, despite feeling like collectibles are right up my alley. So I did a deep dive, started playing around with Solidity, and came up with CryptOrchids as a fun, small project I could build to learn more.
CryptOrchids are flowers that grow on the ethereum blockchain as ERC721 tokens or NFTs. When a CryptOrchid token is minted, it starts off as a seed.
A seed owner can germinate their seed, which calls a function on the CryptOrchids smart contract that makes a request to Chainlink VRF, a service that provides verifiably random numbers. The contract uses that random number to determine the species of the flower according to an n per 10k scale for each of the 10 species in the CryptOrchids genum - the Shenzen Nongke orchid is the most sought after species, germinating at a 1 in 10k seeds rate.
Germinating a seed starts the game - CryptOrchids are extremely sensitive and must be watered exactly every 7 days, within a 3 hour window.
All of the gameplay mechanics are stored on chain - when a seed is germinated, the contract stores the block timestamp as the plantedAt for the token. Each token also has a waterLevel integer, and we can then do math to determine if a particular plant is alive or dead.
A plant will be considered alive if it’s water level is equal to the number of complete growth cycles the plant has been alive, which looks something like this:
alive? = plantWaterLevel == Math.floor(plantAgeSeconds / GROWTH_CYCLE)
To give players a bit of slack time to water their flower, we provide a 3 hour watering window. So we can express that this way, where if the watering level is 1 less than fill cycles, but the modulo is within the watering window, the plant is still alive:
alive = plantWaterLevel + 1 == Math.floor(plantAgeSeconds / GROWTH_CYCLE) && (plantAgeSeconds % GROWTH_CYLCE) < WATERING_WINDOW
The result is a very simplified way to express the essence of a plant on the ethereum blockchain. Of course real world plants also need sunlight, and nutrients, and they grow different sizes and have things like reproductive cycles.
But from an ontological standpoint, I’m trying to move beyond 2D posters and more towards metaverse objects that behave like their real world counterparts. The contract also stores latin species names on chain, and the species are all real species found in the natural physical world.
Where I’d really like to take this project is to metaverses as 3d objects that owners can water inside the metaverse. I’ve started playing with the Decentraland SDK. It’s not much, it’s not earth or metaverse shattering stuff, but that’s the direction this is all going, and I’m super excited to be trying to make this happen. I can’t wait to be able to own a digital car, to race it in a racing universe, to use it for transportation in an RPG metaverse, or to auction it at a Mecum auto show in a metaverse. But cars are a lot more complex than plants, so I started here.
There’s a great little community popping up around the project, and there’s a lot of interesting social and gaming dynamics that are coming to the fore as people start to engage with the idea. Some have compared the game to Tomagotchis, which feels like a really nice compliment.
It’s been a really fun intro to Solidity, Ethereum and NFTs, but to be clear this is experimental and I while I wrote tests and QAed on Rinkeby extensively, I’m sure there are things that I don’t understand about Ethereum that may cause things to break down over time, so I’m very open to learning what naive mistakes I may have made here!