HN user

sbauch

22 karma
Posts24
Comments34
View on HN
cryptorchids.io 5y ago

Show HN: CryptOrchids – an Ethereum based game to keep finicky flower NFTs alive

sbauch
2pts1
www.thenifty.com 5y ago

CryptOrchids: The NFT That Dies If You Don’t Water Them

sbauch
3pts0
mtruyens.medium.com 5y ago

SSO for Serious Startups

sbauch
2pts0
ossoapp.com 5y ago

SAML on Rails: How to Implement SAML SSO in Rails 6

sbauch
3pts0
github.com 5y ago

Show HN: Osso – Open-source SAML SSO service

sbauch
41pts56
ossoapp.com 5y ago

Implement SAML SSO in a Rails App

sbauch
3pts0
ossoapp.com 5y ago

All About Identity Providers: The ABCs of IDPs

sbauch
3pts0
www.textrecs.com 11y ago

Show HN: Bar Recommendations by Text

sbauch
1pts0
medium.com 11y ago

A Twitter Ads Hack to Get a Twitter Interview

sbauch
2pts0
medium.com 11y ago

3 Mobile Trends Creating Mobile Opportunities

sbauch
2pts0
itunes.apple.com 11y ago

Show HN: Tunedup – discover new music with stacks of tracks at your fingertips

sbauch
1pts0
library.deweybird.com 12y ago

Hacking Spotify into Twitter for Fun and Profit

sbauch
1pts0
library.deweybird.com 12y ago

How To: Instagram Content in Twitter Cards

sbauch
1pts0
www.feedtarget.com 13y ago

Show HN: FeedTarget - scaling targeting and context for Facebook content

sbauch
1pts0
fomosqr.com 13y ago

Show HN: fomo - a foursquare connected app

sbauch
1pts1
blog.bigleaguefantasy.com 13y ago

Why We Reward Users for Signing Up with Facebook (and not Twitter)

sbauch
1pts0
www.bigleaguefantasy.com 13y ago

Show HN: Big League Fantasy - Fantasy Football for the Social Web

sbauch
8pts11
news.ycombinator.com 13y ago

Ask HN: Rip out Twitter integration that uses find friends functionality?

sbauch
1pts3
news.ycombinator.com 14y ago

Ask HN: review my project: Big League Fantasy

sbauch
2pts0
sammybau.ch 14y ago

Is this an algorithm? Rookie programmer goes a bit beyond CRUD

sbauch
1pts0
news.ycombinator.com 14y ago

4 Months with Rails - Launching My First App

sbauch
7pts5
www.solvate.com 14y ago

When is a startup fundable?

sbauch
2pts0
www.solvate.com 14y ago

How to Communicate Effectively with a Developer

sbauch
2pts0
www.solvate.com 14y ago

Startup Biz Dev Strategies

sbauch
2pts0

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:

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!

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.

Perhaps. Let's use plain English as neither of us are lawyers.

Allowed:

Deploy your own Osso instance and use it in applications you own and operate.

Not allowed:

You use Osso to start a business where your primary business is in helping other companies implement SAML SSO in the applications they own.

If that's not what our license says then we will change the license text.

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.

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 didn't mean for you to take my comment as a guarantee, but if you're more than curious I'd have your counsel read the license, as we are under the impression the use you describe is well within the rights granted by the current license. Put another way, do you consider Sentry "open source"?

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.

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

So the intent of the license is to prevent copy-cats from using Osso's source to run a competing business. We certainly intend for you to be able to authenticate external customers in a SAAS app. IANAL but the license text hsa been vetted by an attorney.

Is our intent with the license enough for you to consider it appropriate for us to call this open source?

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!

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

Thanks so much for the kind words!

The pricing here is definitely more applicable to Auth0 :)

But for us, charging per user makes predicting the cost of your SAML provider difficult, and everyone seems to do this. We charge per customer account instead - if one of your customers has 50 MAUs it wont cost you more than a customer that has 10. And you won't need to pay us more is your software is a daily driver vs. something thats used lee frequently.

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.

FWIW, We're big fans of Sentry's explanation of the BSL license - https://sentry.io/_/open-source/

Thanks so much!

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.

Hey HN! We're Sam, Sam, and Michael, the founders of Osso (https://ossoapp.com/)

Osso is open-source software for integrating SAML SSO with any web application. It provides an Admin UI to onboard your customers, generates custom documentation to configure your app in a customer's Identity Provider (IDP), handles SAML authentication against IDPs and provides your app normalized JSON profiles as part of an OAuth 2.0 code grant authorization flow.

We started working on Osso together as a way to keep in touch and distract ourselves from, well, *gestures broadly at everything*. We chose to work on something that each of us came up against during our careers: supporting SAML SSO. Between the three of us, we've built internal tools where SAML was required by IT and struggled to sell SaaS products that didn't offer SAML SSO to enterprises who required it. We've also been users of various IDPs, limiting us from accessing the apps we wanted at work when they only included SAML SSO on the way-too-expensive Enterprise plan.

Every successful SaaS company builds SAML SSO eventually but it's never a top priority and nobody takes time to really understand it. If your customers want SAML, it's a great problem to have but chances are there are thousands of other things on your list. Most teams end up kicking it down the road, which can lead to lost sales opportunities. Companies end up piecing something together that kind of works but creates technical debt or support burden, or they spend thousands of dollars on Auth0 or AWS Cognito, but still lack customer docs or a streamlined flow for SAML onboarding.

So we're trying to simplify things for SaaS companies to make SAML SSO a more accessible option. We took existing open-source software and added the last 10% to make integrating a scalable, sellable, and serviceable SAML SSO solution as easy as possible. All the code is available on Github for you to run on your own, but we also offer a SaaS solution where we'll manage an Osso instance for you.

Osso:

• Treats SAML like OAuth - connect your app to an Osso instance via OAuth, and Osso will handle the SAML authentication and return normalized JSON profiles

• Enables first class support for Azure Active Directory, Okta, OneLogin, Ping, Google, and Salesforce, yet works with any IDP that supports SAML 2.0

• Features an Admin UI for customer support / success teams to onboard and support customers

• Provides a convenient interface for technical teams to create and roll OAuth clients and their secrets

• Generates custom PDFs for step-by-step onboarding for each of your customers

If you're interested in learning more, start here:

— Our docs [https://ossoapp.com/docs/quick-start]

— Github repos [https://github.com/enterprise-oss]

— Quick video walk-through of Osso [https://youtu.be/Jps3eeZGOr0]

— Demo instance [https://demo.ossoapp.com]

The back end is a few modular Ruby/Rack apps including a GraphQL API and an OAuth 2.0 server, while the front end is a React app written in Typescript. We use a modular and package driven approach, allowing you to customize your Osso instance with theming or middleware, or pick and choose parts of the stack to use, while getting critical updates through our Ruby gems and npm packages. We offer client libraries for Ruby (omniauth-osso) and NodeJS (passport-osso), and are working on React components you can use to interact with your Osso instance, like a login component and a widget to allow your customers to configure SAML themselves.

We really appreciate the HN community and the discussion that takes place here, so we hope you'll provide honest feedback on Osso. What's missing? What should we do differently? Anything you'd take away? We look forward to reading and responding to your comments, but if you want to speak with us directly you can also email us at hello@ossoapp.com.

Thank you! Sam, Sam, and Michael

https://vcardme.com

My current side project is Vcardme. It's a service for hosting your contact information at a URL where it can be accessed or saved. Idea being you should put your Vcardme URL in your email sig.

For me, what really makes it awesome, is the iOS app that allows you to save Vcardme links to your iOS phone book and also subscribes you to updates for the contacts you saved. So your iOS Contacts would stay up to date, automagically.

Just hacking around with the foursquare connected apps platform. Also uses the explore endpoint to surface a recommended venue. All in all, the foursquare platform is a real breeze to develop with, and I'm surprised I haven't seen more connected apps. Looking forward to the Nov 3rd hackathon!

I've come across Football Verdict before, love the clean design! I'm definitely having trouble explaining how the game works in few enough words for a landing page, so fair critique there.

This is a one man side-project, so I wish I could have launched sooner, but I'm just happy I got it out the door before the season started.

Let's definitely connect - I'll reach out!

To clarify, I'm certainly not approaching this from a personal ethics standpoint. It is I suppose a question of social service authentication elasticity. Will removing twitter at the outset significantly reduce my sign ups to the point that it would be smarter to deal with the repercussions of losing API access in the future? Or are most users not so sensitive to which service they use to sign up for something, such that if facebook is the only option, I can guarantee a consistent experience for all users going forward?

Absolutely agree about realtime. Just ran into this issue. Relative timestamps on content that is live updated gets stale immediately. The user has to refresh the page to get an accurate timestamp, which sort of defeats the purpose of the realtime content. So we switched to absolute.

I learned html in middle school (2000-2001?) and have always been semi-comfortable with it. CSS too, which I also brushed up on for BadNYCapartments.com.

And I definitely need basic HTML skills for my day job for html emails, things like that.

But this was a whole different ballgame!