search

tjl-dev / npass

nPass - Nano based tokens for web access
https://npass.dev/npass
7 stars 3 forks source link

New Design Proposal #17

Open kelepirci opened 2 years ago

kelepirci commented 2 years ago

Current nPass use of XNO (Formerly known as Nanocurrency) is quite ingenious. The design and implementation must be acknowledged and appreciated. :) @tjl-dev.

I was thinking about transforming nPass into a completely feeless and fast smart contract L2 network. Then found something similar was done by the IOTA Smart Contract Chain (https://v2.iota.org/). But unfortunately, it is not completely feeless. According to sources, it is "Almost Feeless".

I propose to launch L2 Smart Contract Network by utilizing BlockchainDB (https://github.com/bigchaindb/bigchaindb) and nPass.

Most of the heavy lifting will be carried by BlockchainDB. Since nPass has already solved the anchoring between XNO and internal token, we only need to deploy the L2 Smart Contract Blockchain to store the token in a distributed in immutable fashion. nPass team can create a new implementation that will work with new L2 Smart Contract Chain.

After proper implementation, we can utilize XNO as follow in the completely feeless way:

Any thoughts?

BlockchainDB is the open-source project that is behind Binance Smart Chain. So I do not see any performance problems but am not sure about true decentralization.

tjl-dev commented 2 years ago

Interesting idea. Ideally token verification would be performed independently of token generation and use a standard protocol with clients embedded into individual services, so I wouldn't need to run a centralized service for it. Using a decentralized database to persist tokens might also be a good idea, but would necessitate an extra step in the protocol to for the content server to verify the token belongs to the requesting user.

kelepirci commented 2 years ago

Good to hear from you @tjl-dev

Ideally token verification would be performed independently of token generation and use a standard protocol with clients embedded into individual services, so I wouldn't need to run a centralized service for it.

I am with you on this matter. I would not like to have any centralized solution to solve this problem or any other problem.

My original idea was to use the NANO blockchain to persist the token. That way tokens would be persistent across all clients. This persistent token could be verified easily by utilizing the NANO blockchain (nPass is already doing something similar).

As you may have already known; storing extra data in the NANO blockchain is not aligned with the NANO blockchain prototol. NANO blockchain is only interested in value transfer (I am 100% pro to this idea). That is why it is not possible to implement features like NFT or any other feature that requires extra data/metadata fields. I think it is not possible to add extra data/metadata fields without sacrificing speed and scalability. I believe that is the main reason why IOTA has launched L2 chain to implement the popular features to the L1 network without sacrificing L1 network performance. Anyway, this subject is long, and let's get back to our original idea.

Using a decentralized database to persist tokens might also be a good idea, but would necessitate an extra step in the protocol to for the content server to verify the token belongs to the requesting user.

With this new approach of L2 blockchain network, the webserver will become another client of both L1 (NANO) and L2 (NEW blockchain) networks. The client (now both user client and webserver client) can access both networks for any sort of verification or other functions. We must keep L2 network as small as possible and rely on L1 network as much as possible. Only data that should reside in L2 network must be minimal. In this case, we should only keep the token and token ownership data/metadata in L2 network. Since the token will reside in public blockchain space, we may need to take the extra steps to secure the token. I am not 100% sure about how this should work properly. But I am positive that nPass is already doing this on the user-client-side.

I think tokens are only stored on user-client so it is relatively secure. With that token, the webserver is issuing JWT token to the user for accessing the content. Please correct me if I am wrong. If we store the token and token ownership on L2 network, we can easily verify the client has the right to access the content (in this case; if the NANO account has the right to access the content).

If we can launch and implement the above feature, it would become our base to implement other distributed features. (By the way, we can call this new feature distributed fungible token :smile: )

tjl-dev commented 2 years ago

Thanks, I think the idea has a lot of merit. If we can move the token persistence (encrypted) to a decentralized L2 network/DB, and standardize the access protocol for wallets and content servers, the benefits would be greater trust and probably easier integration for content providers.

I don't know a lot about bigchain and will need to do some further reading, hopefully over the end of year break.

On Wed, 22 Dec 2021, 2:33 am Ferhat Ozkasgarli, @.***> wrote:

Good to hear from you @tjl-dev https://github.com/tjl-dev

Ideally token verification would be performed independently of token generation and use a standard protocol with clients embedded into individual services, so I wouldn't need to run a centralized service for it.

I am with you on this matter. I would not like to have any centralized solution to solve this problem or any other problem.

My original idea was to use the NANO blockchain to persist the token. That way tokens would be persistent across all clients. This persistent token could be verified easily by utilizing the NANO blockchain (nPass is already doing something similar).

As you may have already known; storing extra data in the NANO blockchain is not aligned with the NANO blockchain prototol. NANO blockchain is only interested in value transfer (I am 100% pro to this idea). That is why it is not possible to implement features like NFT or any other feature that requires extra data/metadata fields. I think it is not possible to add extra data/metadata fields without sacrificing speed and scalability. I believe that is the main reason why IOTA has launched L2 chain to implement the popular features to the L1 network without sacrificing L1 network performance. Anyway, this subject is long, and let's get back to our original idea.

Using a decentralized database to persist tokens might also be a good idea, but would necessitate an extra step in the protocol to for the content server to verify the token belongs to the requesting user.

With this new approach of L2 blockchain network, the webserver will become another client of both L1 (NANO) and L2 (NEW blockchain) networks. The client (now both user client and webserver client) can access both networks for any sort of verification or other functions. We must keep L2 network as small as possible and rely on L1 network as much as possible. Only data that should reside in L2 network must be minimal. In this case, we should only keep the token and token ownership data/metadata in L2 network. Since the token will reside in public blockchain space, we may need to take the extra steps to secure the token. I am not 100% sure about how this should work properly. But I am positive that nPass is already doing this on the user-client-side.

I think tokens are only stored on user-client so it is relatively secure. With that token, the webserver is issuing JWT token to the user for accessing the content. Please correct me if I am wrong. If we store the token and token ownership on L2 network, we can easily verify the client has the right to access the content (in this case; if the NANO account has the right to access the content).

If we can launch and implement the above feature, it would become our base to implement other distributed features. (By the way we can call this feature distributed fungible token 😄 )

— Reply to this email directly, view it on GitHub https://github.com/tjl-dev/npass/issues/17#issuecomment-998877225, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADFXBKFDNJNSEIPYNTFDVS3USCM5VANCNFSM5KOZZXJQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

kelepirci commented 2 years ago

I have a broad idea of how to secure the token in L2 network. Before I start throwing some empty ideas around, it would be good to brush up on my NANO protocol knowledge and learn more about BichainDB/BlockchainDB. :smile:

While learning BlockchainDB, I will be launching a test network. I will share the details with you. But on other hand it is also possible to launch a test network with docker-compose in your own local env.

I have created a Discord for nPass. Please do not hesitate to join: https://discord.gg/Grjb9fmB