BitShares Forum
Other => Graveyard => Keyhotee => Topic started by: toast on March 15, 2014, 11:12:31 pm
-
Option 1: Release a MVP consisting of a client with a CLI/RPC interface and a working blockchain ASAP which does nothing but register and look up names.
Pros:
* Let outside developers start integrating Keyhotee.
* Let people starting marketing Keyhotee outside of these forums
Cons:
* "Keyhotee is ready!", but no user-friendly interface or any advanced functionality
Option 2: Delay launching the blockchain further but have a clean, feature-full application to interact with it soon after it launches.
Pros/cons: The opposite of pros/cons from above.
This poll is part of my status update in this thread: https://bitsharestalk.org/index.php?topic=3598.0
-
What are the timelines for these options?
Sent from my iPhone using Tapatalk
-
From your other thread:
"Communication issues? Internal politics? Lack of trust? No idea, but it left me scared and confused."
My suggestion is to have Stan make this determination before choosing a forward course for Keyhotee development. If Stan can't/doesn't want to make the determination, hire an outside consultant for this one factor and nip it in the bud lest it spreads to other areas.
-
Option 1: Release a MVP consisting of a client with a CLI/RPC interface and a working blockchain ASAP which does nothing but register and look up names.
Pros:
* Let outside developers start integrating Keyhotee.
* Let people starting marketing Keyhotee outside of these forums
Cons:
* "Keyhotee is ready!", but no user-friendly interface or any advanced functionality
Option 2: Delay launching the blockchain further but have a clean, feature-full application to interact with it soon after it launches.
Pros/cons: The opposite of pros/cons from above.
This poll is part of my status update in this thread: https://bitsharestalk.org/index.php?topic=3598.0
I think you've missed the current division of work: Eric Frias and I are now working on the generic blockchain code which will be used for Keyhotee and other DACs, while the guys in Poland (lead by vogel67) are working on the GUI side and Keyhotee-specific backend requirements (e.g. system-specific messages like authorization requests, etc). These are independent efforts proceeding in parallel, mostly.
Theoretically, we could move them to working on the blockchain with us, but in practice, its much simpler for Eric and I to handle it, since we can sit in the same room and design it together. The other reason this division of labor is more sensible is that only Eric and I are really familiar with Dan's fc library which is used as the basis for the networking and fiber code, and it takes some time to understand this code well (Eric and I both worked in this code base on a past contract).
Plus, if we did bring all those guys into blockchain code now, we'd still need to add KH-specific stuff to the backend afterwards.
For those who are curious, this is current Invictus programmers as I'm aware of it (there's also a few outside guys):
In US, bytemaster works on BitSharesX
In US, emfrias and I are designing blockchain/p2p code
In Poland, vogel76, grzegorz, and PaulEU work on KH GUI and KH-specific backend code
In Poland, gandalf provides build support, scripts, and general system admin support
In India, yuvaraj works on KH GUI and is also primary tester for KH (he's away this month on honeymoon)
-
Thanks for your response - I was under the impression that this wasn't being worked on at all based on my conversations with Dan L and the very brief skype chat we had while I was at their house. I've updated the original status update thread with your comment.
-
...
I think you've missed the current division of work: Eric Frias and I are now working on the generic blockchain code which will be used for Keyhotee and other DACs, while the guys in Poland (lead by vogel67) are working on the GUI side and Keyhotee-specific backend requirements (e.g. system-specific messages like authorization requests, etc). These are independent efforts proceeding in parallel, mostly.
...
Thanks for the update! Are authorizations stored on chain? It seems like there will be a huge number of application specific data elements needed for new apps that use KIDs, but I imagine most of this will either be off chain or on a separate app-specific chain rather than the KID chain. Am I far off from the design plan here?
-
...
I think you've missed the current division of work: Eric Frias and I are now working on the generic blockchain code which will be used for Keyhotee and other DACs, while the guys in Poland (lead by vogel67) are working on the GUI side and Keyhotee-specific backend requirements (e.g. system-specific messages like authorization requests, etc). These are independent efforts proceeding in parallel, mostly.
...
Thanks for the update! Are authorizations stored on chain? It seems like there will be a huge number of application specific data elements needed for new apps that use KIDs, but I imagine most of this will either be off chain or on a separate app-specific chain rather than the KID chain. Am I far off from the design plan here?
Authorizations aren't on the blockchain. Authorizations are only known locally to the two clients who have authorized each other. Authorization will be used for things like direct connect communication and sharing a set of deterministicly computable keys between a pair of users. Authorizations are part of the KH-specific message protocol which can be used by any KH-style client.
-
Thanks, that makes sense.
-
I'd like the blockchain launched because nothing starts out perfect and eventually needs to be worked with. Although it won't be user friendly, it'll be out there and not just something in development. But I do want everything to be done right, I'm ok with waiting for other features.