Blockchain Inbox #2
Comments
|
Issue Status: 1. Open 2. Started 3. Submitted 4. Done This issue now has a funding of 27207.1416 BLZ (5510.56 USD @ $0.2/BLZ) attached to it.
|
|
Issue Status: 1. Open 2. Started 3. Submitted 4. Done Work has been started. These users each claimed they can complete the work by 9 months, 1 week ago. 1) developer-piyush has started work. A cross-platform chat client built on Bluzelle, the database for decentralized applications. Learn more on the Gitcoin Issue Details page. |
|
Hi @njmurarka , I have started working on it. Before going any further, I wanted to discuss few things. I have also watched this video Bluzelle. Also regarding extension BlzKeplr, wanted to confirm that is this the extension you are talking about in this hackathon? ---->Keplr Also if it's a strict requirement to use BlzKelr or Metamask will do or it's like BlzKelr can only get our job done? Also I will need your direction and little guidance from your side. I will update you frequently after every 2-3 days by making a commit on my git repo for this app. Also if I want to trouble you anytime for 2-3 minutes, Is discussing at discord is fine? Thanks :) |
We are actually building our own fork for Keplr. So yes, the extension you pointed out is what it is based on. We will hopefully be making it available to you all ASAP and in the meantime, you can try to use Keplr itself (the one you pointed out) to do your development... although the existing one won't talk to our Bluzelle network, but you can use it to at least get the hooks installed. Once our BlzKeplr (we will likely rename it) is out, we will let you know in Discord and try to let you know here as well. Great question about BlzKeplr or Metamask. What is simplest is to support both. To keep things simple for this project, limit it where messages can be sent ONLY via someone's Bluzelle account... as in, that's what pays for and signs the message. The recipient can be another Bluzelle account, or it could be an Ethereum account. The message itself should be ideally encrypted with the recipient's public key (so if the recipient is another Bluzelle account, encrypt with the recipient's Bluzelle public key). The recipient, in turn, when they login, can login with EITHER BlzKeplr OR Metamask... depending on which address they want to check the inbox for. If BlzKeplr, then all their messages can now be decrypted with their Bluzelle private key. If Metamask, their messages can be decrypted with their Ethereum private key. In either case, the encryption and decryption should be possible via the libraries exposed by BlzKeplr and Metamask, respectively. Let us know if you have trouble doing encryption and decryption. We have not specifically tried to do this before, but in theory, it should all work. Discord is fantastic... just ask questions there... good so others can see the questions and answers! Not sure what your question was about React vs GioUI. |
|
Hi @njmurarka , |
|
@mearaj We will extend this out and give you as much time as reasonably necessary to finish this. How does that sound? Keplr has a new version and I think we can help ensure you will be successful :). Please let us know and confirm you can continue working on it. We can support you on Discord directly to make sure it works for you. Thoughts? |
|
Yes, I am continuing working on it... |
|
Issue Status: 1. Open 2. Started 3. Submitted 4. Done Work for 5500.0 USDC (5500.00 USD @ $1.0/USDC) has been submitted by:
|
|
Hi @njmurarka , Approach 1 Approach 2 Cons: In this approach, the messages are still viewable by the app. Approach 3
Please let me know what do you suggest. Thank you :) |
|
A few comments.
Thanks. |
|
Hi @njmurarka , |
|
Sounds good. Will check it out. Note we have a substantial # of items to
review... so please bear with us.
…On Wed, Jul 28, 2021 at 1:43 PM MEARAJ BHAGAD ***@***.***> wrote:
Hi @njmurarka <https://github.com/njmurarka> ,
I have submitted the work but few things needed your feedback. This is the
link BlockChain Inbox <https://github.com/mearaj/blockchain-inbox>. This
repo is private but only shared with you. Please let me know if you want me
to make it Public or want to allow some specific users.
Thank you :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADTCQUHBGJEJYBY5RTLUTDT2BTW3ANCNFSM463JQ5JA>
.
|
Prize Title
Blockchain Inbox
Prize Bounty
$5,500 USD worth of ERC20 BLZ, at time of payout.
$4,000 USD worth of ERC20 BLZ, at time of payout, without message encryption/decryption.
Challenge Description
Bluzelle provides decentralized data services, powered by the Cosmos blockchain. Our services include a key-value-store (CRUD), oracle, and NFT. We are also building toward providing support to EVM (Ethereum Virtual Machine) and Polkadot support for our services. Our bounties reflect our aggressive approach to consistently improve our ecosystem and value proposition.
While the Hackathon has a specific start and end date, we are ok with work continuing after the hackathon, for the chosen winners to finish their projects to our standards.
An inbox that is keyed on blockchain addresses.
Imagine that you need to contact Bob on blockchain X with address Y. How would you do that?
You cannot.
This is a client application that is the decentralized inbox for all blockchain addresses. It would be a responsive (ie: mobile friendly) app that listens for messages sent to any of your registered addresses. So you can receive messages to your BTC, ETH, DOT, ATOM, BLZ, etc addresses.
For each such address that you want to be able to receive messages on (where you are a recipient), all you need to do is "login" with the blockchain address that you expect to receive messages on. For this app, we don't expect any password -- just enter in the address, and you are logged in.
As a sender, for this submission, it might be ok to limit the scope to just our Chrome Extension (it is being called "Curium"), which allows for easy interaction between a web app and a Bluzelle wallet. The idea is to login with your “sender blockchain address” so you can send messages from that BLZ address, and of course, read incoming messages to that BLZ address.
Once you authenticate with Curium, it then can decrypt all messages you received to your BLZ address, but also, whenever you send a message, it can encrypt these messages with the recipient's public key, as a form of privacy. We understand that encryption may be difficult. You can deliver a solution without encryption, and if so, a smaller prize is awarded nonetheless. But if you want to do encryption, the basic idea is to encrypt with the recipient's BLZ public key. They can then read the message when they "login", by decrypting it with their BLZ private key.
The sender does not actually need to have any addresses except a BLZ one, from which they send the messages. All such usage would incur gas costs on Bluzelle to store the data, paid for by the message sender.
Responses to the messages would exclusively come back to the senders “Inbox” on the same app. The Inbox "login" can be any blockchain address, and is not limited to just a BLZ address. So, if the message was sent to someone's ETH address, the recipient can login with their ETH address. Note that outgoing messages can ONLY be sent from someone's BLZ address, but the recipient can be ANY blockchain address.
If you are implementing encryption, the sender would need to encrypt the message with the recipient's known public key. The recipient, in turn, can decrypt the message using their blockchain's own public key, and therefore be able to exclusively read it. The flow, if say a message was being sent to an ETH address, would be for the message to be composed, encrypted with the recipient's ETH public key, stored encrypted to Bluzelle, and then, the recipient, upon login, would be able to read this message by decrypting the message with their ETH private key. The scope of doing this depends on integration of your app's ability to encrypt and decrypt messages and access to the recipient's key-pairs. If encryption too difficult, please feel free to implement the app without encryption.
The messages would take on leases that make sense for the purpose. People can send messages to each other for whatever purpose. Perhaps to initiate a trade or to alert about something. Marketing companies can bombard blockchain addresses of specific interest (like high net worth ones) with ads, etc. Reminder the sender is ALWAYS a BLZ address.
The idea here is “lazy creation”. Bob from chain X does not have to go and “sign up” for an "account" to receive messages at his address on chain X. Rather, Alice can simply send a message to Bob on X by specifying his address on X. Bob can then go and check his messages, of his own accord.
Please use the Bluzelle "Curium" extension as part of your integration so that the sender is always interacting with Curium to pay the gas to send the messages.
Curium is still awaiting approval in the Chrome Extension Store, but in the meantime, you can install it locally via our repo:
https://github.com/bluzelle/blz-extension
Resources
Our Discord:
https://discord.gg/yqBmzPxRZK
Website:
https://www.bluzelle.com
Our JS library:
https://www.npmjs.com/package/@bluzelle/sdk-js
To install our libraries:
install @bluzelle/sdk-js with “yarn” or “npm”
Submission Requirements
The submission should include sufficiently QA’d documentation on how to deploy the service/product, and how to use the submission as per the requirements of the bounty.
These should include documentation on the commands to be used to interact with the submission, and how the submission is configured to work properly with BluzelleDB, etc.
A video demo should be included. It would nice to have a voice-over in English where we can fully understand the submission, but this is not a strict requirement. A computer-generated voice over is ok too, if you prefer.
The demo should also walk through the code and explain all the items that are being provided. The demo should walk through the process of deploying the submission, and how to use it, etc.
It is expected that the documentation is accurate. We will follow your documentation, to properly evaluate the submission. If it is incorrect, we may be unable to fairly evaluate your submission.
Including tests with your submission will greatly improve your chances of winning. We like to run tests that are highly verbose and explicit in terms of what they are doing, so we can gain confidence in the correctness of what you have submitted. If you provide tests and expect us to run them, like everything else, document it well, and ensure that the tests can be run by us -- give us the steps to setup and run the tests.
If the documentation is incomplete or incorrect, there is a possibility that we may not be able to fairly assess the submission, as we will walk through the documentation to validate the project. Due to practical limitations on time and resources, once a project is submitted, we are not able to provide much assistance in correcting a project’s that may not be properly working, nor to inquire to get proper steps, if the documentation that comes with a submission is insufficient.
Your project will be judged based on what you submit. Please submit something that is complete, well thought out, and tested, from a documentation and product features and code quality standpoint. We will do our best to evaluate, but obviously, the easier you make our life, the better the chances are that you win.
WE LOVE VERBOSITY AND DOCUMENTATION. There is no such thing as too much information. Explain what you have built, and please ensure it will run CORRECTLY, when we follow your directions literally. Just doing this alone will vastly improve your chances of victory.
Judging Criteria
Our goal is to, as part of the evaluation process, fully setup, and use your submission, successfully, and without any major hiccups.
Based on the ease of doing this and the quality of your documentation, product, code, and features, we will choose the winner.
There is no preference to ordering of submissions -- just be sure to submit them on time. Once submitted, we will evaluate and there will not be alot of opportunity for back and forth. Please ensure your submitted documentation and code is complete, enabling us to properly judge it based on its merit.
We will choose the best based on quality. Documentation and properly written code is a large part of the criteria. A project that we cannot deploy ourselves is difficult to give a prize to. We will do our best to contact you, if there is an issue. Practically, we probably won’t have much time to contact you, after submission, to get clarification or to ask you to fix a bug. It ideally should work when we judge it.
Note: While the descriptions given for bounties are quite explicit and even tend to suggest how an actual solution to each problem can be built, you as a developer have the option to architect the solution your own way. We have provided guidance on a solution we see as reasonable, but we are open to considering other solutions. Obviously, we will choose the best overall submission, based on various factors including the elegance of the solution.
The text was updated successfully, but these errors were encountered: