Skip to main content

Show HN: An API for CO₂ Removal https://ift.tt/LurbWUI

Show HN: An API for CO₂ Removal Hi all, We're Fabienne and Ewan of Climacrux. Today we're proud to launch our latest project to try and make carbon dioxide removal as accessible as possible: CDR Platform [1]. In short: it’s an API to connect to a portfolio of carbon removers. You can purchase from as low as a single gram and select from both natural and technological removal methods. Longer: A couple of years ago we launched an alternative to carbon credits, Carbon Removed[2], designed for individuals to buy and subscribe to CDR. But we always had the nagging thought that there was more that could be done. CDR Platform is our foundation for that - a simple API to get prices and purchase (at the moment). Our plan is to become the Stripe of the carbon removal ecosystem, seamlessly connecting the supply to the demand. We’d love to hear your feedback. Do you see a use case for this and would you use it? What features have we missed? Do you understand what we’re doing and if not, what’s unclear? We’d love to hear from you.[3] Many thanks and happy hacking, Climacrux. P.s. If you are a carbon remover, send us your prices, life cycle analysis and some more information about your removal timeline. Our aim is to bring your services to a wider audience so you can focus on reducing our CO₂ levels. Thanks for your work! [1] https://ift.tt/njPyLfD [2] https://ift.tt/XKipVh1 [3] ewan@climacrux.com https://ift.tt/njPyLfD November 11, 2022 at 12:07AM

Comments

Popular posts from this blog

Show HN: TypeScript query builder with full type inference https://ift.tt/xZp9HOm

Show HN: TypeScript query builder with full type inference Hey HN! Colin here - a TypeScripter, open sourcer, and engineer at EdgeDB. As the creator of Zod and tRPC, I'm interested in designing tools/APIs that use type inference and generics to make life easier for devs. This query builder represents another step in that direction. We set out to build an EdgeQL query builder that can express queries of arbitrary complexity (EdgeQL has feature parity with SQL, roughly) and infer the static type of the query result. We introspect the database and generate a schema-aware client that represent any query, including ones that use built-in functions, operators, string/array/tuple indexing, aggregations, conditionals, type casting, subqueries, computed properties, etc—things most ORMs can’t represent. This post mostly discusses the API design, which I think will be interesting regardless of familiarity with EdgeQL. I’d love to see some of these ideas bleed into future generations of TypeSc...