BitShares Forum
Main => General Discussion => Topic started by: santaclause102 on August 24, 2015, 11:21:53 am
-
I have a very specific question:
How much and what type of (front end / back end) development work is needed to realize a colored coins application (say a brownie points style gift economy platform) if Bitshares (2.0) already supports these features (user issued assets and trading of them). I know you can do all that just by using the bitshares wallet but in order to commercialize it an entrepreneur would need to market it with that specific use case. So a website / webapplication that offers tools for a brownie points style gift economy an without all the added functionality of the bitshares wallet would make sense.
Would an entrepreneur build his own front end /web wallet or would it make sense to customize the bitshares whitelabel wallet?
And do you see a chance that for the above use case (brownie points style gift economy) adding features to bitshares (shareholder approval needed) might be required?
-
Other point is, what are the transaction fees in this situation.
-
Other point is, what are the transaction fees in this situation.
Those would the the standard tx fees for the bitshares network as the tx happen on the bitshares blockchain.
-
Other point is, what are the transaction fees in this situation.
Those would the the standard tx fees for the bitshares network as the tx happen on the bitshares blockchain.
It's ok I was thinking about the price of gift tokens vs the price of the transaction. So the gift should be more than 20 cents.
-
in bts 2.0 the issuer can fund the fee pool so that costumers don't need to pay the transaction fees .. unless the fee pool is emptied
-
in bts 2.0 the issuer can fund the fee pool so that costumers don't need to pay the transaction fees .. unless the fee pool is emptied
So if I am a life member and I want to be charged 4 cents for sending gift tokens, will that be possible?
-
in bts 2.0 the issuer can fund the fee pool so that costumers don't need to pay the transaction fees .. unless the fee pool is emptied
So if I am a life member and I want to be charged 4 cents for sending gift tokens, will that be possible?
Or I will need to fund the fee pool, and each one will be charged 20 cents.
-
AFAIU you either let the issuer pay all fees via fee pool .. or let your costumers pay all fees (either in BTS or as asset with a base_rate to BTS) ..
-
AFAIU you either let the issuer pay all fees via fee pool .. or let your costumers pay all fees (either in BTS or as asset with a base_rate to BTS) ..
Thanks xeroc
-
in bts 2.0 the issuer can fund the fee pool so that costumers don't need to pay the transaction fees .. unless the fee pool is emptied
So if I am a life member and I want to be charged 4 cents for sending gift tokens, will that be possible?
Yes
-
in bts 2.0 the issuer can fund the fee pool so that costumers don't need to pay the transaction fees .. unless the fee pool is emptied
So if I am a life member and I want to be charged 4 cents for sending gift tokens, will that be possible?
Yes
Thanks!
-
Anyone interested in addressing the OP? :D
Simplifying the question a bit: How would one go about creating "a brownie points style gift economy platform", how much development effort would that be, what type of dev effort would be required (front/end back end), is shareholder approval needed and how would that someone profit from it?
I partly have answers to these questions (see my assumptions in the OP) but I want to have a clearer picture.
-
It seems that not every type of website/webapplication is equally suitable for this approach.
You need to take into account the considerations described by BM here:
I think this is an area where there is a lot of confusion over encryption, authentication, and "security".
Blockchains are good for authentication, but their data is public.
Hosted Wallets are good for authentication *AND* encryption so long as server-side indexing of the data isn't required. So if I wanted something like drop-box, MEGA, or Google Docs, then I would want the file encrypted on the server and only visible in my browser.
A dating website would be problematic if you expect the server to cross-reference profiles and find matches.
Social Media would be slightly less effective without server-side indexing and matching.
Identabit will be using a "private blockchain" to protect privacy. *IF* one of those private servers were hacked then the chain data could be made public. Even though no-ones account control was compromised, their financial history would have been.
-
It seems that not every type of website/webapplication is equally suitable for this approach.
You need to take into account the considerations described by BM here:
I think this is an area where there is a lot of confusion over encryption, authentication, and "security".
Blockchains are good for authentication, but their data is public.
Hosted Wallets are good for authentication *AND* encryption so long as server-side indexing of the data isn't required. So if I wanted something like drop-box, MEGA, or Google Docs, then I would want the file encrypted on the server and only visible in my browser.
A dating website would be problematic if you expect the server to cross-reference profiles and find matches.
Social Media would be slightly less effective without server-side indexing and matching.
Identabit will be using a "private blockchain" to protect privacy. *IF* one of those private servers were hacked then the chain data could be made public. Even though no-ones account control was compromised, their financial history would have been.
I don't think its a matter of suitability as much as it is a matter of development burn time involved. We have a toolkit/network. Some will put in more effort than others to build more advanced solutions than others. Give two different people the same set of tools and ask them to build something and the results will be different based on the level of expertise and creativity applied to their work.
I do agree not all endevours are going to be easy peasy.... but it doesn't mean they are out of the question.
-
It seems that not every type of website/webapplication is equally suitable for this approach.
You need to take into account the considerations described by BM here:
I think this is an area where there is a lot of confusion over encryption, authentication, and "security".
Blockchains are good for authentication, but their data is public.
Hosted Wallets are good for authentication *AND* encryption so long as server-side indexing of the data isn't required. So if I wanted something like drop-box, MEGA, or Google Docs, then I would want the file encrypted on the server and only visible in my browser.
A dating website would be problematic if you expect the server to cross-reference profiles and find matches.
Social Media would be slightly less effective without server-side indexing and matching.
Identabit will be using a "private blockchain" to protect privacy. *IF* one of those private servers were hacked then the chain data could be made public. Even though no-ones account control was compromised, their financial history would have been.
I don't think its a matter of suitability as much as it is a matter of development burn time involved. We have a toolkit/network. Some will put in more effort than others to build more advanced solutions than others. Give two different people the same set of tools and ask them to build something and the results will be different based on the level of expertise and creativity applied to their work.
I do agree not all endevours are going to be easy peasy.... but it doesn't mean they are out of the question.
Yes, that's a good clarification of what I meant.
So to answer the OP question:
"How much and what type of development work is needed to realize a brownie points style gift economy platform?"
we need to take into account what role the user data plays in such a platform and how we want to manage it.
I guess some implementations might be straight out of the box, but other might require developing additional solutions for handling and securing user data.