Hi all,
This is Vishwas, from India. We are planning to build our network using cosmos sdk. We have some confusion regarding IBC. Would need your help to clear them out.
So let me start by sharing what is Hypersign and what we are planning to do with it.
Warning: It will be a bit longer post. Kindly give me chance to explain.
Hypersign (https://hypersign.id/ ) is a decentralized password less authentication solution (we are calling it Hypersign dAuth - unofficial name) which works on Self Sovereign Identity principle. At present it does not use any blockchain, the DID and credentials are stored in database and user;s device respectively. We have seen quite a decent amount of traction in this product since the users do not have to manage any password. Currently, it is being used and tested thoroughly in one of our marketing tools called, Hyperfyre (https://fyre.hypersign.id/) which has over lakhs users and also uses SSI.
Our vision with Hypersign was, to build an authentication system which is self sovereign - meaning, tomorrow even if my company shuts down or my servers are no more, the users should not loose access to applications they were using. You can clearly see this problem with existing 3rd party authentication systems like Google login , Facebook logins etc. The way we try to solve this problem is, the website (we call service provider) never calls the IdP (identity provider) when user goes to verify the credentials to get access. The website should be able to verify the identity (technically speaking digital signature of issuer and user) of the user on its own.
That’s where blockchain pitches in. We have two options, we can either use someone else chain, or we can build our own. There are five reasons we are not going to use someone else’s chain.
-
Interoperability : One thing which we also want to achieve is, we want to provide SSI infra to all the zones available in the cosmos ecosystem. Like if a DID is issued on one zone, it should get resolved in other zones - usecase would be, an issuer (Idp) can sit in one of the zone but the verifier (service provider or website) may sit in another zone. I do not see (or at least I did not come across, I might be wrong) any project doing that. Not just that, we are also visualizing the privacy preserving sub chains using our interoperable SSI infra.
-
HID Tokens : We did our token (HID) sale on Ethereum and we want to increase the token utility.
-
Team : We have good team of engineers and researchers and marketing personnel who have good background in blockchain tech and crypto space overall. I myself have worked on a 2 blockchain networks so far. So we are confident enough to do things.
-
Use cases : Just like Hypersign dAuth and Hyperfyre we have more use case which we will port on our network - bringing enough transactions at the time of bootstrapping. Our ideas was to build business first and then go for a network and pull these transactions on that network.
-
Market : Indian market is growing at a very faster rate, people (specially the younger generation) don’t want to work for others any more, they want to build on their own. I personally have been training people (college students) on blockchain and have been encouraging them to become entrepreneurs and build products. I believe some of them will surely develop on us if we give them technical and financial support. We have a lot of strategies to tap Indian youth and one of them is Hackathons (I myself is product of Hackathons :))
Sorry about the long post but I felt the need to give an introduction.
Now let me ask my question. So you might have observed our USP would be interoperability of DID. We see, IBC can be used to achieve that. So the questions are:
- can IBC is flexible enough to send / receive any kind of arbitrary data? If yes, how it reaches consensus on that data in the recipient zone? Or is it only designed to send / receive payment related data?
- Is there any team or documentation who are working on sending arbitrary data via IBC?
TIA, looking forward to hear from you.