Background: At dClimate we want to make Climate DeSci easy. The way to do this is by giving people access to tools they are used to using while abstracting away all the "complicated stuff". Most of the time it's hard to get people to get into their Terminal and install Git let alone Kubo(IPFS), provide instructions support for cross platform support etc. In the case of DeSci, one of the most important tools for scientists is a Jupyter Notebook for running python code easily. Coupled with IPFS it can demonstrate the value of DeSci. At dClimate we created a mini curriculum of sorts in a repo that can be found here https://github.com/dClimate/jupyter-notebooks which bundles IPFS and Jupyter into the same Docker container, this way the end user doesn't need to worry about their global python version, venv, package managers etc. Things "just work". What's more is that not only can the notebook be run locally via docker compose (scientists won't installed docker, that's a dropoff point already), it can be essentially one click launched onto Railway (a very easy to use PaaS) without any frills. In other words, you can launch a Jupyter Notebook which accesses data via IPFS without being too technical. You can launch it on Railway using this template here https://railway.com/template/4Xk-zm?referralCode=ciD76B (IMPORTANT: After deploying the template you must tap the jupyter-notebooks service box, go to the settings page, select TCP Proxy under Public Networking and pick the 4001 port which maps to IPFS. You can only pick one proxy, you will be randomly assigned a domain name and a port which maps to the port you selected. You must then click the three dots on deployments and redeploy so that the TCP proxy takes effect.) Screenshot 2025-03-18 at 1.26.36 AM Problem: On either Railway or running locally, the IPFS node in the notebook (101 - Getting Started.ipynb) can access and swarm connect to other running peers. This also means data can be queried from these peers or the wider ipfs network. So far so good.

When designing the routing system for a web application that supports both native password authentication and OAuth social logins, you should consider the various steps involved in each authentication process. Here's a sample route setup: Native Password Authentication:POST /signup: This route would handle the creation of a new user account. It would accept a payload with username and password, perform validation, hash the password, and store the user in the database. POST /login: This route would handle user login with username and password. It would validate the username and password, compare the hashed password with the one stored in the database, and if they match, create a session or return a JWT token. OAuth Social Login: GET /auth/{provider}: This route would initiate the OAuth process for the specified provider (e.g., GET /auth/google, GET /auth/twitter). It would redirect the user to the provider's login page. GET /auth/{provider}/callback: This route would handle the callback from the OAuth provider. The provider will redirect the user to this route with an authorization code in the URL. This route would exchange the authorization code for an access token, retrieve the user's profile information from the provider, and create or update the user in your database. After this, it would create a session or return a JWT token.