Accept a web2 third party auth + web2 payment

General
1

Hello,

I’m currently building an application for web2 users that have nothing to do with crypto at all. The whole stack could be on web2 using normal cloud provider. This is probably an uncommon scenario but recently I’ve been evaluating the possibility of using IC as the backend. The reasons I could potentially see to use IC over a traditional cloud:

  • No infrastructure to handle (vps, dedicated server, k8s, whatever)
  • Price should be cheap (perhaps I’m wrong on this one)
  • Geography replication, almost guaranteed 200ms query call.

While perfectly being aware of constraints such as:

  • Two seconds state update
  • Canister 4gb memory limit. (I still haven’t understood how stable memory works with upgrade and all, I’ll have to do more research)
  • Limited interoperability with web2 (while http outcall are a thing, post request have to be idempotent, which I may be wrong, but this exclude canisters from being normal API citizens)

Correct me if I’m wrong on any of the above and/or think the rational are wrong. The above is also to make it clear that I want my potential customer to have a web2 experience and at no moment they should feel like they’re on IC. The product I’d like to sell is totally unrelated with crypto.

I see 2 main challenges to build a traditional website with auth + subscription (through fiat, not crypto) on IC:

  • Auth. I saw NFID was a thing and it works with google auth. That’s awesome, however, NFID seems to heavy for my use case and so I’d like to implement my own. I would love to hear anyone explaining me how to convert an oauth2 to a principal in a few high level explanation, or simply how NFID managed to do their.
  • Subscription. This is the biggest challenge, I’d like to be able to use service such as stripe or google pay and have the account management in a canister. I probably will have to get my hand dirty and try with a sort of proxy between stripe/gpay and the canister to listen/translate the requests and keep the state accurate on the canister side. And then later try to reduce the proxy as much as I can. Any idea on that is welcomed, be a brainstorm or whatever.

I would love to also hear whatever you think it is a stupid idea to use IC when it’s not crypto related at all or … maybe it is not a bad idea ?

4 Likes
2

For #1 I recommend NFID.

For #2 I would take a look at what @Hazel is building with Quark and what ICME has done with integrating Stripe:

3

Not a bad idea at all.

4

Thanks for the answer, appreciate it.

For #1 I recommend NFID.

NFID is doing too much, it is creating a wallet and all for me as a user, register take a whole 10 sec last time I tried. This is a deal breaker and I’d rather go the traditional cloud way if that’s the only way. The only thing I need is to prove that 1 account is 1 account.

For #2 I would take a look at what @Hazel is building with Quark

I knew they existed however, correct me if I’m wrong, they are a payment solution on IC, to pay with crypto, not fiat.

and what ICME has done with integrating Stripe

Interesting to know this exist ! Is there anywhere I can find how they managed to do it ? Is it really from a canister, or do they host something aside ?

5

I don’t think it’s a stupid idea.

But…
(A) if your app does not need vps, k8s etc, you can literally build a entire functional website through something like AWS Lambda.
(B) storage is not cheap ; byte-for-byte as compared to traditional cloud providers; simply because we replicate on many more servers

(C) Geographical replication…i don’t think that we can really beat AWS/Azures of the world. Just look at the map of deployed nodes…what to do if your user is in Argentina?

In short, figure out one thing that is indispensable to your app (may be Internet Identity?) that is not available elsewhere or hard to do and then see if that one thing is worth it for you to code on IC.

1 Like
6

This thread might also interest you:

1 Like
7

Awesome reply, thanks a lot for the rationals !

A: It would be stateful
B: Storage wise, it will be a few kb/mb per users. I really don’t need a lot of state. I can consider it almost free.
C: You’re right, that’s very fair.

In fact for the last point I was thinking of the web2 solution for hosting I know so far; it’s either your local single instance vps or a k8s cluster at 100$ a month. If only there were a good middle without having a stupid devops cost :person_shrugging:. IC kinda manage to get this position in my eyes.

8

Personally I think that IC has a lot going for it.

Just as you can host a static website on S3 (no infra) with geo replication through caches, you can host a static website on a Canister in IC.

Just with some Javascript wizardry you can turn that static website on S3 into dynamic website (still no infra that you directly need to manage), with similar Wizardry you can convert that static website on Canister into a dynamic website.

The piece of the puzzle, without down into the rabbit hole too much, where IC shines, as much as i understand your requirements (which is not too much understanding), is stateful processing of messages.

But rarely if ever do you need actual hosting of servers in modern cloud world to host websites (even if they are stateful) & your architecture should be hyper aware about it.

1 Like
9

To do your own google auth → principal at this time you have to use a Rust based canister: I can’t remember the specific method at the moment, but there’s a way to use a seed value to create a principal using the Secp256k1 library. I believe they do this in the The Wall dapp (after authenticating signed Metamask messages instead of from the results of an authenticated Google O-Auth). You can check the source code from that project.

1 Like
10

Hi,
We are in a similar situation. I am also building in IC a platform that is web2 for the MVP. My project will transition into web3 and I think that having the IC backend will help when we go to that phase of the project.

  • My backend is in rust, and I think i have figured out the DB migrations and the Stable memory.
  • For auth I have integrated web3auth with firebase
  • For payments, I am still checking options but I was thinking of Stripe. Did you do any research in the topic?
11

I forgot to mention that for the Auth, I am converting the private key from web3auth to a Principal.

12

Any updates on this?

13

The bad news is how hard it was to find rust library for crypto on wasm32-unknown-unknown. They all depends on some random and we don’t have randomness on IC. What I was trying to do was simply to validate the google’s jwt token, which, I don’t think require randomness.

So even though I love internet computer, I wanted to get my stuff done and went web2.0 without trying much further on IC.

However, the two good news:

  1. I believe it should be possible to provide a custom implementation of getrandom. Where I could implement and be sure it’s never used. I didn’t gave some time to try that yet.
  2. Since I went back to web 2.0, I discovered cloudflare worker which I absolutely love and believe they could have a very good use along with IC.

You can think of a cloudflare worker as a tiny stateless function deployed around the world. I’m currently using them for my project. Because they are stateless and most app are stateful at the end, you always end up getting this problem of where should the data be.

Cloudflare themselves offer mutliples solutions such as their KV store (eventually consistent, 60sec max). However imo a kv store remain quite basic, it helps and I’m using to act as buffer in some scenario, it is awesome but it doesn’t replace a full traditional db. So usually you still end up having a centralized server somewhere.

I do have that centralized server to have a state on my app however it’s expensive, can go down, etc. I’m only half sastified with that one but it’s my current options and works well. And this is where I think IC could shine in my scenario and provide that stateful backend that is cheap, scalable and will never go down.

The cloudflare worker here are interesting because they live on web2 and can communicate easily with others service and can talk back to IC. You could think of them as a proxy. Remember here in that scenario, decentralization, no trust and transparency are not values I’m looking for. Oh and I also should note that cloudflare worker run on wasm32-wasi where randomness is available. And I don’t believe that all request should go through cloudflare, but some would and make things easier.

I’m definitively planning to give a second try at some point and reduce the stack complexity to only cloudflare + some canisters.

14

Here’s a possible solution. I’m not sure how viable it is with existing libraries, but there is a way…

2 Likes
15

In many cases, it’s also enough to disable the standard features of the respective crate and only enable the features you really need.

2 Likes
16

You can hook up custom randomness and seed it with randomness from the management canister. We’ve been using a seed of 0s for a bit now in Azle and Kybra, and are in the process of seeding with custom randomness. Here’s some example code:

use rand::{rngs::StdRng, Rng, SeedableRng};

thread_local! {
  static RNG_REF_CELL: std::cell::RefCell<StdRng> = std::cell::RefCell::new(SeedableRng::from_seed([0u8; 32]));
}

fn _kybra_custom_getrandom(_buf: &mut [u8]) -> Result<(), getrandom::Error> {
    RNG_REF_CELL.with(|rng_ref_cell| {
        let mut rng = rng_ref_cell.borrow_mut();
        rng.fill(_buf);
    });
    Ok(())
}
getrandom::register_custom_getrandom!(_kybra_custom_getrandom);

This should allow you to use the rand crate, and the rng does generate random values, but from a seed of 0s.

To add better randomness you can set RNG_REF_CELL with randomness from the raw_rand method on the management canister. Our plan is to set a timer of delay 0 in the init and post_upgrade methods to set the RNG_REF_CELL just after a deploy.

6 Likes