Tooling: User Authentication Bridge & User Management

Cartesi Grants Program CGP Pilot
1

New proposal

User Authentication Bridge

Unified way to reference User Object in a centralised system and on the Cartesi VM. Helper packages to develop a user-centric system in a standardised way on a Cartesi Rollup. Standardised user management module.

Project Description

Not everything belongs to the blockchain, but modern apps require blockchain components to leverage its security and stability. A blockchain component can provide features not available in web2 applications. Storing everything in the blockchain is inefficient; some of the ordinary components of the web3 application cannot function within the same principles as they would in a centralised environment. Every Contract has to be triggered to invoke actions. For typical web2 systems, a system can trigger itself to do an action because certain external conditions have been met. A synergy between the web2 component and web3 components has to be achieved to deliver a functional web2 system with web3 capabilities. This is why we want to create User Authentication Bridge for the most popular backend solution. Writing a solution, you will be able to safely reference a user and invoke Cartesi Rollup methods from your web2 applications, allowing schedulers and queues to reference a web3 user precisely.

Value proposition

Tooling is very important in modern development. Intelligent IDEs with autosuggestions are a standard nowadays, and referencing Users while developing should be straightforward and standardised. User management is essential to every system, and most of the frameworks out there do have it from the get-go.

How you will use Cartesi, specifically?

The User Authentication Bridge brings user management to Cartesi Rollup Framework and a Kickstarter template for more advanced systems that use web2 and web3 components together.
The solution leverages an SQLite database that can run on the Blockchain OS.

Milestones

Milestone 1: Design and Architecture with a PoC

  • Duration: [2 months]

  • Deliverables:

  1. Research, Snippets
  2. Architecture charts + docs
  3. GUI design for User Management
  4. Scope of work - detailed
  • Funds request (USD) for milestone 1: 4400 USD [80H x 55USD]

Milestone 2: Implementations for 2 Backend Frameworks

  • Duration: [3 months]

  • Deliverables:

  1. Implementation of the bridge in 2 frameworks,
    Laravel (PHP), NestJS(Typescript)
  2. Working GUI and Kickstarter templates,
  3. How-to guides per framework
  4. CF implementation
  • Funds request (USD) for milestone 2: 11 000 USD [200H x 55USD]

Milestone 3: Example Dapps on test-net

  • Duration: [1 month]

  • Deliverables:

2 dapps with user management for different frameworks and tech stacks

  • Funds request (USD) for milestone 3: 4400 USD [80H x 55USD]

Total funds requested

19 800 USD

Use of funds (specific breakdown):

  • Design and Documentation: 60H, 3300 USD

  • Software Development: 220H, 12100 USD

  • Testing, Examples & Deployment: 80H, 4400 USD

About your Team

Kamil Zawadzki - Software Architect
Sabina Francuz - UI Designer / Tester
Karol Pietruszka - Software Developer

Relevant Experience

Links and resources

Website: https://webchefs.tech/
Social: https://www.instagram.com/wearewebchefs/
LinkedIn: Webchefs Software Company | LinkedIn

ERC-20 Payee address

ERC-20 address: 0xcc425d2f6900d6538cdac895896f2ef2a8c53d1f

2

Hello!

I’m not sure I understand what you mean by User Authentication Bridge, would it be a sort of Ethereum Name Service for Cartesi? I’d love if you could give us some more context be a bit more specific about what would be built.

Thinking out loud, something like this could be quite interesting:

Imagine a Cartesi DApp that manages identity:
It creates a connection between an ethereum address and a unique string (joedoe.ctsi, worldOfWarcraft.ctsi, etc). This DApp has two different kinds of inputs: register identity and subscribe.
Register identity is where you create the connection between addresses → string. It can follow the successful example of ENS, it can be an auction, first come first seve, I don’t know. And this identity could support all kinds of things, like reputation system, dapp specific annotations, tags, badges etc

Subscribe is called by DApps that are synchronizing to this database of shared identities. Every epoch, this Identity DApp sends a voucher to every subscribed application updating their internal databases, so people and applications all share the same identities across every application specific rollups. And then we’d need some web2 code that allows dapps to update their identity tables and understand inputs that reference the “ctsi identity”

Anyway, I’d love some for information on what the team is planning to build :slight_smile:

And thanks for your proposal!

2 Likes
3

While developing Cartesi Parking Dapp we can across a problem with user authentication and management. The simplified version of the proposal would be:
User Management Component with GUI and a way of identifying those Users by external entities (web2 apps for instance), a sort of a bridge. What your saying rings a bell. Please remember that I’m coming from a web2 background. Ideally, it would have an SDK for each web2 framework to facilitate rapid development. I think that somewhere in between your reference and my proposal there is a sound component to be refined. I will dig deeper into the link you’ve sent and my vision of the component and I will try to refine it accordingly.

2 Likes
4

Hey there Kamil. Thanks for the proposal. Since we’re aiming to fund projects with potential for reusability by the dev ecosystem, it would be good to know to what extent your architecture will allow for upgradeability/changes to the User Authentication Bridge, to keep up with future Cartesi updates. This will ensure its compatibility with future Cartesi or backend solution updates. How do you intend to handle updates and maintenance to guarantee compatibility? If you’re confident that it can handle these without large-scale refactoring, that would be good to know as well.

5

Hey! We would use abstraction across the codebase to cover fallbacks/upgradability and any changes under the hood. You would still be able to use the method, but the method (code) can change over time. The methods of authentication are quite solidified, so I don’t see breaking changes often. We would also make the bridge configurable to use XXX version of the framework for instance. The first two months would involve close cooperation with Cartesi Team to work out flexible abstractions for the Identity system. The adoption across different web2frameworks can be community-led (i.e. nodejs community-led) if the bridge catches on. We would provide guidelines on how to create and maintain the bridge.

6

At first glance, I find the proposal really interesting and with a lot of potential. I’d love to see more details about why and how Web2 systems would integrate into the service. Should we evaluate Authentication and Authorization separately?

I could ask a few more questions, but I would recommend thinking about making this our Milestone 1 and start exploring the idea.

Before we dive into the technical stuff, it would be great to have a detailed study that explains why we need this decentralized system and gives examples of Web2 applications that would benefit from it (and perhaps why would they want to migrate to this service). We should also consider if it’s feasible from a (crypto-)economic standpoint and think about any limitations blockchain and Cartesi might have that could affect our goals. So again, I would suggest that as Milestone 1.

If Milestone 1 turns out well and we get positive results, it will give all of us the confidence to keep going.

7

@erick.demoura to answer your immediate concerns:

We should consider authentication and authorization separately.
There are a few things to consider:

  • authentication of a user in the web2 application
  • authorization of a user in the web2, two ways:
    • what are user rights within the app,
    • what can the application do on the user’s behalf

how Web2 systems would integrate into the service.

They would use the service as the identity provider. The web2 app would see its users and could act on their behalf to a degree (for instance, by running a scheduler) within provided access rights.
The allowance might be deposit based. As I user, I can see all my apps and access rights.

As for your comment here:

Can I consider a slightly changed definition of Milestone 1 here below as a valid proposal?

Milestone 1: Design, Architecture, Study and Report

  • Duration: [2 months]
  • Deliverables:
  1. Research, Snippets
  2. Architecture charts + docs
  3. GUI design for User Management
  4. Scope of work - detailed
  5. How would web2 application benefit from it - real-world examples
  6. Crypto-economic feasibility
  • Funds request (USD) for milestone 1: 5500 USD [100H x 55USD]
8

That looks fair to me, @wch-kamil. Let’s listen to a few more technical voices from the technical committee on your proposal.

1 Like